You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While working on Case Reporting (Issue #305), I thought it was a good idea to provide the option for people to provide the previous iterations (edits, extensions, ..etc) of things happening on each Case to let others see the progression of work done on each one. When trying to add this, I discovered that these previous iterations are not currently being stored AFAIK. From what I've seen, updatedBy are updatedAt are the only things being stored to reference this data on certain documents, but with only having these we lose a lot of information that would be useful.
Possible Solutions
For example in Cases, to keep track of previous iterations we could attach two keys on each Case: parent and HEAD (Very creative, I know). parent could keep track of the ID of the newer version of the Case, and HEAD could keep track of which Cases are the newest versions of themselves. While this solution would increase redundancy since we would now store the same information multiple times on each edit, I do believe the benefits of keeping track of this type of information outweigh the cons of storing it.
The text was updated successfully, but these errors were encountered:
You can rely on audit logs to know what has been updated on a case, over time.
There is an issue related to a case timeline, but it's not yet planned for implementation.
Request Type
Feature Request
Problem Description
While working on Case Reporting (Issue #305), I thought it was a good idea to provide the option for people to provide the previous iterations (edits, extensions, ..etc) of things happening on each Case to let others see the progression of work done on each one. When trying to add this, I discovered that these previous iterations are not currently being stored AFAIK. From what I've seen,
updatedBy
areupdatedAt
are the only things being stored to reference this data on certain documents, but with only having these we lose a lot of information that would be useful.Possible Solutions
For example in Cases, to keep track of previous iterations we could attach two keys on each Case:
parent
andHEAD
(Very creative, I know).parent
could keep track of the ID of the newer version of the Case, andHEAD
could keep track of which Cases are the newest versions of themselves. While this solution would increase redundancy since we would now store the same information multiple times on each edit, I do believe the benefits of keeping track of this type of information outweigh the cons of storing it.The text was updated successfully, but these errors were encountered: