Warnings, Restrictions, & Centralized Administration #97780

New Issue

Harley Acheson · 2022-05-02T19:05:45+02:00

Harley Acheson commented

2022-05-02 19:05:45 +02:00

With more organizations adopting Blender there is increasing need to simplify the deployment, maintenance, and administration of the program in large installations. This plan is meant to be a number of incremental steps that, once approved, I could implement myself. I have about 10 years of prior experience as a Domain Administrator on a network of approximately 600 users and 1000 computers in a Windows domain, and am familiar with the pitfalls and best practices.

Improved Warnings

This doesn't seem related, but is. I would like us to implement something like D10955: UI: Improved Operator Confirmations, which allow us to make warning dialogs much more easily than now that are also more informative, more customizable, and more differentiable. This way we can define many more than we have now to cover almost any situation where some users might want warnings, like when overwriting existing files or when files differ in version. We can define more because we'd also add the ability for users to easily enable/disable them.

Move Warning Configurations from Keymap to Settings

Right now the configuration of warnings is quite obscure, buried in the keymaps as an attribute of the entry. Most users will not be able to change the current warnings. I'd like to make a "Warnings" section in Settings with checkboxes to allow quick enabling and disabling of warnings.

Expose Factory Settings

Right now the default startup file and the factory preferences are only stored inside the executable. I'd like to optionally expose those for customization. Perhaps add a command-line argument to the executable that extracts copies of the embedded "default.blend" and "prefs.blend" to the install folder. These would be used instead, if present, in the same way that you can now override the splash image with a custom "splash.png".

In a large deployment you would put the blender installation folder in a shared read-only location that everyone would launch. That way you only have to install it once, not on every workstation. With this change you could, for example, change the fonts directory to be a shared network location. Change that in this one place and it becomes the default for everyone.

Add Restriction Settings

Like the "Warnings" section in Settings, I'd like to add "Restrictions". So checkboxes that, once enabled, restrict the user from doing some operations. For example to not allow the installation of addons. In a single-user installation this would not be used. But imagine an administrator setting these, along with warnings, and placing a "prefs.blend" file in the shared read-only network location of the Blender installation. It now means everyone on the network has the same defaults, warnings, and restrictions.

Project Settings

As another layer of granularity, allow putting these shared defaults and preference files within the folder path of blend files. So while loading any "blend" file we also look in its folder and parent folders for defaults and prefs. This way you can have per-project settings.

Platform Enhancements

During startup we are loading settings for settings, warnings, and restrictions. Once this is done we could also call platform-specific routines if they exist, like checking settings in the Windows Registry for example. This is all that is required to support Group Policy, so an Administrator can set a path for all user, allow some groups to add addons, and only leaders to change restrictions, etc.

With more organizations adopting Blender there is increasing need to simplify the deployment, maintenance, and administration of the program in large installations. This plan is meant to be a number of incremental steps that, once approved, I could implement myself. I have about 10 years of prior experience as a Domain Administrator on a network of approximately 600 users and 1000 computers in a Windows domain, and am familiar with the pitfalls and best practices. **Improved Warnings** This doesn't seem related, but is. I would like us to implement something like [D10955: UI: Improved Operator Confirmations](https://archive.blender.org/developer/D10955), which allow us to make warning dialogs much more easily than now that are also more informative, more customizable, and more differentiable. This way we can define many more than we have now to cover almost any situation where some users might want warnings, like when overwriting existing files or when files differ in version. We can define more because we'd also add the ability for users to easily enable/disable them. **Move Warning Configurations from Keymap to Settings** Right now the configuration of warnings is quite obscure, buried in the keymaps as an attribute of the entry. Most users will not be able to change the current warnings. I'd like to make a "Warnings" section in Settings with checkboxes to allow quick enabling and disabling of warnings. **Expose Factory Settings** Right now the default startup file and the factory preferences are only stored inside the executable. I'd like to optionally expose those for customization. Perhaps add a command-line argument to the executable that extracts copies of the embedded "default.blend" and "prefs.blend" to the install folder. These would be used instead, if present, in the same way that you can now override the splash image with a custom "splash.png". In a large deployment you would put the blender installation folder in a shared read-only location that everyone would launch. That way you only have to install it once, not on every workstation. With this change you could, for example, change the fonts directory to be a shared network location. Change that in this one place and it becomes the default for everyone. **Add Restriction Settings** Like the "Warnings" section in Settings, I'd like to add "Restrictions". So checkboxes that, once enabled, restrict the user from doing some operations. For example to not allow the installation of addons. In a single-user installation this would not be used. But imagine an administrator setting these, along with warnings, and placing a "prefs.blend" file in the shared read-only network location of the Blender installation. It now means everyone on the network has the same defaults, warnings, and restrictions. **Project Settings** As another layer of granularity, allow putting these shared defaults and preference files within the folder path of blend files. So while loading any "blend" file we also look in its folder and parent folders for defaults and prefs. This way you can have per-project settings. **Platform Enhancements** During startup we are loading settings for settings, warnings, and restrictions. Once this is done we could also call platform-specific routines if they exist, like checking settings in the Windows Registry for example. This is all that is required to support Group Policy, so an Administrator can set a path for all user, allow some groups to add addons, and only leaders to change restrictions, etc.

