Created attachment 181996 [details] Open the database, open the form and try: All fields are set to "required" in field properties. Open the attached database. Open the form. All controls have been saved with Data → Input Required → 'Yes' Fields "ID" and "Surname" are also set to "Required" in table design. Now the test: Only fill in content for "Surname" ("ID" is set to "AuoValue"). You could save the data without any warning. "Input Required", set in a control, doesn't give a warning. Only fill in content for "Forename", not for "Surname". You couldn't save the data. An error directly from the database appears for field "Surname". No error dialog in GUI language will appear any more here. We have three possibilities to solve this: 1. Remove "Input Required" from Control Properties → Data. Doesn't do anything. 2. Use "Input Required" for give a warning in language of user interface instead of warning from database directly. (Behavior of LO 6.0. and earlier) 3. Use "Input Required" for give a warning in language of user interface independent of "Input Required" in table editing. No. 3 would be the best solution.
Given that the same symptom had been fixed in bug 75341 for 6.2 in 2018, this needs a bibisect to find when the behavior reverted.
LOL. It only lived one week in 6.2 (from Sep 07 to Sep 15, 2018), and indeed it was a regression - by Julien ;) - so indeed it is not "I can't help here" ;-P Regression after commit e005ab5d40d358adb75a64e140d46f4bf605647d Author Julien Nabet <serval2412@yahoo.fr> Date Fri Sep 14 20:10:11 2018 +0200 Micro-optim in FormController::approveRowChange
I don't remember at all how was the patch supposed to do so, just to be sure, do you want me to revert https://gerrit.libreoffice.org/c/core/+/60109/ ? if yes, just tell and I'll do it.
https://gerrit.libreoffice.org/c/core/+/138550
By the way, I bet this will spawn the same storm as in bug 120353 ;)
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/59f30175bfc557aa7c752ab0b45af9d34215d4dc tdf#150577: Revert "Micro-optim in FormController::approveRowChange" It will be available in 7.5.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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/9fc6b68a075201b52ba1b70f60e04e6200dcf35b tdf#150577: Revert "Micro-optim in FormController::approveRowChange" It will be available in 7.4.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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/0e12ed1c39531566d080c9fa1e27e9e2659addd2 tdf#150577: Revert "Micro-optim in FormController::approveRowChange" It will be available in 7.3.7. 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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-3-6": https://git.libreoffice.org/core/commit/16eafe39aba428178aea67fba38cdfb8abf25262 tdf#150577: Revert "Micro-optim in FormController::approveRowChange" It will be available in 7.3.6. 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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-4-1": https://git.libreoffice.org/core/commit/8417736e27b71a3d291f7e316c08c1c18852ff03 tdf#150577: Revert "Micro-optim in FormController::approveRowChange" It will be available in 7.4.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.
Could confirm the bug has been fixed in LO 7.4.1.2 Thanks, Mike.
While the fix works when the property is set, it has an issue if the property is set using a macro. Attached Base file has amount field checked for a negative amount. If negative a REASON must be specified. The macro is attached to the Losing Focus event of the amount field. If the property is set correctly and the user gets the error, the amount field can be corrected but the error will continue even though the property is correctly set to False. You can only get around this by correcting the amount, leaving the REASON with some text, going to another record, then back to delete the text. Version: 7.4.1.2 / LibreOffice Community Build ID: 3c58a8f3a960df8bc8fd77b461821e42c061c5f0 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 182633 [details] Base file with macro to set parameter
(In reply to Stang from comment #12) Please debug the macro; namely, check if 'event.Source.Value() < 0' is executed at the moment of execution.
(In reply to Mike Kaganski from comment #14) > (In reply to Stang from comment #12) Actually, that is a completely different issue, related to "Column Info Cache" that gets initialized once, and not updated for the same row/record. That is unrelated to the issue raised and fixed here. In any case of "the problem is resolved as it is stated initially, but I found another way to get a similar/same result", please file new bugs (and ass this to See Also there, if appropriate).
(In reply to Mike Kaganski from comment #14) > (In reply to Stang from comment #12) Actually, that is a completely different issue, related to "Column Info Cache" that gets initialized once, and not updated for the same row/record. That is unrelated to the issue raised and fixed here. In any case of "the problem is resolved as it is stated initially, but I found another way to get a similar/same result", please file new bugs (and add this to See Also there, if appropriate).