Content
View differences
Updated by Rosanna Sibora 3 days ago
Main goal:
Enable system administrators to centrally define, manage, and assign schemas for work package types - ensuring consistency, reducing configuration overhead, and allowing governance across all projects.
It's to be defined if we use the wording of "schemas" within OpenProject. The goal is to address the need users have. The concept for schemas in general need to be defined first.
* A central schema repository exists in the Administration panel where schemas can be created and managed independently of individual work package types
* A schema defines: visible attributes, their order, groupings, required/optional status
* Schemas can be assigned to one or more work package types
* Multiple work package types can share the same schema
* Changes to a central schema are automatically propagated to all work package types using it
* Global administrators should define per project if project admins are allowed to overwrite the schemas
* Project administrators can override a centrally managed schema at the project level if allowed
* \[open point\]: once s schema was overwritten on project level, how do we handle global governance / configuration? To be verified with users.
* A default schema can be defined and applied to new work package types automatically
* Audit log entries are created when a schema is modified
* API endpoints are available to manage schemas programmatically
Enable system administrators to centrally define, manage, and assign schemas for work package types - ensuring consistency, reducing configuration overhead, and allowing governance across all projects.
It's to be defined if we use the wording of "schemas" within OpenProject. The goal is to address the need users have. The concept for schemas in general need to be defined first.
* A central schema repository exists in the Administration panel where schemas can be created and managed independently of individual work package types
* A schema defines: visible attributes, their order, groupings, required/optional status
* Schemas can be assigned to one or more work package types
* Multiple work package types can share the same schema
* Changes to a central schema are automatically propagated to all work package types using it
* Global administrators should define per project if project admins are allowed to overwrite the schemas
* Project administrators can override a centrally managed schema at the project level if allowed
* \[open point\]: once s schema was overwritten on project level, how do we handle global governance / configuration? To be verified with users.
* A default schema can be defined and applied to new work package types automatically
* Audit log entries are created when a schema is modified
* API endpoints are available to manage schemas programmatically