Harley Acheson self-assigned this 2022-05-02 19:05:45 +02:00

Harley Acheson commented

2022-05-02 19:05:45 +02:00

Changed status from 'Needs Triage' to: 'Needs Developer To Reproduce'

Harley Acheson commented

2022-05-02 19:05:45 +02:00

Added subscriber: @Harley

Harley Acheson commented

2022-12-06 17:57:49 +01:00

Added subscriber: @manuelgrad1

Harley Acheson commented

2022-12-06 18:02:37 +01:00

Blenderartists discussion involving a request for production-specific restrictions/warnings: https://blenderartists.org/t/what-is-the-most-bat-guano-insane-thing-in-blender-that-you-cant-believe-they-havent-fixed-yet/1300129/247

Manuel Grad commented

2022-12-06 19:03:21 +01:00

Added subscriber: @ManuelGrad

Robert S commented

2022-12-06 22:53:20 +01:00

Added subscriber: @RobertS

Robert S commented

2022-12-06 22:53:20 +01:00

Note sure if this is described using a wording I don't understand (not a native English speaker or an admin, really), so I just want to say that as I'm contemplating deploying Blender where I work (small deployment scale of 5-25 people, but who are not traditional 3D artists), it would be ideal if I could place the installer on one of our shared network folders, and have anyone who uses it automatically transfer a settings file, startup file, asset library locations, theme and most importantly plug-ins!

