Version #

Version 1

Module Type #

Standard

Internal Name #

userRights

Status #

Draft

Description #

In Version 1, the User Rights module governs detailed permissions (e.g., read-only, read/write) associated with each user role. Permissions are stored in a structured format (such as JSON) so the system can easily identify what each role can do with specific fields or system functionalities.

Because a user can have multiple roles, the module merges any overlapping permissions by comparing the roles” numeric indexes. If multiple roles specify different permissions on the same field, the highest-index role”s permission “wins.” If no role provides explicit permission for a given field or action, the system can fall back to a default policy (e.g., no access).

Administrative endpoints in this module handle creating, updating, and deleting role-based permission sets. All operations require proper Authentication via the Auth Module, and the system emits webhooks and logs changes for auditing and traceability.

This module has basic error handling.

User Journeys #

To be written.

Authentication #

Authentication for is managed via the Auth Module. Module-to-module communication in Version 1 does not require Authentication. Internal services can call the Admins Module freely.

Schema #

userRights #

Name	Type	Internal Name	Description
right_id	xxxxxUUID/String	userRights.userRights.right_id	A unique identifier for the rights configuration.
role_id	String	userRights.userRights.role_id	Associated user role (“Standard” in Version 1).
permissions	JSON	userRights.userRights.permissions	Defines the full access rights assigned for the role.

Functions #

Name	Endpoint	Description	Internal Name	Input	Response
createRight	/userRights/create	Creates a new rights configuration for a specific role.	userRights.CreateRight	{ “RoleID”: “role-1234”, “Permissions”: { “FirstName”: “read-only”, “Email”: “read/write” } }	{ “status”: “success”, “RightID”: “right-5678” }
updateRight	/userRights/update	Updates an existing rights configuration.	userRights.updateRight	{ “RightID”: “right-5678”, “Permissions”: { “FirstName”: “read/write”, “Email”: “read/write” } }	{ “status”: “success” }
deleteRight	/userRights/delete	Permanently deletes a rights configuration.	userRights.deleteRight	{ “RightID”: “right-5678” }	{ “status”: “success” }
getRight	/userRights/get	Retrieves the rights configuration for a specific role.	userRights.getRight	{ “RoleID”: “role-1234” }	{ “RoleID”: “role-1234”, “Permissions”: { “FirstName”: “read-only”, “Email”: “read/write” } }
listRights	/userRights/list	Lists all rights configurations, with support for pagination and filtering.	userRights.listRights	{ “page”: 1, “pageSize”: 20 }	{ “rights”: [ /* Array of rights objects */ ], “total”: 50 }

Webhooks #

Name	Trigger	Destination	Payload	Description	Error Handling
rightCreated	When the createRight function successfully creates a right.	Log Module	{ “event”: “rightCreated”, “timestamp”: “YYYY-MM-DDTHH:MM:SSZ”, “right”: { “RightID”: “right-XXXX”, “RoleID”: “role-XXXX”, “Permissions”: { /* permissions */ } } }	Notifies that a new rights configuration has been created.	None
rightUpdated	When the updateRight function successfully updates a right.	Log Module	{ “event”: “rightUpdated”, “timestamp”: “YYYY-MM-DDTHH:MM:SSZ”, “right”: { “RightID”: “right-XXXX”, “UpdatedFields”: { “Permissions”: { /* new permissions */ } } } }	Notifies that an existing rights configuration has been updated.	None
rightDeleted	When the deleteRight function successfully deletes a right.	Log Module	{ “event”: “rightDeleted”, “timestamp”: “YYYY-MM-DDTHH:MM:SSZ”, “right”: { “RightID”: “right-XXXX” } }	Notifies that a rights configuration has been deleted.	None
rightRetrieved	When the getRight function successfully retrieves a right.	Log Module	{ “event”: “rightRetrieved”, “timestamp”: “YYYY-MM-DDTHH:MM:SSZ”, “right”: { “RightID”: “right-XXXX”, “RoleID”: “role-XXXX”, “Permissions”: { /* permissions */ } } }	Notifies that a rights configuration has been retrieved.	None
rightsListed	When the listRights function successfully retrieves rights.	Log Module	{ “event”: “rightsListed”, “timestamp”: “YYYY-MM-DDTHH:MM:SSZ”, “rights”: [ /* Array of rights objects */ ], “total”: 50 }	Notifies that a complete list of rights configurations has been retrieved.	None

Settings #

Settings for the User Rights module are maintained in an internal key-value store and are stored in JSON format. These settings include:

• Default permission templates for new roles.
• Validation rules for permission levels (e.g., allowed values such as “none”, “read-only”, “read/write”).
• Pagination defaults for listing rights.
• Webhook configuration settings (URLs, retry policies, etc.).

Clarifications #

• Granular Control: Rights are defined at a field or functionality level, allowing very detailed permission control across the system.
• Role Aggregation: When a user is assigned multiple roles, the effective permission for each field is determined by comparing the rights of each role. The role with the highest index (i.e., highest priority) will dictate the final permission (for example, if one role grants read-only and a higher-priority role grants read/write, then the user receives read/write access).
• Separation of Concerns: The User Rights module operates separately from the User Roles module. While roles handle membership and grouping, rights explicitly define what actions and data fields are accessible.
• Administration: All functions to create, update, or delete rights configurations are intended for use by system administrators or processes with elevated privileges, ensuring that only authorized changes are made.
• Extensibility: The module is designed with future enhancements in mind; additional permission types and complex rules may be incorporated in later versions.
• Audit and Compliance: Changes to rights configurations are tracked and stored along with metadata for auditing and compliance purposes.