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 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
@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) [NinjaEdit]
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC) [NinjaEdit]
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 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.
Deepanshu has a patch for this, but doesn't seem to have a BZ account: https://gerrit.libreoffice.org/c/core/+/183219
Created attachment 201080 [details] fields disabled but default values don't reflect the reality
Created attachment 201441 [details] font doable working correctly on the system
Deepanshu Sharma committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/57352dce995c98d1282484d02c38ed2132b091f5 tdf#56676 disable form properties when they are not available for change It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Deepanshu: feel free to close as fixed.
Reopened this bug, because it sets all created forms to unwritable. There will be no difference between Calc forms (and, for example, Writer forms) and forms for a normal database. With LO 26.2.0.3 you couldn't create any form now, which could be used for write data into a table. This "enhancement" destroys normal working with Base. See bug 170839 Version: 26.2.0.3 (X86_64) Build ID: afbbd0df0edb6d40b450b0337ac646b0913a760c CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-26-2": https://git.libreoffice.org/core/commit/4a3c49a26667f33bc25d309814181a2a478e48ac tdf#170839: Revert "tdf#56676 disable form properties when they are not available for change" It will be available in 26.2.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-26-2-1": https://git.libreoffice.org/core/commit/b694178bd7d996eef834892f103610e8d808b1fb tdf#170839: Revert "tdf#56676 disable form properties when they are not available for change" It will be available in 26.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/17b15a7f6f70aedf9a8f1c2e764b82c61004f6d0 tdf#170839: Revert "tdf#56676 disable form properties when they are not available for change" It will be available in 26.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Unfortunately I had to revert the commit fixing this issue because it was causing bug 170839
Hi, I’ve started looking into this after it was reopened. When testing with a writable embedded Firebird database, I see that in Design Mode → Form Properties → Data tab, the options “Allow additions”, “Allow modifications”, and “Allow deletions” are disabled and set to “No”. However, in normal mode I can still insert and modify records successfully. So currently the UI suggests the form is not writable, while runtime behaviour allows writing. Before attempting a fix, could you clarify what should be the authoritative source for determining writability here? Should it be based on the form component’s Privileges, the underlying RowSet/RecordSet, or connection/database metadata? I’d like to make sure the solution correctly handles read-only datasources (e.g. Calc-based) without affecting writable databases. Thanks.
(In reply to Madhura R Hegde from comment #28) > > When testing with a writable embedded Firebird database, I see that in > Design Mode → Form Properties → Data tab, the options “Allow additions”, > “Allow modifications”, and “Allow deletions” are disabled and set to “No”. > However, in normal mode I can still insert and modify records successfully. > > So currently the UI suggests the form is not writable, while runtime > behaviour allows writing. If you create any new form (or change a old form and save it with LO 26.2.0.3) it won't be writable any more. In LO 26.2.0.3 it isn't possible to show any other behavior than described above, but you won't have saved this behavior. Don't know where it has been saved that datasource would be writable at all. So I would switch to "not writable" for Spreadsheet, Writer document and any Mail-Addressbook, because tables of this data source aren't writable at all for Base.
(In reply to Madhura R Hegde from comment > Before attempting a fix, could you clarify what should be the authoritative > source for determining writability here? Should it be based on the form > component’s Privileges, the underlying RowSet/RecordSet, or > connection/database metadata? > > I’d like to make sure the solution correctly handles read-only datasources > (e.g. Calc-based) without affecting writable databases. > My 2c. There are, IMO, several things to bear in mind: - the whole point of the original UI options was to allow the creation of forms that the form developer could selectively specify the bound data source as non-modifiable, non-additive, and/or non-deletable via the Form UI, _even_if_ the data source was writable - this functionality should not be lost ; - on the other hand, it has always been accepted AFAIK that non-writable datasources from within Base can never be writable from the Form UI. Some might argue that we should also allow writing via the Form UI to bound data sources such as CSV,text, Calc and Excel, but this would be technically challenging for a whole load of other reasons linked to data integrity and reliable indexation of the dataset. So, if there is a reliable method to determine whether a data source is writable from the connection metadata, then I would have thought that this might be the most elegant option.
New patch from Madhura: https://gerrit.libreoffice.org/c/core/+/200254