Bug 112059 - Events fired by subform changed, when form is write-protected
Summary: Events fired by subform changed, when form is write-protected
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.0.0.5 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Database-Forms
  Show dependency treegraph
 
Reported: 2017-08-27 15:37 UTC by Robert Großkopf
Modified: 2023-12-08 07:25 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Open the form "Name_not_editable". Msgbox show the fired events. Differs to LO <5 (27.46 KB, application/vnd.oasis.opendocument.database)
2017-08-27 15:37 UTC, Robert Großkopf
Details
bibisect output (3.47 KB, text/plain)
2017-09-01 02:13 UTC, Terrence Enger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2017-08-27 15:37:07 UTC
Created attachment 135820 [details]
Open the form "Name_not_editable". Msgbox show the fired events. Differs to LO <5

Don't know if this is a buggy behavior or only modified, but the events, which are fired by a subform have been changed from LO 4.4.7.2 to LO 5.0.0.5.

Open the attached database with LO 5.*.
Open the form "Name_not_editable". Form will be empty, data couldn't be edited.
Two messageboxes will appear:
"BeforeRecordChange" and "AfterRecordChange".

Do the same with LO 4.4.7.2 and all earlier versions of LO.
Two messageboxes will appear:
"BeforeRecordChange" and "WhenReloading".

I have named all the messageboxes like the events, so they will show the event, which fires.
Comment 1 Stephan 2017-08-27 15:43:47 UTC
Confirmed for both forms in LO 5.2.7.2 64bit under Windows 7 64 bit with Java 8.
Comment 2 Alex Thurgood 2017-08-28 15:34:36 UTC
I can also confirm this when testing with LO4452 and LO5063. Behaviour is as described by Robert.

Marking as regression.

I don't recall there being any voluntary changes to macro event firing in that particular period (but I could be wrong).
Comment 3 Alex Thurgood 2017-08-28 15:37:53 UTC
Bug 42796 looks similar...
Comment 4 Alex Thurgood 2017-08-28 15:42:26 UTC
And also bug 91828...
Comment 5 Terrence Enger 2017-09-01 02:13:12 UTC
Created attachment 135920 [details]
bibisect output

Working on debian-stretch in the 50max bibisect repository, I see that
the bug entered LibreOffice in the one commit:

          commit    s-h       date
          --------  --------  -------------------
    good  243f270d  4a7089ff  2015-01-22 12:18:54
    bad   cbafe9bb  47bd9bd0  2015-01-22 12:18:54

for which the commit log is:

    commit 47bd9bd00edc9c0f2f4834a1b4869b45b65ab66a
    Author: Lionel Elie Mamane <lionel@mamane.lu>
    Date:   Thu Jan 22 11:13:14 2015 +0100

        RowSet: notify listeners when next() brings us afterLast
    
        Change-Id: I6024352f9d7c68d8075d90b5954ec3ba662a06f0

I am removing keyword bibisectRequest and adding bibisected and
bisected.
Comment 6 Xisco Faulí 2017-09-05 22:21:56 UTC
Adding Cc: to Lionel Elie Mamane
Comment 7 QA Administrators 2018-09-06 02:59:57 UTC Comment hidden (obsolete)
Comment 8 Robert Großkopf 2018-09-06 14:07:30 UTC
Bug also appears in LO 6.1.0.3 on openSUSE 15, 64bit rpm Linux. Nothing changed here.
Comment 9 QA Administrators 2019-12-07 03:43:41 UTC Comment hidden (obsolete)
Comment 10 Robert Großkopf 2019-12-07 07:53:36 UTC
Bug still exists with LO 6.4.0.0 beta1 on OpenSUSE 15.1 64bit rpm Linux
Comment 11 QA Administrators 2021-12-07 04:56:10 UTC Comment hidden (obsolete)
Comment 12 Robert Großkopf 2021-12-07 15:24:01 UTC
It's the same behavior in LO 7.2.3.2.

But I don't know if this is a bug or a planned feature.
Comment 13 QA Administrators 2023-12-08 03:14:52 UTC Comment hidden (obsolete)
Comment 14 Robert Großkopf 2023-12-08 07:25:17 UTC
Behavior still exists in
Version: 24.2.0.0.alpha1 (X86_64) / LibreOffice Community
Build ID: 06946980c858649160c634007e5fac9a5aa81f38
CPU threads: 6; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb)
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded

Don't know why "AfterRecordChange should appear when there isn't any record, which could be shown and could be changed.