Bug 56676 - EDITING: Tables in databases based on calc are unwriteable - Form Properties show them as writable
Summary: EDITING: Tables in databases based on calc are unwriteable - Form Properties ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
3.3.4 release
Hardware: Other All
: low enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: difficultyInteresting, easyHack, skillCpp, skillSql, topicUI
Depends on:
Blocks: Database-Tables
  Show dependency treegraph
 
Reported: 2012-11-02 12:03 UTC by Robert Großkopf
Modified: 2020-03-09 13:28 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Shows the write-protected table and the wrong properties for this table. (217.96 KB, application/vnd.oasis.opendocument.graphics)
2012-11-02 12:03 UTC, Robert Großkopf
Details
Calc-document, base-file (must be connected, two screenshots) (71.09 KB, application/zip)
2013-05-13 15:27 UTC, Robert Großkopf
Details
form properties for attached calc based database (60.53 KB, image/png)
2013-07-13 10:57 UTC, Alex Thurgood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 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 (inactive) 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 Großkopf 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 Großkopf 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 Comment hidden (no-value)
Comment 10 Alex Thurgood 2015-10-21 09:03:07 UTC
@Tim : are you actually working on this or is there are mistake in this bug having been assigned to you ?
Comment 11 Nielens Tim 2015-10-21 10:24:55 UTC
No mistake but didn't finish. I put the ticket back to new.
Comment 12 Robinson Tryon (qubit) 2015-12-14 04:52:59 UTC Comment hidden (obsolete)
Comment 13 Robinson Tryon (qubit) 2016-02-18 14:51:51 UTC Comment hidden (obsolete)
Comment 14 jani 2016-05-04 05:51:57 UTC
Missing code pointer, which is mandatory for easy hacks.
Comment 15 Lionel Elie Mamane 2016-05-04 06:57:54 UTC
(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?
Comment 16 jani 2016-05-04 07:11:05 UTC
My bad, overlooked comment 7
Comment 17 Xisco Faulí 2020-03-09 13:28:11 UTC
Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.