dan-tang-ssd
commented
1 year ago For (relative) simplicity, I'm only including the most important variables related to the assessment:
* Redlines: The Value (0, or 1) * Principles: The rating, comment and is_na; * Additional Criteria: The rating, comment and is_na;
Yes, we need to keep revision history for the most important variables only. I think it is good enough.
Because the pivot-table entries are created along with the assessment record, completing the assessment for the first time counts as a "change", so even the first time entering values / ratings for an assessment will be tracked. I think this is actually good, as the system will show each change to a redline value or rating from the very beginning of the assessment process.
That's really great. It shows the complete history starting from the very beginning, without anything missing.
The revision history view is not very good at the moment, but I think it can be revised in the UI / UX branch, so I'm only interested in getting the functionality here. The only changes I've made to the default blade templates are:
Yes, I agree. We can revise it in the UI / UX branch. Perhaps we should avoid using red and green colors. Red color looks like something is wrong, green color looks like something is correct. The revision history page looks like something wrong before (in red) is corrected now (in green). Another concern is, user may co-relate red and green colors to dashboard principle summary, which may use of green, yellow, red colors.
- removed the "undo revision" button, which doesn't work here and I don't think is needed. (A user can reverse a change by making a change again in the assessment itself).
Yes. We do not need "undo" function here. Every single change should be kept in revision history. We keep track of all changes for completeness.
dave-mills
This PR resolves #38.
It adds a revision history feature to keep track of changes to key assessment variables.
The Feature
For (relative) simplicity, I'm only including the most important variables related to the assessment:
Because the pivot-table entries are created along with the assessment record, completing the assessment for the first time counts as a "change", so even the first time entering values / ratings for an assessment will be tracked. I think this is actually good, as the system will show each change to a redline value or rating from the very beginning of the assessment process.
After making changes to an assessment, the revisions are available for review on the projects List View - in the details row:
The revision history view is not very good at the moment, but I think it can be revised in the UI / UX branch, so I'm only interested in getting the functionality here. The only changes I've made to the default blade templates are:
$history->relationand$history->linkedItemName- 2 extra variables added when getting the$assessment->revision_historylist, to get the show the needed information to understand what values / ratings were changed.Technical Details
The default Revisionable trait only handles properties of the model - not the syncing of related entries or updating of pivot table values via a relationship. So, I've put the revisionable trait onto the 'pivot' models directly (
AssessmentRedLine,PrincipleAssessmentandAdditionalCriteriaAssessment).To bring the history together to the "Assessment" level, I added a
getRevisionHistoryAttribute()method onto Assessment, that combines the histories of the 3 related pivot models.The tracking is done via save events on the models, so I also updated the AssessOperation, RedLineOperation and AssessCustomOperation to use save() instead of sync() or updateExistingPivot() to save the needed variables to those models.