# Adding a "settings admin" role **URL:** \ **Category:** Development\ **Created:** [May 7, 2025, 8:28pm UTC](https://farmos.discourse.group/t/adding-a-settings-admin-role/2295 "2025-05-07T20:28:17Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [May 7, 2025, 8:28pm UTC](https://farmos.discourse.group/t/adding-a-settings-admin-role/2295/1 "2025-05-07T20:28:17Z")
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](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](https://github.com/farmOS/farmOS/pull/714#issuecomment-1694492576)) 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](https://github.com/search?q=repo%3AfarmOS%2FfarmOS+config_permissions+language%3AYAML&type=code&l=YAML) 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. 🙂 ---
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [May 7, 2025, 8:33pm UTC](https://farmos.discourse.group/t/adding-a-settings-admin-role/2295/2 "2025-05-07T20:33:50Z")
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? - ?? ---
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [May 7, 2025, 8:38pm UTC](https://farmos.discourse.group/t/adding-a-settings-admin-role/2295/3 "2025-05-07T20:38:24Z")
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!) ---
**Author:** ![Symbioquine](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/symbioquine/32/284_2.png) [@Symbioquine](https://farmos.discourse.group/u/Symbioquine)\ **Post date:** [May 8, 2025, 12:27pm UTC](https://farmos.discourse.group/t/adding-a-settings-admin-role/2295/4 "2025-05-08T12:27:19Z")
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? ---
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [May 8, 2025, 5:14pm UTC](https://farmos.discourse.group/t/adding-a-settings-admin-role/2295/5 "2025-05-08T17:14:29Z")
> [@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](https://github.com/farmOS/farmOS/pull/714) (see comment: [Add an Account Admin role with permission to administer users and assign managed roles by mstenta · Pull Request #714 · farmOS/farmOS · GitHub](https://github.com/farmOS/farmOS/pull/714#issuecomment-1703048040)). 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”? 😆 ---
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [May 8, 2025, 5:15pm UTC](https://farmos.discourse.group/t/adding-a-settings-admin-role/2295/6 "2025-05-08T17:15:28Z")
> [@mstenta](#): > > “Settings Admin” feels weird? The more I say it, the less weird it feels. Maybe it should just be “Settings Admin”? 😆 ---
**Author:** ![Symbioquine](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/symbioquine/32/284_2.png) [@Symbioquine](https://farmos.discourse.group/u/Symbioquine)\ **Post date:** [May 8, 2025, 5:24pm UTC](https://farmos.discourse.group/t/adding-a-settings-admin-role/2295/7 "2025-05-08T17:24:07Z")
Maybe there’s an even better word. 🤔 “Settings Admin” feels a bit vague to me also. ---
**Author:** ![nununo](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/nununo/32/1860_2.png) [@nununo](https://farmos.discourse.group/u/nununo)\ **Post date:** [May 12, 2025, 10:18pm UTC](https://farmos.discourse.group/t/adding-a-settings-admin-role/2295/8 "2025-05-12T22:18:47Z")
Hello, Settings admin is not a tragedy for me 🙂 but here are some alternatives: - Configurator - Settings configuration - Settings manager - Settings manipulator 🙂 ---
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [May 14, 2025, 9:06am UTC](https://farmos.discourse.group/t/adding-a-settings-admin-role/2295/9 "2025-05-14T09:06:44Z")
> [@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. 🙂 ---
**Author:** ![gbathree](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/gbathree/32/286_2.png) [@gbathree](https://farmos.discourse.group/u/gbathree)\ **Post date:** [May 29, 2025, 3:19pm UTC](https://farmos.discourse.group/t/adding-a-settings-admin-role/2295/10 "2025-05-29T15:19:26Z")
+1 to System Administrator. That’s a known role (outside farmOS) and accurate IMO. ---
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [May 29, 2025, 5:47pm UTC](https://farmos.discourse.group/t/adding-a-settings-admin-role/2295/11 "2025-05-29T17:47:21Z")
What about “System Config Admin”? > [@gbathree](#): > > +1 to System Administrator. That’s a known role (outside farmOS) and accurate IMO I like the sound of this, but I think the fact that it has a specific meaning outside of farmOS is a non-starter, unfortunately. The connotation is that it provides full admin access (aka all Drupal permissions), which this role will not. So we need something that makes it clear that it’s for modifying system config/settings, but not full admin access. ---
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [May 29, 2025, 6:22pm UTC](https://farmos.discourse.group/t/adding-a-settings-admin-role/2295/12 "2025-05-29T18:22:05Z")
> [@mstenta](#): > > System Config Admin Or maybe just “Config Admin”? ---
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [November 24, 2025, 6:28pm UTC](https://farmos.discourse.group/t/adding-a-settings-admin-role/2295/13 "2025-11-24T18:28:19Z")
I opened a pull request that adds a new “Config Admin” role (and shifts some permissions to it from “Manager” and “Account Admin” roles). > > > Originally proposed here: https://farmos.discourse.group/t/adding-a-settings-adm…in-role/2295 > > This adds a new "Config Admin" (\`farm\_config\_admin\`) role specifically for granting access to manage certain farmOS configuration settings. > > The intention is similar to the existing "Account Admin" (\`farm\_account\_admin\`) - these roles are not enabled by default in farmOS, but a system administrator (with full Drupal user 1 access) can grant them to users in order to provide some higher-level permissions, without needing to grant full admin access. > > Previously, we were starting to overload the "Account Admin" role with permissions to things unrelated to user accounts (like the \`administer farm settings\` permission). > > This PR also shifts some of the "configuration" settings from the "Manager" role to the new "Config Admin" role. Therefore this is a breaking change because it removes some access from existing users. > > It does this by splitting the \`config\_permissions\` setting into \`config\_permissions\` and \`manager\_permissions\`. I took my best shot at splitting these in a way that makes sense, but curious to hear what others think. I decided I like the simplicity of “Config Admin” (`farm_config_admin`), especially when considered alongside the existing “Account Admin” (`farm_account_admin`) role. Both are simple, and convey their purpose, albeit both might benefit from a description in the UI to make it more explicit. I think this is true of all roles, so we can think about it in a followup. ---
**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\ **Post date:** [January 11, 2026, 10:26pm UTC](https://farmos.discourse.group/t/adding-a-settings-admin-role/2295/14 "2026-01-11T22:26:02Z")
[Add a Config Admin role for granting access to farmOS configuration by mstenta · Pull Request #1022 · farmOS/farmOS · GitHub](https://github.com/farmOS/farmOS/pull/1022) has been merged into `4.x`! 🎉