Created attachment 69432 [details]
Shows the write-protected table and the wrong properties for this table.
Create a database. The database should have a Calc-table as datasource.
Open the database. The tables of this database aren't editable, only readable.
No create a form. Link the form to a table of this database. The form shows properties, which are impossible for any table of this database:
- Allow additions
- Allow modifications
- Allow deletions
- Add data only
All this properties have to be set to "No" and not active for any changing through the user. They irritate people, who want to edit data to a Calc-table with base (and not only a Calc-table - could also be a addressbook, which is writeprotected.
Could you attach any example files to allow others to check on different
Created attachment 79257 [details]
Calc-document, base-file (must be connected, two screenshots)
Open the base-file.
Connect the database to the calc-file (Edit → Database → Properties).
Open the form for editing (right click of the mouse → Edit).
Open the form-properties (right click of the mouse on a control → Form).
See "Data" - the properties show the Calc-Sheet with the properties
"Allow Additions - Yes"
"Allow Modifications - Yes"
"Allow Deletions - Yes"
"Add Data only - No"
All this fields must be disabled when connecting to a database, which couldn't be edited.
Notice, that the wizards shows the same. So users might think: "Editing of a table is impossible - but with a form it is possible in LO. Why doesn't this work here with my database?"
(In reply to comment #1)
> Could you attach any example files to allow others to check on different
Any further questions? Could you reproduce - so please set Status to "New". If you couldn't reproduce set Status to "Unconfirmed".
Confirming, enclosed a screenshot of the Form Properties of your ODB file in LO :
Version 18.104.22.168 (Build ID: 0eaa50a932c8f2199a615e1eb30f7ac74279539)
Where it can be clearly seen that the Form is supposed to allow Additions, Modifications, and Deletions, which is clearly wrong because the Calc file can not actually be written to when the Form is opened for normal use.
Created attachment 82384 [details]
form properties for attached calc based database
I have no idea whether LO in its form handling code is actually supposed to be able to tell the difference between a r/o datasource and a r/w datasource. If nothing is there already, this would turn into a request for enhancement.
I'm of two minds on this... I always understood these properties as "should the form impose these restrictions or not". Setting them to "Yes" does not guarantee that these actions will work out in the end: the Database may not allow them because the user does not have the required permissions, LibreOffice may not be able to carry them out (e.g. because no primary key), ...
To me, it makes sense to keep these settings as such, orthogonal from the issues that may keep these actions from succeeding in practice. Frim this POV, this is not a bug.
OTOH, I kinda understand from a beginner-friendly POV that allowing the user to set a non-meaningful setting that will have no effect in practice is only confusing. From this POV, this is a valid enhancement request.
Oh well, if anyone feels like preparing a patch... let's see.
The code that decides whether a given propery is enabled or not is in file extensions/source/propctrlr/formcomponenthandler.cxx; look for _rxInspectorUI->enablePropertyUI calls. You'll need to add a case in FormComponentPropertyHandler::actuatingPropertyChanged for everything that may change the decision whether to enable or not, and there add PROPERTY_ALLOWADDITIONS, DELETIONS and EDITS to aDependentProperties.
Then add a case to FormComponentPropertyHandler::impl_updateDependentProperty_nothrow
for PROPERTY_ALLOWADDITIONS, DELETIONS and EDITS to make the actual decision to enable or disable. For that, I think you just have to read out the underlying RecordSet's "Privileges" property and test whether it includes com::sun::star::sdbcx::Privilege::DELETE/INSERT/UPDATE
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.
see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Adding self to CC if not already on
@Tim : are you actually working on this or is there are mistake in this bug having been assigned to you ?
No mistake but didn't finish. I put the ticket back to new.
Migrating Whiteboard tags to Keywords: (EasyHack DifficultyInteresting SkillCpp SkillSQL TopicUI)
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC)
Missing code pointer, which is mandatory for easy hacks.
(In reply to jan iversen from comment #14)
> Missing code pointer, which is mandatory for easy hacks.
You that comment 7 is not precise enough?
My bad, overlooked comment 7
Please add keyword 'needsUXEval' and CC 'firstname.lastname@example.org' if input from UX is needed.