51 lines
3.0 KiB
Markdown
51 lines
3.0 KiB
Markdown
---
|
|
title: "OneAdmin Framework Behavior"
|
|
type: OpenSpec
|
|
status: Draft
|
|
domain: OneAdmin
|
|
---
|
|
|
|
# OneAdmin Framework Behavior
|
|
|
|
## Requirement Definition
|
|
OneAdmin is the application framework upon which all OLS administration functions are built. It defines the standard behavior for data maintenance, record lifecycle states, search capabilities, and audit trailing across all modules (e.g., Campaign Management, Customer Management, Catalogue).
|
|
|
|
## Business Rules
|
|
|
|
### Maintenance Actions
|
|
The framework supports the following standard maintenance actions across modules:
|
|
- **Add**: Creates a new record in a Pending state.
|
|
- **Edit**: Modifies an existing record. The modifications are saved as a new version in a Pending state, leaving the original active record unchanged until approval.
|
|
- **Copy**: Duplicates an existing record, prompting the user to update unique key values.
|
|
- **Delete**: Marks a record for deletion (Inactive). The deletion request creates a Pending state version.
|
|
- **Approve**: Transitions a Pending record to Active state. The approving user must have appropriate approval rights and cannot be the user who submitted the change.
|
|
- **Reject**: Transitions a Pending record to a Rejected state for follow-up.
|
|
- **Save as Draft**: Temporarily saves the record without publishing it to a Pending state.
|
|
- **Save as Template**: Saves the record details to be reused as a template.
|
|
- **History**: Retrieves previous versions of a record.
|
|
|
|
### Record State Transitions
|
|
1. **Pending**: When a new record is added, edited, or deleted, the action results in a Pending state.
|
|
2. **Active**: Upon approval, a Pending record becomes Active. Only Active records are considered during transaction processing.
|
|
3. **Rejected**: If an approver rejects a Pending record, its state becomes Rejected.
|
|
4. **Inactive**: An approved deletion sets the record to Inactive, blocking it from further use.
|
|
|
|
### Search and Filtering Capabilities
|
|
- **Quick Search**: Keyword-based search applied to all character columns using a case-insensitive "Contains" operator.
|
|
- **Advanced Filter**: Allows compound criteria using AND logic. Supported operators vary by data type:
|
|
- **Character**: Equal, Not Equal, Empty, Not Empty, Contains, Not Contains, In, Not In.
|
|
- **Number**: Equal, Not Equal, Greater Than, Less Than, Greater Than Or Equal To, Less Than Or Equal To, Between.
|
|
- **Boolean**: Equal.
|
|
- **DateTime**: Equal, Not Equal, Greater Than Or Equal To, Less Than Or Equal To, Between.
|
|
|
|
### Audit Logging
|
|
Every record update or approval is logged. The following audit fields are maintained for all records:
|
|
- **Last Updated By**: User ID (or Batch ID) that last updated the record.
|
|
- **Last Updated Date**: Date and time of the last update.
|
|
- **Last Approved By**: User ID that last approved the record.
|
|
- **Last Approved Date**: Date and time of the last approval.
|
|
|
|
## Post-Conditions
|
|
- All updates are reflected in the database immediately upon approval.
|
|
- Concurrent edits and approvals are strictly logged and version-controlled.
|