Adding a "settings admin" role

[mstenta]

Today @paul121 and I were discussing the need for a new dedicated role in farmOS for “administering farmOS settings”. I’ll try to document the thinking here so we can open this up to feedback/brainstorming…

Context: from the beginning, farmOS has provided three default roles: Manager, Worker, and Viewer. The Manager and Worker roles are very similar - both can view/edit/delete all records, but historically the Manager role has been granted some additional “configuration” permissions. The Viewer role can view all records, but can’t change anything.

Then, in farmOS 2.x we added the “Account Admin” role, with the primary purpose of managing users logins. Managers couldn’t do this, so it was only available to sitewide (Drupal) admins. In Farmier I provided an “Account Admin” role for this purpose, which I then contributed back to core and we merged via this PR: https://github.com/farmOS/farmOS/pull/714

Notably, we also added the administer farm settings permission to that role, even though it didn’t quite fit the purpose. I noted this in the PR:

this role ALSO adds the administer farm settings permission. This is a carry over from Farmier, and it sort of stretches the purpose of this module, so curious if we should rethink that or not. As it stands now, the administer farm settings permission is not added to any managed roles, so it’s up to the host to decide who gets it. Feels like it makes sense to be in this “Account Admin” role to me, but open to feedback on that.

(Add an Account Admin role with permission to administer users and assign managed roles by mstenta · Pull Request #714 · farmOS/farmOS · GitHub)

This administer farm settings permission doesn’t make sense to assign to Manager roles, because it grants access to change things like the name of the farmOS instance (the farm name), the system of measurement (imperial/metric), etc. It’s more “admin”-y in that way.

But we don’t have an “admin” role other than Account Admin right now, unless you are self-hosting and you have access to Drupal user 1 - but Farmier does not allow access to that, nor should any “hosted” farmOS service. Hence this forum topic.

The way we currently grant “configuration” permissions to the Manager role is via the config_permissions option provided by the farm_role module, which provides our concept of “Managed roles” (roles whose permissions are assigned automatically via PHP logic rather than by manually clicking all the boxes in the Drupal role/permission array).

This shows which permissions are currently assigned to Manager roles that way: Code search results · GitHub

A quick copy+paste at the time of this writing:

• access taxonomy overview
• access data_stream_notification overview
• create data_stream_notification
• delete data_stream_notification
• update data_stream_notification
• view data_stream_notification
• administer quantity
• access farm import index
• access farm report index
• administer field_module
• administer farm notification
• access farm setup
• create quick_form
• update quick_form
• administer quick_form

So maybe the next step here is reviewing those and asking “should Managers have these permissions”?

Another question is: “should we rename the config_permissions property”? It’s sort of a confusing name… it traces back to this idea that “Managers have more access to configuration than Workers”… which we then split from the “Manager” role specifically in 2.x and made this concept of config_permissions, which the Manager role received (but others could too potentially). And now we are talking about trying to meet the need for another level… above Manager, for site-wide configuration.

These would be breaking changes, no doubt… and I’m not sure if we have the capacity to make them happen in 4.x, so this might be aspirational. But maybe there’s an elegant solution and everything will fall into place easily! Let’s see what others think.

[mstenta]

Another question: if we added a new role, what should it be called?

• “Admin” isn’t good because it would potentially conflict with “Business Admin” roles on a farm.

• “Site Admin” has the same problem. “Site” can mean “physical location” in a farm context.

• “farmOS Admin” isn’t good because farmOS gets used for things that are not called “farmOS” (that are just “Powered by farmOS”) so including that in the role name won’t work.

• “Settings Admin” feels weird?

• ??

[mstenta]

I forgot to mention, what kicked this off originally was @BOTLFarm noticed that the administer farm map permission isn’t currently assigned to any default farmOS roles! Which kicked off my thinking into where it should go…

We could add it alongside administer farm settings in the Account Admin role, but that further “stretches” the original purpose of that role (user management). So it feels like we need another role for administer farm settings and administer farm map at the very least.

Side note: @wotnak’s Custom Map Layers module grants its own manage custom map layers to Manager roles via the config_permissions option, but since its nested under /farm/settings/map, Managers can’t see it because they don’t have the administer farm map permission. So that’s the other side of all this: providing clear and consistent guidance and best practices for contrib module maintainers (thank you again for the awesome module @wotnak!)

[Symbioquine]

I agree that it is probably a mistake to keep letting the scope of the “Account Admin” role creep - at least as-is.

If we mostly ignore the naming, then we can explore the pros/cons of having a distinction between the role that can modify accounts and the role that has these other configuration permissions.

Separate roles:

• Pro: Allows for scenarios where a farm might actually have two different sets of people “in” each role and wants to keep access to those things separate.
• Pro: Configuring accounts probably needs to occur more frequently than modify the other config, so from a least privilege perspective it would make sense to only use a role that has those configuration permissions more rarely. (i.e. only when needed) To enable that, farmOS should ship with 2 distinct roles.
• Con: Further complicates the mental model of “who can do what” in farmOS.
• Con: Presumably adds some minimal ongoing code maintenance cost to farmOS. (i.e. requires more actual lines of php/yaml)

A single role:

• Pro: May tend to better represent the reality where - in most farmOS instances - the same person will be in charge of both of these kinds of things.
• Pro: Keeps the existing mental model complexity for “who can do what” in farmOS.
• Pro: Probably a lighter-weight code change - either none or just a naming change.
• Con: Disregards the principle of least privilege for simplicity.
• Con: Could become a “kitchen sink” for new permissions that really should be assigned at a finer granularity.
• Con: Even the best naming will tend to be less “self documenting” since there’s just “less name” involved .

@mstenta

if we added a new role, what should it be called?

• Instance Admin?
• Domain Admin?

@mstenta

These would be breaking changes, no doubt… and I’m not sure if we have the capacity to make them happen in 4.x, so this might be aspirational. But maybe there’s an elegant solution and everything will fall into place easily! Let’s see what others think.

As a thought exercise…

How terrible would it be to proceed with just the renaming approach if that was a small enough change to make it into farmOS 4.x?

Would it be too much churn to do that with the idea that perhaps an “account/personnel admin” role might be re-added in a future version if there is demand?

[mstenta]

@Symbioquine

• Pro: Allows for scenarios where a farm might actually have two different sets of people “in” each role and wants to keep access to those things separate.
• Pro: Configuring accounts probably needs to occur more frequently than modify the other config, so from a least privilege perspective it would make sense to only use a role that has those configuration permissions more rarely. (i.e. only when needed) To enable that, farmOS should ship with 2 distinct roles.

Yea, these sum up my reasoning for wanting two separate roles, and the maintenance cost of an additional role is very minimal IMO. We can copy and paste the farm_role_account_admin module and make minor modifications for this.

Configuring accounts probably needs to occur more frequently than modify the other config

This bit specifically is what really drives it home for me. I’m thinking about Farmier, where the instance is initially created by one person. They set the farm name, system of measurement, etc at that point in time, and so it makes sense that they would get the “Settings Admin” role (or whatever it’s called) AND the “Account Admin” role so they can create new users. They might want to delegate the “Account Admin” role to others at that point, without also giving them the ability to change the farm name etc.

This also reminds me of the “Allow peer role assignment” setting we added in Add an Account Admin role with permission to administer users and assign managed roles by mstenta · Pull Request #714 · farmOS/farmOS · GitHub (see comment: Add an Account Admin role with permission to administer users and assign managed roles by mstenta · Pull Request #714 · farmOS/farmOS · GitHub). Currently in Farmier, I’m the only one who can turn that on and off, which means if someone wants it they have to ask me for it. If we added the “Settings Admin” role, separate from the “Account Admin” role, we could grant access to that setting, without allowing “Account Admin” role users to change it themselves.

@Symbioquine

Pro: May tend to better represent the reality where - in most farmOS instances - the same person will be in charge of both of these kinds of things.

I’m curious about this, and we don’t really have great metrics - but it’s important to note that both of these roles (Account Admin and this hypothetical new one) are NOT installed by default. They are only necessary if the “instance maintainer” is sufficiently separate from the end users of farmOS, aka in the case of hosting services like Farmier. For a small self-hosted instance, these roles are not necessary, because the person hosting the instance can also manage users and configuration (since they have access to the super admin user).

@Symbioquine

How terrible would it be to proceed with just the renaming approach if that was a small enough change to make it into farmOS 4.x?

Would it be too much churn to do that with the idea that perhaps an “account/personnel admin” role might be re-added in a future version if there is demand?

It feels to me that if there’s any chance that we might want two roles in the future, then we should just create the new one now, and keep the “Account Admin” role named as-is, to avoid another breaking change. Then, when upgrading to farmOS 4.x, the site admin can decide if they want to enable the new roles or not, since it’s in its own module.

@Symbioquine

• Instance Admin?
• Domain Admin?

“Instance Admin” isn’t too bad… or maybe “least bad” of all the other choices so far. But I can already hear the question: “what the heck is an instance”?

[mstenta]

@mstenta

“Settings Admin” feels weird?

The more I say it, the less weird it feels. Maybe it should just be “Settings Admin”?

[Symbioquine]

Maybe there’s an even better word. “Settings Admin” feels a bit vague to me also.

[nununo]

Hello,

Settings admin is not a tragedy for me but here are some alternatives:

• Configurator
• Settings configuration
• Settings manager
• Settings manipulator

[mstenta]

@nununo

Settings admin is not a tragedy for me but here are some alternatives:

“Settings manager” is kind of nice.

“System administrator” is another that came to mind, although it has a specific meaning in IT generally.

@paul121 made a good point in our conversation: we could (and should) improve how we document these potential roles in the UI to make it easier to understand what they are for and what access they provide. Doing so would take a little of the pressure off the role name itself.