Created attachment 120683 [details] Test file for invisible macros When storing a password protected macro in 5.0.3.2 and opening it with 4.4.5.2 or 4.4.3.2, then the old version would not show the macro, let alone execute it. When I enter the password in 4.4.3.2 and then store the whole ODB file again, and reopen it, the macro shows up again, and it is not necessary to enter the password this time. With bug #87530 generally entering a password was broken. But now I cannot even see the macros anymore in old versions unless I follow the steps above. I usually work with 5.0.3 now, and do not want to go back to OpenOffice 3.x to set a password and to LibreOffice 4.4 for storing the changes to make sure that macros also work with older versions. This is really cumbersome. The attachment shows the behavior very clearly. Open the odb file. If the menu Test is there on the top right side, then it works (5.0.x), otherwise (older versions) it does not. I am not sure, if this is related to #93475, but it seems somewhat different. Best regards, Gerhard
Correction, there seem to be two issues. 1. First is that the menu entry disappears 2. The macro itself is not visible for macro execution. The password for the macro in the test file is "test". Once I store the file in LibreOffice 4.4.3.2, the macro is visible from then on. But the menu will not show up even then.
If you have created a menu, the information for it is stored in your profile, not in a document. I'm not seeing any menu. It is true that the testlib macro is not visible in Run macro in 4.3. It is visible in Organize macros. However, it becomes available even in Run macro after entering the password in Organize macros. Win 7 Pro 64-bit, Version: 5.0.3.2 (x64) Build ID: e5f16313668ac592c1bfb310f4390624e3dbfb75 Locale: fi-FI (fi_FI) Version: 4.3.0.1 Build ID: 67f5430184326974072b65403ef1d9d934fc4481
Yes, forget about the menu. I accidentally stored it in the profile instead of the file (it can be stored in the file itself as well). The menu is not a problem.
The missing macro is, though.
Bisected via git://dev-downloads.libreoffice.org/lo-linux-dbgutil-daily-till51.git 9b3e246c95933293fa60b1e377bf05b0e1c80a6d is the first bad commit commit 9b3e246c95933293fa60b1e377bf05b0e1c80a6d Author: Miklos Vajna <vmiklos@collabora.co.uk> Date: Fri Oct 2 04:45:00 2015 +0200 2015-10-02: source-hash-419549b095a1bb95ce23bf3fc8866e6b582e6dde :100644 100644 1ba4d8b7ed7b3f003e039d08f61ed98ef6da8733 093c920989ef7bd4c1b91603e4ed40f8ac177139 M build-info.txt :040000 040000 a9bdba5afeb7c33a31917bafb3c4589f39642f0b dabcb36b98f1689f496d9e55c9dcf09198c21b5e M opt
Cor Nouws, you set the TooBusyNowNeedsFurtherTestingForPossibleRegressionAndPossibleDuplicates in the Whiteboard field. Since this is bibisected, maybe you want to reconsider this.
Yeah let's take it out. Miklos: can you take a look at the bisect result?
Created attachment 121051 [details] build info file from the bisect for the first bad version
Created attachment 121074 [details] build info file from the bisect for the first bad version This is the build info file from the first bad commit. The previous one was from a good version
(In reply to Gerhard Schaber from comment #8) > Created attachment 121051 [details] > build info file from the bisect for the first bad version Please ignore this file. It was from the last good version.
The file from 2015-12-06 is the right one. I guess a candidate that might cause this could be (see also the attached build info file of the bisect repository): commit ddb45261590939d884ac2bcb1fd258de7b2370da Author: Laurent Godard <lgodard.libre@laposte.net> Date: Fri Sep 18 17:06:29 2015 +0200 tdf#94617 allow to store nStart information greater than sal_Int16 limit - preserve backward compatibility - nDebugFlag is stored but not used when loaded - Flag nDebugFlag set the top bit to 1 - stores the multiplier of sal_Int16 limit to reach nStart - in load, test this flag bit - rebuild correct nStart - new B_CURVERSION file format for binary storage macro - unit test for big modules Reviewed-on: https://gerrit.libreoffice.org/18926 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit db17079fcff6f9a068c499b17f2501cc4c82d10b) Change-Id: Iaa037982d828fef7195615e6eda546b7199a4fe8
Ok.. removing Miklos and adding Laurent to CC.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
Of course, OpenOffice cannot run the macros either (unless they are unprotected)
The original intention apparently was to preserve backwards compatibility according to the check-in comment. Is the current behavior considered a regression or will it stay this way? There are regressions in 5.x that kind of keep me from using it, but on the other hand there are bug fixes that are onky available in 5.x. I would like to go with 5.x, but with the option of using the database file in 4.x as well. I do not know the code, but is there anything else I can do to help with narrowing down / fixing this issue?
Laurent, please can you have a look to make it more compatible?
If this is not possible, it would be good to have a kind of warning that says that password protected macros cannot be used in older versions unless one enters the password and stores it with the older version. I basically find it good to have more lines available per module.
The fix 89710 that causes this, seems to fix issue 94617. I am fine with closing the current issue. It would be very useful, if there was some kind of warning, so that a user is aware that the stored macro will not be compatible with earlier versions than 5.0.2 anymore. If you know the password, you can enter it in the older LO version and store the macro again as workaround. So, you do not actually lose data.
lets close it cause we kind of got painted into a corner there and can't fix earlier versions than 5.X