Bug Hunting Session
Bug 33060 - Bundled extensions can not be disabled
Summary: Bundled extensions can not be disabled
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.3.0 RC2
Hardware: Other All
: high enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Extension-Manager
  Show dependency treegraph
 
Reported: 2011-01-13 06:57 UTC by Zoltán Reizinger
Modified: 2017-03-17 09:14 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot from LibO's Extension Manager (21.50 KB, image/png)
2011-01-21 11:08 UTC, Steven W
Details
Screenshot of bundled dictionary extensions that are not even installed (187.74 KB, image/png)
2016-12-14 11:23 UTC, Alex Thurgood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Zoltán Reizinger 2011-01-13 06:57:43 UTC
The extensions installed on LibO installation time cannot disabled through UI, at least on win7.
It is not possible even with administrator role.

The needs for disabling some extensions, could happen with report builder extension.

If you want to use "old" type report wizard, in OOo you disable report designer extension, run old report wizard, create report. Later you can allow report designer extension and create report with wizard based on report designer.
Comment 1 Rainer Bielefeld Retired 2011-01-21 00:03:16 UTC
@Zoltán:
Still a problem?
If yes, please contribute additional information:
- What extension(s) are we talking about? 
- What does "is not possible" mean? Locked symbol? No reaction? Error message?
Comment 2 Zoltán Reizinger 2011-01-21 00:50:18 UTC
All extensions locked and this cause that "Report builder" 1.2.1 extension can not be disabled to use "old" report wizard.
It is a RC3 problem.
Comment 3 Steven W 2011-01-21 11:08:20 UTC
Created attachment 42284 [details]
Screenshot from LibO's Extension Manager

I may know what's being spoken of here.  In LibO, Report Builder 1.21 from Oracle is showing up in the Extension manager.  I am not sure if this is installed from LibO or Oracle Open Office.  Does LibO detect OOo or Oracle Open Office extensions?  It's either installed with LibO or LibO is detecting it from another install.

I have attached a screenshot of LibO's Extension Manager.  As you can see, the extension is locked.  I believe Zoltán wishes to disable the extension and run a Wizard built-in to the program.

This is similar to what I am talking about here:

https://bugs.freedesktop.org/show_bug.cgi?id=33299
Comment 4 Björn Michaelsen 2011-12-23 11:44:30 UTC Comment hidden (obsolete)
Comment 5 Florian Reisinger 2012-08-14 13:58:10 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 6 Florian Reisinger 2012-08-14 13:59:27 UTC Comment hidden (obsolete)
Comment 7 Florian Reisinger 2012-08-14 14:04:03 UTC Comment hidden (obsolete)
Comment 8 Florian Reisinger 2012-08-14 14:06:16 UTC Comment hidden (obsolete)
Comment 9 Florian Reisinger 2012-08-16 16:18:50 UTC
Hmmm, I think that this is no bug, maybe wanted....

IMHO your enhancement is a great idea...
Comment 10 Rainer Bielefeld Retired 2012-08-16 16:34:30 UTC
Yes, it really might cause problems that you are forced to use bundled extensions instead of other ones you prefer. But currently there seems to be some decision that those extensions are more or less part of LibO and should not be unselectable in Extensions manager.

@Zoltán Reizinger:
Did you already try to unselect a bundled extension you dislike during installation?
Comment 11 Zoltán Reizinger 2012-08-16 17:15:59 UTC
I install LibO parallel to many version of AOO/LibO versions to test it under win7. I usually use msiexec/a installation_file.msi option which is not allows me to unselect extensions, I can live with this situation. 

But the original question was to disable report builder to allow creation of "old" type of reports, and enable later, to crate report-builder reports. 
  