(In the meantime, I'm going to try a Powershell script to accomplish this, basically just copying a backup of my own %appdata%\Blender Foundation\Blender folder contents, perhaps.)

Note sure if this is described using a wording I don't understand (not a native English speaker or an admin, really), so I just want to say that as I'm contemplating deploying Blender where I work (small deployment scale of 5-25 people, but who are not traditional 3D artists), it would be ideal if I could place the installer on one of our shared network folders, and have anyone who uses it automatically transfer a settings file, startup file, asset library locations, theme and most importantly plug-ins! (In the meantime, I'm going to try a Powershell script to accomplish this, basically just copying a backup of my own %appdata%\Blender Foundation\Blender folder contents, perhaps.)

Alexey Adamitsky commented

2022-12-07 23:16:57 +01:00

Added subscriber: @AlexeyAdamitsky

Evan Wilson commented

2022-12-12 05:35:21 +01:00

Added subscriber: @EAW

Brecht Van Lommel commented

2023-01-16 15:47:16 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2023-01-16 15:47:16 +01:00

Regarding "Expose Factory Settings", "Add Restriction Settings" and "Project Settings", for me there is a bigger picture. There are 5 potential levels of preferences:

Blender default
Studio
Project (see D16288)
User
User per-project (?)

Having studio or project levels completely replace the Blender defaults and provide additional add-ons/assets is relatively straightforward in some way. There it's mainly a question of how to define it: using environment variables, files in the Blender install folder, putting files in the project folder (see D16288), some standard directory next to the regular users config files. Adding ability to override the default prefs.blend and startup.blend + revisiting how environment variables like BLENDER_SYSTEM and BLENDER_USER work I think could be a good direction here and similar to how some other apps work.

The user level less clear. We already know where to store it, but you need to either have an override mechanism, or a split up the preferences in some way that makes sense for users to be able to change some parts completely, or not change some parts at all. I think we need to look at it that way more than as "restriction", it's about where the data is stored.

An override mechanism is probably too complex a solution for users and developers in practice, but splitting things up in some natural way is also not obvious. We need more concrete examples of what would make sense to do here.

It may also be that there is some relatively small fixed set of settings that makes sense to override at the studio or project level, and give those special treatment rather than making a completely general system. For example an OpenColorIO config or enforcing of file/datablock naming conventions seems to naturally fit at the project level and it's not obvious this needs to exist at other levels.

Some data is additive, like installed add-ons or asset libraries. All levels can be added together for that case, though making it actually work requires changes as the list of asset libraries and which add-ons are enabled is stored in the single prefs.blend.

Another point to make is that a lot is possible through Python scripting. It's not an ideal solution, but you can have scripts running on load that ensure certain preferences are set, ensure a specific set of asset libraries is added, etc. With some utility module and documentation it could be quite powerful.

Regarding "Expose Factory Settings", "Add Restriction Settings" and "Project Settings", for me there is a bigger picture. There are 5 potential levels of preferences: * Blender default * Studio * Project (see [D16288](https://archive.blender.org/developer/D16288)) * User * User per-project (?) Having studio or project levels completely replace the Blender defaults and provide additional add-ons/assets is relatively straightforward in some way. There it's mainly a question of how to define it: using environment variables, files in the Blender install folder, putting files in the project folder (see [D16288](https://archive.blender.org/developer/D16288)), some standard directory next to the regular users config files. Adding ability to override the default prefs.blend and startup.blend + revisiting how environment variables like BLENDER_SYSTEM and BLENDER_USER work I think could be a good direction here and similar to how some other apps work. The user level less clear. We already know where to store it, but you need to either have an override mechanism, or a split up the preferences in some way that makes sense for users to be able to change some parts completely, or not change some parts at all. I think we need to look at it that way more than as "restriction", it's about where the data is stored. An override mechanism is probably too complex a solution for users and developers in practice, but splitting things up in some natural way is also not obvious. We need more concrete examples of what would make sense to do here. It may also be that there is some relatively small fixed set of settings that makes sense to override at the studio or project level, and give those special treatment rather than making a completely general system. For example an OpenColorIO config or enforcing of file/datablock naming conventions seems to naturally fit at the project level and it's not obvious this needs to exist at other levels. Some data is additive, like installed add-ons or asset libraries. All levels can be added together for that case, though making it actually work requires changes as the list of asset libraries and which add-ons are enabled is stored in the single prefs.blend. Another point to make is that a lot is possible through Python scripting. It's not an ideal solution, but you can have scripts running on load that ensure certain preferences are set, ensure a specific set of asset libraries is added, etc. With some utility module and documentation it could be quite powerful.

Brecht Van Lommel commented

2023-01-16 15:50:33 +01:00

About the other points:

Improved Warnings: agreed this should be improved.
Move Warning Configurations from Keymap to Settings: I would not consider tweaking of keymaps to have different warnings to be really a feature, it's just something that happens to be possible and not really used. So for me this is about adding new settings, and there's not really much to say without a specific proposal for which new settings are to be added and why. For example a preference to disable automatic folder creation in the file browser I don't think is a good use case, I'd rather consider removing that feature entirely.
Platform Enhancements: operating system specific mechanisms like the Windows registry or group policy I don't think we should integrate with, and as far as I know other 3D apps generally also do not. We need feature parity with Linux and macOS regardless, so we should implement something that can work across platforms. Of course it can be convenient for a Windows only studio if they already use such features, but I don't think the complexity / usefulness trade-off is right. In general I'm also not really convinced by the who is allowed to do what angle. If according to the file system some files can't be edited by the users, then reflecting associated editability in the Blender UI makes sense to me, but I'm not sure I would go further than that.

About the other points: * Improved Warnings: agreed this should be improved. * Move Warning Configurations from Keymap to Settings: I would not consider tweaking of keymaps to have different warnings to be really a feature, it's just something that happens to be possible and not really used. So for me this is about adding new settings, and there's not really much to say without a specific proposal for which new settings are to be added and why. For example a preference to disable automatic folder creation in the file browser I don't think is a good use case, I'd rather consider removing that feature entirely. * Platform Enhancements: operating system specific mechanisms like the Windows registry or group policy I don't think we should integrate with, and as far as I know other 3D apps generally also do not. We need feature parity with Linux and macOS regardless, so we should implement something that can work across platforms. Of course it can be convenient for a Windows only studio if they already use such features, but I don't think the complexity / usefulness trade-off is right. In general I'm also not really convinced by the who is allowed to do what angle. If according to the file system some files can't be edited by the users, then reflecting associated editability in the Blender UI makes sense to me, but I'm not sure I would go further than that.

Ray molenkamp commented

2023-01-16 15:57:47 +01:00

Added subscriber: @LazyDodo

Ray molenkamp commented

2023-01-16 15:57:47 +01:00

while I'm not against supporting group policies, there has to be a large stake holder interested in the feature for it to thrive and get to a mature state, I can't remember anyone even asking for it in my time with blender. I'm not entirely convinced "build it and they will come" applies to this use-case.

while I'm not *against* supporting group policies, there has to be a large stake holder interested in the feature for it to thrive and get to a mature state, I can't remember anyone even asking for it in my time with blender. I'm not entirely convinced "build it and they will come" applies to this use-case.

Iliya Katushenock commented

2023-01-16 16:00:37 +01:00

Added subscriber: @mod_moder

Iliya Katushenock commented

2023-01-16 16:00:37 +01:00

I seem to have seen requests for more group work in the company, in RCS. But there it was more likely than that of managing the level of access to different parts of the project.

Harley Acheson commented

2023-01-16 19:02:24 +01:00

Although I mention Windows Group Policies here, it really isn't a big part of it and no big deal if not done. I think my biggest point about it is that once the other things are done properly, adding support for Group Policies is very trivial.

Brecht Van Lommel commented

2023-01-16 19:36:52 +01:00

A concrete step here could be to introduce the following environment variables:

BLENDER_SITE_RESOURCES
BLENDER_SITE_CONFIG
BLENDER_SITE_SCRIPTS
BLENDER_SITE_DATAFILES

Files in these directories would be read-only for Blender, and would override defaults (startup.blend and prefs.blend) or add to (add-ons, keymaps, HDRIs, ..) the BLENDER_SYSTEM files.

I don't know if "site" is the best terminology, I've seen that term used for similar purpose but have not checked if there is something more standard.

There have also been proposals in the past to make BLENDER_USER environment variables a list of paths to achieve the same purpose, though I think it's good to have a distinction between read-only directories and user directories where Blender writes. BLENDER_SYSTEM also can't be used for that purpose without breaking compatibility or being inconvenient, because that currently is the the path to the files bundled with the Blender install. BLENDER_SITE variables could be a list of paths however. I'm not sure BLENDER_SYSTEM is really that useful in practice with current behavior at all and maybe had (some of) the same use cases as BLENDER_SITE behind it, but probably not worth breaking how that works.

Maybe we can provide other mechanism for such site paths for those who don't like to deal with environment variables, some standard location or a path specified in the user preferences. But that can be considered and added once the basic system is in place.

A concrete step here could be to introduce the following environment variables: * `BLENDER_SITE_RESOURCES` * `BLENDER_SITE_CONFIG` * `BLENDER_SITE_SCRIPTS` * `BLENDER_SITE_DATAFILES` Files in these directories would be read-only for Blender, and would override defaults (startup.blend and prefs.blend) or add to (add-ons, keymaps, HDRIs, ..) the `BLENDER_SYSTEM` files. I don't know if "site" is the best terminology, I've seen that term used for similar purpose but have not checked if there is something more standard. There have also been proposals in the past to make `BLENDER_USER` environment variables a list of paths to achieve the same purpose, though I think it's good to have a distinction between read-only directories and user directories where Blender writes. `BLENDER_SYSTEM` also can't be used for that purpose without breaking compatibility or being inconvenient, because that currently is the the path to the files bundled with the Blender install. `BLENDER_SITE` variables could be a list of paths however. I'm not sure `BLENDER_SYSTEM` is really that useful in practice with current behavior at all and maybe had (some of) the same use cases as `BLENDER_SITE` behind it, but probably not worth breaking how that works. Maybe we can provide other mechanism for such site paths for those who don't like to deal with environment variables, some standard location or a path specified in the user preferences. But that can be considered and added once the basic system is in place.

Brecht Van Lommel added

and removed

Needs Info from Developers

Priority

Normal