Change history

[mikedawson]

Jenkins Status

As a user I want audit logs so that I can see a history of any data changes and who made the changes.

User flows:

• User wants to see the history of changes made (any data they have access to) on learning units (lessons, assignments, playlists), class, person, enrollment, content Metadata.
• Each change line needs to include the date and time stamp, who made the change/person name, previous value, and new value.

Prototype here

Behavior notes:

1. Draft descriptions for change descriptions (initial version as from Slack):

PERSON:
When created: Created (First name = 'bob, Last name = 'Jones', Gender='Male', Username = ) show the value of each field
When modified: Changed (First name from 'Bob' to 'Robert'): list each field that has changed with the new value and the old value
When deleted: Deleted (First name = 'bob, Last name = 'Jones', Gender='Male', Username = '): show the value of all fields as it was when deleted 

CLASS (including enrollment changes): 
When created/modified: same behavior as per person
When student or teacher enrolled : (Student/teacher) enrolled : (First name = 'Bob', Last name ='Jones' username = 'username', start date = 09/Mar/2026): Show role, then the student/teacher's first name, last name, and username. 
When enrollment modified: Enrollment modified for First name = 'Name' Last name = 'Name', username='username': Changed (Start date from 09/Mar/2026 to 01/Mar/2026)
Enrollment requested: First name = 'Bob', Last name ='Jones' username = 'username', start date = 09/Mar/2026)
Enrollment <approved/rejected>: First name = 'Bob', Last name ='Jones' username = 'username', start date = 09/Mar/2026)

Playlist removed until this functionality is available in main branch.

Implementation notes:

• The logic to determine changes should go in the store function. The store function can find the previous version (if any). Then generate a ChangeHistoryEntry:

table:
uid:
timestamp:
who:
changes: [
   field: id/enum (e.g. id for first_name, last_name etc).
   newVal: (string)ing sent.
   oldVal: (string?)
]

• The function that sends to server (DrainRemoteWriteQueue) : needs to look for change history entries for the data being sent. The change and the ChangeHistoryEntry must go at the same time in the same request to the server. There may be multiple ChangeHistoryEntry(s) to send for a single piece of data if multiple changes were made offline.
• there will be need to be functions that generate a ChangeHistoryEntry given two entities (the current one, and the new one).
• Expected: The ChangeHistory will have a datasource that will be read-only : so changes made can be retrieved as normal, but storing them is done only by the other relevant datasources (e.g. Person, Class, etc).
• Permissions: permission to see the change history should be the same as seeing the entity itself e.g. if you can see the person, you can see the change history of the person. If you can't see the person, you can't see the change history for that person.

[mikedawson]

@akshattak I think the design needs revision to meet prototype guidelines e.g.

• Consistency: we use the word "Revision history" on a button, but when clicked the screen title is "Audit log"
• Ambiguity: it's not clear in the prototype or task card which data types are going to have revision history e.g. learning units (lessons), people, classes, enrollments? Also not clear: what exactly is going to show in the change log (one line includes the field name, another does not). I think each change line needs to include the field name, previous value, and new value.

[mikedawson]

As per planning poker: was between 5 and 3, so estimate days is now 5

[akshattak]

@mikedawson version history first draft is available here

[mikedawson]

@akshattak As a draft, this looks good to me.

I think we should change the name from 'version history' to 'change history' because if we use the word version people might get the idea that they can save specific versions of things, which we are not doing at this stage.

Please go ahead and add the screens for other items we would track: I think we need this for Person and Class. Enrollment changes could be tracked as a change to the class (e.g. Person name was enrolled as Student etc.

[akshattak]

@mikedawson @poojaustad Comments are resolved, and it is ready for the review.

[mikedawson]

@mikedawson @poojaustad Comments are resolved, and it is ready for the review.

I have reviewed and put comments on Figma. Two main things:

• I think we should call this "Change history" not just "history". We are only showing changes. Read-only access (eg like browser history) is not something we are doing. Figma comment
• What text exactly to show on the change history is ambiguous Figma comment

[akshattak]

@mikedawson I have updated the prototype as per the comments. We need to add a behaviour note list for: exact text to show on the change history.