| Summary: | "Macros disabled" show a button "Show macros" which does not make sense | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Rafael Lima <rafael.palma.lima> |
| Component: | BASIC | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | UNCONFIRMED --- | ||
| Severity: | enhancement | CC: | heiko.tietze, samuel.mehrbrodt, stephane.guillou |
| Priority: | medium | ||
| Version: | 7.6.0.3 release | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://bugs.documentfoundation.org/show_bug.cgi?id=157482 https://bugs.documentfoundation.org/show_bug.cgi?id=153322 |
||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 83009 | ||
| Attachments: | Screenshot showing the problem | ||
It makes the perfect sense. You are free to see the code that didn't run; inspect and see if it might do any harm. You mau disable non-working code, that somehow prevents you from using the document when enabled (e.g., shows messages in loop), and edit it here (without running). I don't see why it confuses you. A button to go to security settings is OK, but only as a companion. OTOH, you specifically mentioned "High", which indicated that you refer to auto-reject cases, where the user didn't see a request (as shown in Medium). Here your proposal might be reasonable; only show it in cases where the user made an explicit decision to reject in UI... The macro is expected to process some data anyway and you should get a hint why something does not work as expected. Whether medium, where you decide to not trust the author unless taking a peek into the code, or high / very high - in all cases you may want to know what this macros does. I'd go rather the other way and allow execution for this particular document, ie. to add a button [Execute]. Users have to change the global setting currently, and have to remember to set it back. We discussed the topic in the design meeting. Hiding the button could be seen as an improvement for security (raises the barrier to access macros) but also as the opposite since users might change the security level without looking into the macro code. In any case it is pretty simple to do so by using the main menu - which is rather an argument to keep the interaction on the toolbar because it might look a bit orphaned without any action. To summarize, no big issue to implement, not much benefit. The recommendation is to resolve as WF. |
Created attachment 191318 [details] Screenshot showing the problem See attached image for more information. If your "Macro Security" settings are set to High, when you try to open a document with a macro, the infobar "Macros disabled" is shown. However, at the end of the infobar there is a "Show Macros" button, which opens the Basic Macro Organizer, which makes no sense. Since macros are disabled, it does not make sense to open a dialog that does not allow to change the settings that made macros disabled. Instead, there should be a "Security options" button that opens the Security section of the Options dialog.