# 6. Resource Lifecycle User Type: **Super Administrator** Source: *Mi Digital Academy - Education CRM Features Document* --- ## 6. Resource Lifecycle ### 6.1 Upload, Edit, and Delete Resources **What it does:** Manages the resource lifecycle actions: the Super Administrator uploads a resource to the library, edits it as it evolves, and deletes it when it is no longer needed. The upload is validated (format, size), the edit preserves the resource's identity, and the delete is guarded (the dependencies checked), so the library's resources are added, maintained, and removed cleanly. **Sub-features:** - Resource upload: the resource file uploaded to the library - Upload validation: the format and size checked on upload - Resource edit: the resource's content/metadata updated - Resource delete: the resource removed (with the dependency check) - Dependency check: the resource's references (the videos/topics it is assigned to) checked before delete - Resource list: the resources with their status and metadata - Audit logging of upload/edit/delete **Super Administrator User Journey:** 1. A new resource is ready. Super Admin uploads the resource file to the library; the platform validates the upload (the format is supported, the size is within the limit). 2. For a failing upload (an unsupported format or an oversized file), the upload is rejected with the specific reason; Super Admin obtains a corrected file and re-uploads. 3. Once uploaded, the resource appears in the list with its status and metadata, ready to be assigned. 4. For a resource that needs an update (a revised document), Super Admin edits it (the content/metadata updated); the change is recorded. 5. For a resource no longer needed (a superseded document), Super Admin initiates the delete; the platform runs the dependency check (the videos/topics it is assigned to). 6. If dependencies exist (it is assigned to a live video), the delete is blocked with the specific reason; Super Admin unassigns it first (or archives it), then deletes. 7. For a resource with no dependencies (an orphaned duplicate), the check passes; Super Admin confirms the delete and the resource is removed. 8. The upload, edit, and delete events are audit-logged with the resource, the actor, and the timestamp. **Rules & Edge Cases:** - The upload is validated (format, size); a failing file is rejected with the specific reason, not silently accepted. - An edit preserves the resource's identity (the assignment is not lost); only the content/metadata changes. - The delete is guarded by the dependency check; a resource with references is not deleted cleanly. - A blocked delete is resolved (unassign first, or archive); the dependency is handled, not ignored. - The resource list shows the status per resource; the library state is visible. - Upload/edit/delete is audit-logged with the resource, actor, and timestamp. ### 6.2 Assign Resources to Videos, Topics, and Subjects **What it does:** Connects resources to the learning structure: the Super Administrator assigns a resource to the videos, topics, and subjects it supports, so the resource is in the right place and is surfaced to the learners who need it. Assignment is what makes a resource part of the learning experience rather than an orphaned file in the library. **Sub-features:** - Resource assignment: a resource assigned to a video, topic, and subject - Multi-level assignment: the resource placed at the video, topic, and subject level as appropriate - Assignment validation: the target nodes exist and are active - Coverage view: the resources per video/topic/subject, so gaps are visible - Reassignment: moving a resource to the correct node where misplaced - Unassignment: removing a resource from a node (with the impact reviewed) - Audit logging of assignment changes **Super Administrator User Journey:** 1. A new resource is uploaded. Super Admin assigns it to its video, topic, and subject (the nodes it supports). 2. The assignment is validated: the target nodes exist and are active; an invalid node is flagged. 3. Saves; the resource is now in the learning structure and is surfaced to the learners in that context. 4. Reviews the coverage view: the resources per video/topic/subject, so a topic with no supporting resource is a visible gap. 5. For a resource misplaced at assignment (assigned to the wrong topic), Super Admin reassigns it to the correct node; the change is recorded. 6. For a resource that is no longer part of a topic (a syllabus change), Super Admin reviews the impact (learners who had it) and unassigns it; the impact is handled. 7. Confirms the assignment is complete: the resource is where it should be, and the coverage is adequate (no silent gaps). 8. The assignment changes are audit-logged with the resource, the nodes, and the timestamp. **Rules & Edge Cases:** - A resource is assigned to videos, topics, and subjects; the assignment places it in the learning structure. - The target nodes must exist and be active; an invalid node cannot be assigned. - The coverage view shows resources per node; a gap (a topic with no resource) is visible, not silent. - A reassignment moves the resource to the correct node; the change is recorded. - An unassignment is reviewed for impact (learners who had the resource) before it is done. - Assignment changes are audit-logged with the resource, nodes, and timestamp. ### 6.3 Version Control for Resources **What it does:** Keeps a version history for each resource: every significant change to a resource (a new file version, a metadata revision) is recorded as a version, so the resource's history is preserved and a prior version can be reviewed or restored. The Super Administrator maintains the version control so resource changes are traceable and reversible, and the learners always see the current version. **Sub-features:** - Version creation: a new version recorded when the resource changes significantly - Version record: the version's content, the change, the actor, and the timestamp - Version list: the versions of a resource in order - Version comparison: reviewing what changed between versions - Restore: reverting a resource to a prior version - Current version: the learners always see the current (latest) version - Audit logging of version create/restore **Super Administrator User Journey:** 1. A resource is updated (a revised document). Super Admin saves the change; the platform records a new version (the change, the actor, the timestamp). 2. Reviews the version list: the versions of the resource in order, so the history is visible. 3. For a change that introduced an error (a bad revision), Super Admin compares the versions (what changed between the current and the prior) to confirm the issue. 4. Restores the resource to the prior version; the resource reverts, and the restore is recorded as a new version (the history is not destroyed). 5. Confirms the current version: the learners always see the current (latest) version; a stale version is not shown. 6. For a resource with a long history, Super Admin reviews the key versions (the significant changes) to understand its evolution. 7. Reviews the version retention: the history is retained per the platform's policy (the older versions available for the retention period). 8. The version create and restore events are audit-logged with the resource, the version, and the timestamp. **Rules & Edge Cases:** - A version is recorded on a significant change; the version captures the change, the actor, and the timestamp. - A restore reverts to a prior version but is itself recorded (the history is append-only, not destroyed). - The learners always see the current (latest) version; a stale version is not shown. - Version comparison shows what changed between versions; it supports a confident restore. - The retention is per the platform's policy; older versions are available for the retention period. - Version create/restore is audit-logged with the resource, version, and timestamp.