Rethinking administration: connecting permissions, resources and settings
From an administrative perspective, the system already provides a wide range of capabilities:
- ACL / permission handling
- default permissions
- module configuration
- group and user management
- user-level settings
The issue is not missing functionality.
The issue is that these capabilities are not presented as a connected system.
Current situation
Administration is spread across multiple entry points into what is essentially the same underlying model:
- Default permissions
- Module permissions
- Group permissions
- User-specific settings
- Permission overview
- Module-specific configuration dialogs
Each of these works in isolation.
However, they do not form a coherent administrative model.
As a result:
- administrators must switch contexts to complete a single task
- each interface shows only a partial view
- relationships between permissions, resources and settings remain implicit
- there is no single place that represents the effective state
This creates the impression of fragmentation even though the underlying functionality is already present.
ACL-centric, but not system-centric
The current model is heavily ACL-centric.
This provides flexibility, but introduces cognitive complexity:
- permissions are managed in multiple places
- there is no consolidated representation
- administrators must mentally combine different views
The system is powerful, but not intuitive.
Settings are not part of the same model
A major inconsistency is how settings are handled.
While permissions are flexible and widely exposed, settings are:
- mostly user-level
- defined in multiple places (user, module, defaults)
- not centrally manageable
- not inheritable across contexts
- not visible as part of a unified system
This creates a structural mismatch:
- permissions follow a distributed but flexible model
- settings follow a fragmented and mostly local model
As a result, administrators cannot:
- define consistent behavior across groups or the entire instance
- enforce settings where required
- understand how a final configuration is derived
What this looks like in practice
Typical workflows become harder than necessary:
- assigning resources (e.g. calendars) to users or groups is not clearly possible from a central admin context
- resource availability (especially for synchronization like ActiveSync, CalDAV, CardDAV) depends on where and how it was created or assigned
- module settings, defaults and permissions are configured in different places without a shared structure
- settings cannot be defined centrally and inherited
- it is difficult to understand why a user has access to a specific resource or configuration
The system is functional but not self-explanatory.
If I was to rethink this
The goal would not be to add new features, but to make the existing system understandable as a whole.
1. Establish a clear hierarchy
Instance → Tenancy → Group → User
All configuration (permissions, resources, settings) should follow this structure.
2. Use one consistent model for everything
Permissions, resources and settings should follow the same principles:
- inheritance (top-down)
- override (optional)
- enforcement (optional lock)
3. Make inheritance explicit
At any point it should be visible:
- where a value comes from
- whether it is inherited or overridden
- what the effective result is
4. Treat settings as a first-class system
Settings should follow the same model as permissions:
- definable at instance, group and user level
- inheritable across levels
- optionally enforceable
- centrally manageable
- visible in aggregated form
Example:
Setting: "Default calendar view"
Instance:
Group:
User:
Effective:
- value: day
- source: user (override)
5. Enable central resource provisioning
Resources (e.g. calendars, address books) should be assignable:
- from an admin context
- to users and groups
This should:
- propagate deterministically
- work reliably with synchronization (ActiveSync, CalDAV, CardDAV)
Proposal: Permissions & Settings Hub
Introduce a unified administrative interface that connects existing functionality.
Goals
- one place to view, assign and understand:
- permissions
- resources
- settings
- eliminate context switching
- make effective state visible
Core features
-
Perspective switch
User / Group / Resource / Module
-
Effective view
- effective permissions
- effective settings
- source (instance / group / user)
- override state
-
Central resource assignment
- assign calendars, address books etc.
- deterministic propagation
-
Unified permission model
- consistent ACL handling across modules
-
Settings inheritance
- define settings at instance / group / user
- allow override
- allow enforcement
-
Defaults vs policies
- defaults = initial values
- policies = enforced constraints
-
Filtering & bulk operations
Summary
The system already provides powerful building blocks.
The main issue is that these blocks are not presented as a connected system, but as separate administrative entry points.
A unified model for:
- permissions
- resources
- settings
combined with a central “Permissions & Settings Hub”
would make administration:
- predictable
- transparent
- self-explanatory
without reducing flexibility.
Mockup
Rethinking administration: connecting permissions, resources and settings
From an administrative perspective, the system already provides a wide range of capabilities:
The issue is not missing functionality.
The issue is that these capabilities are not presented as a connected system.
Current situation
Administration is spread across multiple entry points into what is essentially the same underlying model:
Each of these works in isolation.
However, they do not form a coherent administrative model.
As a result:
This creates the impression of fragmentation even though the underlying functionality is already present.
ACL-centric, but not system-centric
The current model is heavily ACL-centric.
This provides flexibility, but introduces cognitive complexity:
The system is powerful, but not intuitive.
Settings are not part of the same model
A major inconsistency is how settings are handled.
While permissions are flexible and widely exposed, settings are:
This creates a structural mismatch:
As a result, administrators cannot:
What this looks like in practice
Typical workflows become harder than necessary:
The system is functional but not self-explanatory.
If I was to rethink this
The goal would not be to add new features, but to make the existing system understandable as a whole.
1. Establish a clear hierarchy
Instance → Tenancy → Group → User
All configuration (permissions, resources, settings) should follow this structure.
2. Use one consistent model for everything
Permissions, resources and settings should follow the same principles:
3. Make inheritance explicit
At any point it should be visible:
4. Treat settings as a first-class system
Settings should follow the same model as permissions:
Example:
Setting: "Default calendar view"
Instance:
Group:
User:
Effective:
5. Enable central resource provisioning
Resources (e.g. calendars, address books) should be assignable:
This should:
Proposal: Permissions & Settings Hub
Introduce a unified administrative interface that connects existing functionality.
Goals
Core features
Perspective switch
User / Group / Resource / Module
Effective view
Central resource assignment
Unified permission model
Settings inheritance
Defaults vs policies
Filtering & bulk operations
Summary
The system already provides powerful building blocks.
The main issue is that these blocks are not presented as a connected system, but as separate administrative entry points.
A unified model for:
combined with a central “Permissions & Settings Hub”
would make administration:
without reducing flexibility.
Mockup