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.
@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?
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.
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
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
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
Hmmm, I think that this is no bug, maybe wanted.... IMHO your enhancement is a great idea...
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?
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. :(
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
(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
Never confirmed by QA team, setting to UNCONFIRMED.
I think that a disable/enable feature to turn on/off bundled extensions at will is a legitimate enhancement request
Is there consensus on this request? If so, I may handle it while I am still working on the extension manager.
+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.
(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.
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.
(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?
As there was no further input past comment 19, I'll close as WONTFIX now. Feel free to reopen if there's new insights.
(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.
Created attachment 129626 [details] Screenshot of bundled dictionary extensions that are not even installed
I would be inclined to re-open this bug as a result and set to OS(ALL)
The OSX dictionary stub bundled extension problem is known as bug 92226
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.
OK, I'll risk it for some flames - re-opening
(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.
(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.
(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.
(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.
has an agreement about this issue been reached?
So I'll re-close as WONTFIX based on comment 19 and comment 31.