Bug 95959 - Password protected macros are not available in "Run macro" in 4.x when stored with 5.x
Summary: Password protected macros are not available in "Run macro" in 4.x when stored...
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
5.0.3.2 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2015-11-20 18:50 UTC by Gerhard Schaber
Modified: 2016-09-28 10:48 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Test file for invisible macros (6.04 KB, application/vnd.sun.xml.base)
2015-11-20 18:50 UTC, Gerhard Schaber
Details
build info file from the bisect for the first bad version (2.76 KB, text/plain)
2015-12-05 15:42 UTC, Gerhard Schaber
Details
build info file from the bisect for the first bad version (3.96 KB, text/plain)
2015-12-06 12:17 UTC, Gerhard Schaber
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gerhard Schaber 2015-11-20 18:50:08 UTC
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
Comment 1 Gerhard Schaber 2015-11-20 18:58:51 UTC
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.
Comment 2 Buovjaga 2015-11-23 13:41:38 UTC
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
Comment 3 Gerhard Schaber 2015-11-23 22:50:54 UTC
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.
Comment 4 Gerhard Schaber 2015-11-30 08:42:36 UTC
The missing macro is, though.
Comment 5 Gerhard Schaber 2015-12-05 11:32:03 UTC
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
Comment 6 Gerhard Schaber 2015-12-05 11:38:31 UTC
Cor Nouws, you set the TooBusyNowNeedsFurtherTestingForPossibleRegressionAndPossibleDuplicates in the Whiteboard field. Since this is bibisected, maybe you want to reconsider this.
Comment 7 Buovjaga 2015-12-05 11:44:27 UTC
Yeah let's take it out.

Miklos: can you take a look at the bisect result?
Comment 8 Gerhard Schaber 2015-12-05 15:42:12 UTC
Created attachment 121051 [details]
build info file from the bisect for the first bad version
Comment 9 Gerhard Schaber 2015-12-06 12:17:25 UTC
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
Comment 10 Gerhard Schaber 2015-12-06 12:30:06 UTC
(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.
Comment 11 Gerhard Schaber 2015-12-06 12:34:53 UTC
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
Comment 12 Buovjaga 2015-12-06 12:37:10 UTC
Ok.. removing Miklos and adding Laurent to CC.
Comment 13 Robinson Tryon (qubit) 2015-12-13 11:14:21 UTC Comment hidden (obsolete)
Comment 14 Gerhard Schaber 2015-12-18 15:17:34 UTC
Of course, OpenOffice cannot run the macros either (unless they are unprotected)
Comment 15 Gerhard Schaber 2016-01-20 13:14:42 UTC
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?
Comment 16 Gerhard Schaber 2016-02-12 11:15:28 UTC
Laurent, please can you have a look to make it more compatible?
Comment 17 Gerhard Schaber 2016-02-12 11:21:05 UTC
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.
Comment 18 Gerhard Schaber 2016-03-07 13:32:06 UTC
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.
Comment 19 Caolán McNamara 2016-09-28 10:48:24 UTC
lets close it cause we kind of got painted into a corner there and can't fix earlier versions than 5.X