different plugins for different unprivileged users w/ one install?

[teknowledgist]

@gstavi
If there were a way for admins to effectively provide a library of optional plugins for users, that would be fantastic! Admins could review and deploy plugins that they trust/approve, and users could enabled those approved plugins within their use of NPP as they want/need.

Unfortunately, I don’t expect this will happen anytime soon.

[gstavi]

@teknowledgist
Make a feature request in Notepad++ project page

Technically it should not be very complicated.
Notepad++ during its startup scans for plugins and starts them. I am not sure if it is just a scan of “plugins” directory or if some configuration file is used.

Adding a pre-stage where Notepad++ reads a user configuration file (plugins.user.xml) that contains a list of plugins to skip should be easy enough.

[mkupper]

@gstavi
It seems that Notepad++ used to allow for both user and system plugins much like how you are proposing. Unfortunately, I can’t recall where on the Internet this is explained clearly as to how various historical versions of Notepad++ figured out which plugins to load. I do recall there was no explanation on that web page of why Notepad++ was changed.

[Coises]

@mkupper said in different plugins for different unprivileged users w/ one install?:

@gstavi
It seems that Notepad++ used to allow for both user and system plugins much like how you are proposing. Unfortunately, I can’t recall where on the Internet this is explained clearly as to how various historical versions of Notepad++ figured out which plugins to load. I do recall there was no explanation on that web page of why Notepad++ was changed.

See https://community.notepad-plus-plus.org/topic/16645/new-plugins-home-where-notepad-will-load-from/ and https://community.notepad-plus-plus.org/topic/16996/new-plugins-home-round-2

Have the Excedrin ready. :-(

[gstavi]

@mkupper said in different plugins for different unprivileged users w/ one install?:

It seems that Notepad++ used to allow for both user and system plugins

As I said in my first post here. Loading plugins (DLLs) from user folders is a security risk.
This proposal is different. Plugins are only loaded from administrator controlled folder (Program Files) but user can choose to avoid loading plugins he does not like.

[Coises]

@gstavi said in different plugins for different unprivileged users w/ one install?:

Plugins are only loaded from administrator controlled folder (Program Files) but user can choose to avoid loading plugins he does not like.

If this were to be done, it seems to me the sensible way would be to modify the Plugins Admin interface for ordinary users so it would show only the Available and Installed tabs, omitting the Update and Incompatible tabs. The list in Available would be limited to plugins already installed at the system level by an administrator, and Installed would show the plugins the user has enabled. That way the interface for non-administrative users in a controlled environment wouldn’t be all that different from the one for users who have control of their own machines. In my opinion, ordinary users should not be confronted with obscure configuration files.

Perhaps a simple way to control this would be the presence of any file (even an empty one) at %AppData%\Notepad++\plugins\enabled.xml. So long as that file is present, the “unprivileged user” interface is presented. (It doesn’t matter that a user could delete that file, because they still wouldn’t be able to install, remove or update plugins. They’d just have given themselves access to an interface that is useless to them.) So long as it’s not a problem to create an empty copy of that file for each new user (and one time, on introduction of the feature, for existing users), I think that would work. Administrators could get access to the full interface by temporarily renaming that file.

Whether there is enough desire for something like this to make a convincing case for that big a change is another question.

[gstavi]

@Coises
“Sensible” is such a personal concept.

Think of the plugin domain as 2 different layers:

• Install/uninstall
• Enable / disable -or- use / don’t use

The 2 concepts do not have to share a GUI. I will argue that separate administrative interface is better then unified interface that its features magically change.
Current plugin admin IS the administrative interface.
The 2nd interface is missing.

Today the layers are coupled, install=enable, disable=uninstall. You would want to maintain this property for backward compatibility since 99% of user want it that way.

Technically the only needed feature is disable. Any plugin that is not disabled is enabled by default. An enable/disable GUI can be designed to show all non-disabled plugins as enabled since this will be less confusing to users.

[Coises]

@gstavi said in different plugins for different unprivileged users w/ one install?:

Technically the only needed feature is disable. Any plugin that is not disabled is enabled by default. An enable/disable GUI can be designed to show all non-disabled plugins as enabled since this will be less confusing to users.

I agree that there are some advantages to the approach you suggest compared to what I proposed. While I feel that presenting an interface (Plugins Admin) to users which they cannot use isn’t ideal, locked-down users are probably used to that; and there would be a significant advantage of simplicity and predictability in not having Notepad++ behave differently depending on the presence or absence of an obscure file, as in my suggestion. And I can see how any user, including the typical single user with administrative rights, might sometimes want to disable a plugin without uninstalling it, so that would be an added feature.

I do see a problem with “the only feature needed is disable.” In the multiple users situation, when an administrator adds a new plugin at the request of one user, it will appear, probably unexpectedly, for every user until each user who does not want it disables it. I think the internal list should be a list of enabled plugins, not disabled plugins, to avoid unexpected behavior.

I think it would work if installing a plugin automatically added it to the list of enabled plugins for the user installing it. That would keep the expected behavior for both single users and multiple users.

Aside from whether to keep a list of enabled or disabled plugins, I think I agree that your solution is better than mine.

Would you make Enabled a new tab on Plugins Admin, or a whole new dialog?

Edit to add:

It seems like it belongs on the Installed tab, but I’m having a bit of trouble envisioning how it could be added without making the tab confusing. A question would be whether it would be necessary to restart Notepad++ to enable or disable plugins — it would be better if not, but I don’t know if that could leave some inconsistencies. The answer to that would affect the UI: we would want a clear confirmation button, like the existing Install/Update/Remove, if a restart is required, but simply toggling checkboxes would work if the new configuration can be applied on closing the dialog without a restart.

And over all of this is whether anyone is up for developing the pull request, and whether Don would accept it if they did.

[teknowledgist]

I don’t mean to make this more complicated, but from an educator/sysadmin point of view, it would be handy to be able to:

• force some plugins to be enabled
• set some plugins to be enabled by default but disable-able by users
• make some plugins disabled by default but enable-able by users.

However, I would be happy with only the enabled by default option. That would keep functionality closest to what it is for single users while allowing admins to deploy plugins.

[teknowledgist]

Feature Request made