Add support for configuration and add-on inheritance

[LeonarddeR]

In the current situation, it is not possible to share add-ons between profiles, unless you install them all into a profile explicitly. This means that add-ons will be on the system multiple times, which is undesirable in case of large add-on packages, such as Vocalizer voices.

Because of this, I propose a system of configuration inheritance which allows to setup a custom base line configuration in the all users profile or at least a folder only administrators have access to. IN this case, it is possible to setup a base line configuration with installed voices and add-ons all the users profiles can inherit from. I think it could be considered to make this base line configuration equal to the system configuration.

Several additional thoughts:

• Add-ons installed in the base line configuration should be unremovable
• Also, support for configuration profiles should be disabled in this configuration, since that would make the order of inheritance too complex.

[jcsteh]

Having a system wide location for add-ons makes sense and has been discussed a few times already. Many add-ons would need to be updated to support this, though; e.g. they can't just assume they can save configuration in their add-on directory. For this reason, I think we'll need a manifest flag indicating whether an add-on supports this and we should not allow it at all for add-ons which don't.

I don't think we want to implement your other points, though:

1. Inheriting from global configuration could be intrusive for users. Most NVDA settings are related to user preferences. I don't think it makes sense for a user to suddenly have a configuration they've been using for years changed due to a system wide change. We could perhaps use it as an initial configuration when a user first starts NVDA, though.
2. I don't think this should be equivalent to the system configuration. An admin might want an add-on to be available for all users, but that doesn't mean they want it to run on the secure desktop, as this could be a major security risk for some add-ons. See also my comment on Move system configuration to %programdata% #6824.

[LeonarddeR]

I think we'll need a manifest flag indicating whether an add-on supports this and we should not allow it at all for add-ons which don't. I agree, good point here. Inheriting from global configuration could be intrusive for users. Most NVDA settings are related to user preferences. I don't think it makes sense for a user to suddenly have a configuration they've been using for years changed due to a system wide change. We could perhaps use it as an initial configuration when a user first starts NVDA, though. Haven't thought about the latter point as an alternative, but I certainly agree that this would be ok as well. I don't think this should be equivalent to the system configuration. An admin might want an add-on to be available for all users, but that doesn't mean they want it to run on the secure desktop, as this could be a major security risk for some add-ons. So, do I understand it correctly that you do not want a central add-on storage to be available in the system config either? In that case, I'd say we can add an option to the general settings dialog where one can enable or disable the use of the central add-on storage. This option than can be force disabled in secure mode. Now I wonder, what would be the best way to implement such a storage? Initial thoughts: * Where do we want to save the add-ons? I vote for %programdata%\nvda\addons * How do we install these add-ons? I propose adding radio buttons to the add-on installation comfirmation prompt where one can select the installation target, either personal or global. These radio buttons should only be available to system administrators, and elevated privileges should be asked as soon as installation in the global storage has been chosen. An appropriate ACL should be set on the global NVDA storage folder. * How to deal with add-on removal? Either administrators do have the remove button and non-admins don't, or we add a separate button to the add-ons manages for this * How to deal with add-on duplicates? I'd say the local installation always has preference, even when the local add-on is older than the global one * How to deal with add-on updates? (re #3208) CC @josephsl, @derekriemer

[jcsteh]

I actually hadn't considered the need to specifically disable central add-on storage for the system config, though I agree this would be necessary. I'd rather we didn't have a check box for this, though; it seems rather ugly. Perhaps configs can just disable central add-ons, similar to the way they can disable add-ons now. Having a specific UI to install central add-ons is possible, I guess, but it will make things very complicated. It also doesn't allow the central default config to be updated. I'd suggest something similar to the button we have for copying the current config to the system config. That would also benefit from add-on selection if/when that gets implemented. Add-on updates are going to be very difficult to handle for central add-ons and I'd suggest we leave that out of any initial implementation.

[derekriemer]

We really might need an enterprise NVDA version. Has that been pondered as a separate product with advanced mass deployable features?

…

On Tue, Jan 31, 2017 at 5:33 PM, James Teh ***@***.***> wrote: I actually hadn't considered the need to specifically disable central add-on storage for the system config, though I agree this would be necessary. I'd rather we didn't have a check box for this, though; it seems rather ugly. Perhaps configs can just disable central add-ons, similar to the way they can disable add-ons now. Having a specific UI to install central add-ons is possible, I guess, but it will make things very complicated. It also doesn't allow the central default config to be updated. I'd suggest something similar to the button we have for copying the current config to the system config. That would also benefit from add-on selection if/when that gets implemented. Add-on updates are going to be very difficult to handle for central add-ons and I'd suggest we leave that out of any initial implementation. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6822 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFGivSxXEsunyG774u9neeH_RImovR-nks5rX9LzgaJpZM4LxVhn> .

-- Derek Riemer: Improving the world one byte at a time! - University of Colorado Boulder Department of computer science, 4th year undergraduate student. - Accessibility enthusiast. - Proud user of the NVDA screen reader. - Open source enthusiast. - Skier. Personal website <http://derekriemer.com>

[LeonarddeR]

Here is what I've done so far:

• Added inCentralStorage and supportsCentralStorage properties to the addonHandler.Addon class. The latter is based on a flag in the manifest file
• Renamed config.getSystemConfigPath to getCentralConfigPath. getSystemConfigPath did already return the program data folder and was used nowhere anyway
• Added central storage support to addonHandler._getDefaultAddonPaths
• Central add-ons are now visible in the add-on gui as such and can't be removed
• The possibility to copy the current user config to the central config

I haven't looked into storing drivers, plugins and app modules in the central config yet.

[JulienCochuyt]

Most NVDA settings are related to user preferences

Update and usage statistics -related settings are IMHO a good counter example.
These could be easily addressed by an add-on in the central storage, though.

I haven't looked into storing drivers, plugins and app modules in the central config yet.

I guess we can fairly handle the limitation of not having scratchpad support in the central storage.

@LeonarddeR, do you plan to publish your work in progress as a PR any soon?
We could really benefit from this feature for our mass deployment process in some corporate environments: cc @rthxy
Do you wish any assistance in rebasing babbage/i6822 onto latest master?

I think this issue should be renamed to something like "Support for central add-on storage"
ie. "configuration inheritance" seems now to be out of scope, and "add-on inheritance" might be thought as relating to the ability of an add-on to require or extend another add-on.