Created attachment 164552 [details] Cannot disable extensions installed by package manager How can I disable (not remove) Libreoffice extensions installed from Pamac like LanguageTool or TextMaths, because in extension manager the disable button is disabled. I use LanguageTool extension for both english and french with huge locally n-grams data (over 17.5GB) so the extension is expected to always slow down Writer while parsing the content of opened files. That’s why I want to disable it temporarily to have more speed for files that don’t need text verification. And I don’t have always internet, and even If I have it the fact to always download each time over 200MB to use LanguageTool extension is something fastidious. Operating System: Manjaro Linux KDE Plasma Version: 5.19.4 KDE Frameworks Version: 5.73.0 Qt Version: 5.15.0 Kernel Version: 5.8.0-2-MANJARO OS Type: 64-bit
On pc x86-64 with LO Debian test package, I could reproduce this. I installed "libreoffice-lightproof-en/testing" for example and indeed "Disable" button is disabled. Rene: Manjaro is based on Arch and I know you're more on Debian but thought you might be interested in this one since I could reproduce this on Debian.
then deinstall the package? (or rm -rf the extension if in doubt). I don't think this is a bug anywhere. Extensions installed by packages are supposed to be "deactivated" by deinstalling them. (especially for "bundled" extensions which lie there in the filesystem unpacked.)
(and yes, this requrires root rights - but installing that extension package required that too in the first place)
(In reply to Rene Engelhard from comment #2) > then deinstall the package? (or rm -rf the extension if in doubt). > > I don't think this is a bug anywhere. > > Extensions installed by packages are supposed to be "deactivated" by > deinstalling them. (especially for "bundled" extensions which lie there in > the filesystem unpacked.) This is really a bug because LibreOffice extension manager should handle deactivation/activation of any kind of installed extension even if they are installed via package manager. The package manager is only responsible for installing and uninstalling process. Many people like to disable some extensions temporary and enable them only when needed, especially for extensions with big size like LanguageTool with more 200MB.
(In reply to Rene Engelhard from comment #3) > (and yes, this requrires root rights - but installing that extension package > required that too in the first place) Uninstalling the extension is not the solution, because for a machine with multiple users, if instead of deactivating the extension for current user you remove it via package manager then it will be removed for all other users because it's shared between them.
And if that is what the admin of the system wants that's what the admin wants. Users are not supposed to mess with system-wide (and that's what packages do) installations. One could imagine some new feature which makes "don't activate this extension while installed", but that would be questionable imho. And in some cases the admin might want to force something on anyone (and be it config changes which also could be done via extensions). Bypassing what the admin wants is bad.
(In reply to Rene Engelhard from comment #6) > And if that is what the admin of the system wants that's what the admin > wants. > > Users are not supposed to mess with system-wide (and that's what packages > do) installations. > > One could imagine some new feature which makes "don't activate this > extension while installed", but that would be questionable imho. > > And in some cases the admin might want to force something on anyone (and be > it config changes which also could be done via extensions). Bypassing what > the admin wants is bad. I think you don't differentiate between disable and remove ? or you don't understand what I wrote ? Btw why are you are so eager to close this report ? I will explain to you the situation, suppose you have a Linux machine with 3 users (one admin and two normal users), if admin want to disable some extensions installed by package manager, should he remove them totally ? No ! this will remove the extension also for other users ! What the admin want is to disable temporary some extensions for only himself and other users should still have access to extensions.
> I think you don't differentiate between disable and remove ? or you don't > understand what I wrote ? No, you don't understand what I wrote and security. I explicitely wrote --- snip --- One could imagine some new feature which makes "don't activate this extension while installed", but that would be questionable imho. --- snip --- But then --- snip --- And in some cases the admin might want to force something on anyone (and be it config changes which also could be done via extensions). Bypassing what the admin wants is bad. --- snip --- remains. If a user can deactivate extensions deploying configuration by the admin this is VERY bad. Be it Macro Security settings or whatever else company-wide configuration. > Btw why are you are so eager to close this report ? Exactly because of the above and you don't get the distinction between admin and users which is a *fundamental concept*. Users don't get to mess with system-wide installed stuff. Period. We are not in Windows here. > I will explain to you the situation, suppose you have a Linux machine with 3 users (one admin and two normal users), So 2 users. > if admin want to disable some extensions installed by package manager, should he remove them totally ? No ! this will remove the extension also for other users ! > What the admin want is to disable temporary some extensions for only himself > and other users should still have access to extensions. ... as shown here. The admin himself has no LO use, no one should run LO as root. So what the admin does always affects users, not only him for LO. One always can install an extension locally for users (--shared wouldn't probably work either since uninstalling also would require root).
> ... as shown here. The admin himself has no LO use, no one should run LO as > root. So what the admin does always affects users, not only him for LO. admin is just a simple user (in this case it's me) who know root password and can use LO as other users without launching it with root privilege. root is just a role that an admin can acquire by specifying root password.
.. and packages are installed by root. root = admin. Whoever can become root or do root commands to do administrative task is irrelevant for this case here. Only relevant is who has the right to manage system-wide stuff: root - the admin.
This kind of bug reviewing is really ... Quality is not measured by number of closed reports/bugs but by users feedback, and should advance based on interaction with users suggestions and wishlist.
For avoidance of doubt: I don't care about bug numbers here or closed bugs numbers. What I *do* care about is principles and what belongs to the admin and what not. If the admin decides to install something talk to your admin. Or do administrative tasks yourself. And remove the package. (If your distro packages are not fine-grained enough, one could talk to them.) But don't try to bypass your admins' decisions by wanting to disable extensions the admin installs system-wide, be it shared or bundled or in a package for whatever reason.
Also note that for debugging there's the safe mode. (--safe-mode in command line.) Just tried: It also allows ignoring extensions.