Bug 56676

Summary: EDITING: Tables in databases based on calc are unwriteable - Form Properties show them as writable
Product: LibreOffice Reporter: robert
Component: DatabaseAssignee: 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

Description robert 2012-11-02 12:03:10 UTC
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.
Comment 1 bfoman 2013-05-13 12:41:40 UTC
Could you attach any example files to allow others to check on different
system/build?
Comment 2 robert 2013-05-13 15:27:47 UTC
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?"
Comment 3 robert 2013-07-13 10:27:33 UTC
(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".
Comment 4 Alex Thurgood 2013-07-13 10:53:03 UTC
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
Comment 5 Alex Thurgood 2013-07-13 10:57:02 UTC
Created attachment 82384 [details]
form properties for attached calc based database
Comment 6 Alex Thurgood 2013-07-13 10:59:53 UTC
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
Comment 7 Lionel Elie Mamane 2013-07-13 14:22:49 UTC
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
Comment 8 Björn Michaelsen 2013-10-04 18:47:40 UTC
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
Comment 9 Alex Thurgood 2015-01-03 17:40:29 UTC
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.