| Summary: | EDITING: Tables in databases based on calc are unwriteable - Form Properties show them as writable | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | robert |
| Component: | Database | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | NEW --- | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | low | CC: | bfo.bugmail, iplaw67, libreoffice, lionel, serval2412 |
| Version: | 3.3.4 release | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | EasyHack DifficultyInteresting SkillCpp SkillSQL TopicUI | ||
| i915 platform: | i915 features: | ||
| Attachments: |
Shows the write-protected table and the wrong properties for this table.
Calc-document, base-file (must be connected, two screenshots) form properties for attached calc based database |
||
Could you attach any example files to allow others to check on different system/build? 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 > system/build? 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 4.0.3.3 (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. Alex 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. Alex 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 |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
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.