If I remove it from installation, later I can not add it, because no report builder extension is available on LibO extension site, because it is bundled. :(
Comment 12 Benjamin Bach 2013-02-08 16:36:48 UTC
It was previously discussed how bundled extensions cannot be removed. However, the real issue should be that they cannot be *disabled*.

Of course, bundled extensions cannot be removed from LibreOffice, since they are system-wide installations and part of system package management.. so that makes sense.

Extension Manager currently does not live up to its name as it barely manages anything.

On a minor note:
Since all extensions are bundled upon first-run, the column of "lock" symbol icons is hard to intepret for a user, since there are no alternatives to the lock and it looks like a "secure" or "signed" icon.

Please have a look here at how the icons are simply locks all the way down:

http://ge.tt/7nr2CrX/v/0
Comment 13 Jean-Baptiste Faure 2014-05-01 21:50:14 UTC
(In reply to comment #11)
> [...]
> If I remove it from installation, later I can not add it, because no report
> builder extension is available on LibO extension site, because it is
> bundled. :(

Disagree: you can restart the installation in repair mode and reinstall the missing extension.

Best regards. JBF
Comment 14 Joel Madero 2014-11-02 16:38:43 UTC
Never confirmed by QA team, setting to UNCONFIRMED.
Comment 15 tommy27 2014-11-30 21:34:37 UTC
I think that a disable/enable feature to turn on/off bundled extensions at will is a legitimate enhancement request
Comment 16 Muhammet Kara 2016-11-19 05:11:10 UTC
Is there consensus on this request? If so, I may handle it while I am still working on the extension manager.
Comment 17 Yousuf Philips (jay) (retired) 2016-11-22 14:39:04 UTC
+1 from me as i dont see why i shouldnt be able to disable the bundled extensions that i would never use, like the french and spanish dictionaries, which i could build LO without.
Comment 18 Samuel Mehrbrodt (CIB) 2016-11-25 09:52:51 UTC
(In reply to Muhammet Kara from comment #16)
> Is there consensus on this request? If so, I may handle it while I am still
> working on the extension manager.

I see no problem with it.
Comment 19 Stephan Bergmann 2016-11-30 09:59:04 UTC
This bug dates from a time when LO routinely bundled quite a number of extensions.  That has changed significantly since:

* "Code-based" bundled extensions (incl. the report builder mentioned in comment 0, see bug 61950) have been moved into the code proper.  The only such extensions that appear to still be bundled routinely with LO installsets are nlpsolver and wiki-publisher (cf. 'git grep -e --enable-ext- distro-configs/LibreOffice*.conf').  Not sure what were the reasons to not either turn them into code proper too or drop them from installsets.

* Dictionaries are still distributed as bundled extensions.  The original rationale for that was that these could have different update cycles than LO (resp. OOo, at that time) itself, allowing an admin to update these extensions in an existing LO installation.

I'm not sure whether it is explicitly stated anywhere, but one obvious use case for bundled (and/or shared) extensions is to let an admin install an extension that enforces some feature (e.g., makes some configuration entry read-only) so that users cannot override it.  That use case would be negatively affected by allowing users to disable bundled (and/or shared) extensions.  (And the recently added safe-mode, <https://wiki.documentfoundation.org/ReleaseNotes/5.3#Safe_Mode>, may negatively affect this too; would need looking into.)

My suggestion would be to leave things as they are.
Comment 20 Muhammet Kara 2016-12-14 07:54:14 UTC
(In reply to Stephan Bergmann from comment #19)
> This bug dates from a time when LO routinely bundled quite a number of
> extensions.  That has changed significantly since:
> 
> * "Code-based" bundled extensions (incl. the report builder mentioned in
> comment 0, see bug 61950) have been moved into the code proper.  The only
> such extensions that appear to still be bundled routinely with LO
> installsets are nlpsolver and wiki-publisher (cf. 'git grep -e --enable-ext-
> distro-configs/LibreOffice*.conf').  Not sure what were the reasons to not
> either turn them into code proper too or drop them from installsets.
> 
> * Dictionaries are still distributed as bundled extensions.  The original
> rationale for that was that these could have different update cycles than LO
> (resp. OOo, at that time) itself, allowing an admin to update these
> extensions in an existing LO installation.
> 
> I'm not sure whether it is explicitly stated anywhere, but one obvious use
> case for bundled (and/or shared) extensions is to let an admin install an
> extension that enforces some feature (e.g., makes some configuration entry
> read-only) so that users cannot override it.  That use case would be
> negatively affected by allowing users to disable bundled (and/or shared)
> extensions.  (And the recently added safe-mode,
> <https://wiki.documentfoundation.org/ReleaseNotes/5.3#Safe_Mode>, may
> negatively affect this too; would need looking into.)
> 
> My suggestion would be to leave things as they are.

Is there any objection to this? Should we close the bug as WONTFIX?
Comment 21 Stephan Bergmann 2016-12-14 08:02:42 UTC
As there was no further input past comment 19, I'll close as WONTFIX now.  Feel free to reopen if there's new insights.
Comment 22 Alex Thurgood 2016-12-14 11:21:42 UTC
(In reply to Stephan Bergmann from comment #21)
> As there was no further input past comment 19, I'll close as WONTFIX now. 
> Feel free to reopen if there's new insights.

My ha'penneth worth is that currently on LibreOffice for MacOS, there is no way of removing the bundled dictionary stubs for the many *non-installed* languages which pollute the Extension Manager - see screenshot.
Comment 23 Alex Thurgood 2016-12-14 11:23:49 UTC
Created attachment 129626 [details]
Screenshot of bundled dictionary extensions that are not even installed
Comment 24 Alex Thurgood 2016-12-14 11:25:30 UTC
I would be inclined to re-open this bug as a result and set to OS(ALL)
Comment 25 Alex Thurgood 2016-12-14 11:30:58 UTC
The OSX dictionary stub bundled extension problem is known as bug 92226
Comment 26 Alex Thurgood 2016-12-14 12:03:14 UTC
Currently, in a production release of LO5233, I count 50 bundled dictionary extensions that are allegedly installed and displayed as such in the Extensions Manager, when in fact I have (and use) only 3.

This makes use of the Extension Manager even more painful, as having to scroll through the whole list of irrelevant entries is a PITA.
Comment 27 Alex Thurgood 2016-12-14 12:04:36 UTC
OK, I'll risk it for some flames - re-opening
Comment 28 Stephan Bergmann 2016-12-14 12:31:47 UTC
(In reply to Alex Thurgood from comment #26)
> Currently, in a production release of LO5233, I count 50 bundled dictionary
> extensions that are allegedly installed and displayed as such in the
> Extensions Manager, when in fact I have (and use) only 3.
> 
> This makes use of the Extension Manager even more painful, as having to
> scroll through the whole list of irrelevant entries is a PITA.

How is that relevant for this issue about /disabling/ bundled extensions?  Disabled extensions would not disappear from the Extension Manager.
Comment 29 Alex Thurgood 2016-12-14 13:40:10 UTC
(In reply to Stephan Bergmann from comment #28)


> How is that relevant for this issue about /disabling/ bundled extensions? 
> Disabled extensions would not disappear from the Extension Manager.

Having a visual cue corresponding to a disabled extension would vastly improve the UI experience in this regard, as I could simply ignore those that are disabled. Scrolling through the list would be faster, even if still painful. Even better would be a filter for disabled extensions, that allowed them to be hidden from view.
Comment 30 Samuel Mehrbrodt (CIB) 2016-12-14 14:22:09 UTC
(In reply to Alex Thurgood from comment #29)
> (In reply to Stephan Bergmann from comment #28)
> 
> 
> > How is that relevant for this issue about /disabling/ bundled extensions? 
> > Disabled extensions would not disappear from the Extension Manager.
> 
> Having a visual cue corresponding to a disabled extension would vastly
> improve the UI experience in this regard, as I could simply ignore those
> that are disabled. Scrolling through the list would be faster, even if still
> painful. Even better would be a filter for disabled extensions, that allowed
> them to be hidden from view.

A better solution might be to untick the checkbox for bundled extensions by default, so that only shared and user extensions are shown, unless you activate the bundled checkbox. Maybe even hide shared extensions by default.
Comment 31 Stephan Bergmann 2016-12-14 15:05:24 UTC
(In reply to Alex Thurgood from comment #29)
> (In reply to Stephan Bergmann from comment #28)
> Having a visual cue corresponding to a disabled extension would vastly
> improve the UI experience in this regard, as I could simply ignore those
> that are disabled. Scrolling through the list would be faster, even if still
> painful. Even better would be a filter for disabled extensions, that allowed
> them to be hidden from view.

But adding a visual cue for disabled extensions is not in the scope of this issue (about disabling bundled extensions).  If you see room for improvement after bug 92226 is eventually fixed, I'd suggest filing specific issues for that.
Comment 32 tommy27 2017-03-17 09:06:35 UTC
has an agreement about this issue been reached?
Comment 33 Stephan Bergmann 2017-03-17 09:14:59 UTC
So I'll re-close as WONTFIX based on comment 19 and comment 31.