As a user, I can assign an attribute to any page that sets the frequency of the content review.
If the "last update date" +"update frequency" < current date, then the content has to be marked as expired. A quick action should be used to review the content and reset the timer.
(Important note: another feature request could also solve this one.)
I'm not sure about this feature request.
You can apply an archiving config to a space, in which you can configure the "expiration period". It works exactly as described above.
Then, you can use the "Update" quick action to edit a page and make it current again, or the "Confirm" quick action to make it current again without an edit.
So, what is missing from the current app version regarding this use case?
The business problem is that we have certain content that needs to be reviewed at a regular basis. Certain policies need to be reviewed once a quarter for example. This review period varies depending on the type of document it is.
For example we have a page that is our HR policy page that needs to be reviewed once a year; where as things like sprint retros can expire in 90 days and things like how-to’s need to be reviewed at least every 180 days. This doesn't work in the current model where all pages are assigned a blanket expiration period, with the exceptions of one you put a manual date on.
Ideally I want it dynamic because if someone comes and updates the page in that time period it would reset that clock. In the example of HR policies, if they decide to update a particular policy in the middle of the year it would reset the expiration date to a year from that update date, where the other policy pages would retain their expiration labels. Having the person that is updating that page remember to update the expiration label would be a bit cumbersome especially for some of our less technically adept employees.
Thus The idea is that you can assign content an attribute that sets the frequency content needs to be reviewed. So something like:
* 1 day (expired-#d)
* 1 week (expired- #w)
* Monthly (expired-#m)
* Quarterly (expired-#q)
* Annual (expired-#y)
Then; if Update Date + Update Frequency Label < Today's Date it would mark it as expired. This would work similar to the “expired-yy/mm/dd” tag that you have, except it would be more dynamic (expired-60d for example). You could then use your quick actions to review the content and reset the timer without having to reset the new expiration date manually.
Get Guru has implemented a feature similar to this.
https://help.getguru.com/articles/ig9RoGoT/Choosing-a-Verifier-and-Verification-Interval
The other cool thing is you could assign this dynamic expiration label to a confluence template so every time you created a certain type of page it would automatically get the expiration.
@Zachary, thanks for describing your use case and also the Get Guru hint!
Although you also suggest a label-based solution, this use case would be better solved with another open feature request: applying archiving configurations to a page set selected by a CQL query! That'd a be a more natural way to tackle this, I think.
(I added a hint to this feature request summary not to forget this relation when prioritizing requests.)
UPDATE: We have released the Better Content Archiving app's cloud version just a few weeks ago. It addresses many points criticized in the Data Center version and solves new uses cases, including also this one.
(Our plan is that, if there is interest, we will back-port the most valuable changes from the Cloud version to the Data Center one.)
Statuses in the cloud version are extremely flexible. As part of a content status scheme, it is a CQL query per status that determines if a content is in that particular status:
Following that thought, you can configure the "Expired" status to use this CQL:
(label = "update-weekly" and arch.event.lastUpdatedOn < now("-7d"))
or
(label = "update-monthly" and arch.event.lastUpdatedOn < now("-1m"))
or
(label = "update-quarterly" and arch.event.lastUpdatedOn < now("-3m"))
or
(label = "update-annually" and arch.event.lastUpdatedOn < now("-1y"))
With this, you could apply one of the 4 label to determine the required frequency of the update! Can you follow this?
Due to the flexibility of CQL, you can implement really smart statuses based on CQL fields, including basic properties like title, labels, contributors, etc.
5 Comments