SID-02177: ApprovalPlugin; Reset Approved Status
| Status: |
Answered |
TWiki version: |
6.0.1 |
Perl version: |
5.10.1 |
| Category: |
ApprovalPlugin |
Server OS: |
CentOS release 6.5, kernel 2.6.32-431.29.2.e16.x86_64 |
Last update: |
9 years ago |
Is there a way to "Reset" the approval status on a topic that already has been approved?
I would like to understand if the following is possible:
1) User notices an error or wants to add content to a topic that already has been approved.
2) User can press a button (or other technique) that "Resets" the Approved / Locked status of the topic allowing them to make modifications.
3) After making changes, user can restart the workflow by re-submitting the document for approval.
I'm still new with TWiki and have explored the META data and see that the approval status is found there however I'm not sure how to proceed from that point.
Any help would be much appreciated.
--
Jani Hamalainen - 2016-03-17
Discussion and Answer
There are two parts of this issue...
- The technical problem: There's nothing magical with the "APPROVED" state. If you want to be able to get back from "APPROVED" to "WAITING FOR REVIEW" it should be sufficient to add an appropriate line to the transition table.
- The formal problem: Once a document has been approved, it has been approved with all the errors it contains. Any subsequent modification, whether beneficial or malicious, would spoil the formal approval process because you can't undo the actions which have been performed because you've got approval. Perhaps it is better to copy the topic to a new name if you want to start a new round of approval, or at least to "freeze" the approved state (e.g. by attaching a PDF version) before entering the next round.
--
Harald Jörg - 2016-03-17
Thanks for the feedback Harald.
1) I do understand that I can control the states/names however what I'm wondering is if there is a way to have an "APPROVED" state that prevents any editing of a topic but also allows any user to change the state back to "WAITING FOR REVIEW" if they notice something that requires an update. Changing the state back to "WAITING FOR REVIEW" would allow for the topic to be edited. In other words, once a document is "APPROVED" it cannot be edited without first changing state and restarting the approval process.
2) I agree with your comment to "freeze" an approved state (and perhaps the %APPROVAL{"history"}% could include a $Rev variable that would allow the History table to link directly to an existing revision of an Approved Topic). I would really like to stay away from copying the topic to a new name because I think that would get confusing to manage.
Is what I'm trying to do something that can be done or should I try approaching it in a different way?
--
Jani Hamalainen - 2016-03-18
--
Jani Hamalainen - 2016-03-18
Oops. I do realize that I can control the topic "State" and topic "Permissions" using the separate tables in the
ApprovalPlugin. Consider my point (1) above closed.
Is trying to tackle including $rev as an output from %APPROVAL{"history"}% something that could be done outside of the Plugin? Or am I correct in assuming that the plugin would need modification?
--
Jani Hamalainen - 2016-03-18
I admit that I'm not very familiar with ApprovalPlugin, but I guess that including a $rev would need changes in the code.
In the "formal" documents in our TWiki, we have learnt to use $rev with care: It doesn't really
freeze a document. All INCLUDEs, SEARCH results and other dynamic stuff will be taken from the current state and not from the date when a document was approved. Even skins (or style sheets) and preference variables can completely change a document's message. But, of course, the effort spent for freezing depends on the value of "approval" in the context of a topic, which can vary from a simple acknowledgement "We've read the topic and agree with it", to a rocket launch to Mars which can't be undone even if an error is detected after approval.
--
Harald Jörg - 2016-03-18
Within
ApprovalPlugin there is a way to set the format of the approval history.
- Set APPROVALHISTORYFORMAT = "| $state | $wikiusername | $date | %MyVARIABLE% | Text here |"
I'm able to set %MyVariable% to what I desire however %APPROVALHISTORYFORMAT% stores %MyVARIABLE% instead of expanding it. Is there a way to force this variable to be expanded in advance?
--
Jani Hamalainen - 2016-03-21
I don't quite get it: When do you want the variable to be expanded? If you just set
MyVARIABLE and
APPROVALHISTORYFORMAT and then reference %APPROVALHISTORYFORMAT% then %MyVARIABLE% will be expanded - that's just plain TWiki, not related to this plugin. "Seeing" a variable name usually occurs if the variable isn't defined in the scope of the current topic.
So, please double check that the variable name (case sensitive!) is the same in the assignment (
* Set MyVARIABLE = ...) and reference (
%MyVARIABLE%): In your example, they don't match.
Just trying out here:
- Set MyVARIABLE = My Variable
- Set APPROVALHISTORYFORMAT1 = | $state | $wikiusername | $date | My Variable | Text here |
- Set APPROVALHISTORYFORMAT2 = | $state | $wikiusername | $date | %MyVariable% | Text here |
- Get %APPROVALHISTORYFORMAT1%: | $state | $wikiusername | $date | My Variable | Text here |
- Get %APPROVALHISTORYFORMAT2%: | $state | $wikiusername | $date | %MyVariable% | Text here |
--
Harald Jörg - 2016-03-22
Hey, sorry I forgot about this open support question and have no resolved the challenges I had with
ApprovalPlugin.
I appreciate you patience and help answering my questions Harald. I'd like to think that in the 5 months since I asked this question I've improved
--
Jani Hamalainen - 2016-08-20
If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.