My problem is items that complete the workflow and get auto published still show a State of 'Approved'. Right now my users cannot edit items that are in this final state. Is there a way to make Sitecore clear the State field after auto publish or do I need to give every user permission for the 'Approved' workflow state?
Give permission to the "Approved" workflow state.
Without knowing the specifics of your workflow configuration, I am going to guess that the users need to click "Edit" to unlock the item and reset its workflow state. This button can be found on the Home and Review tabs in the content editor.
Related
I need a setup where users can update a page and then submit it for approval/activation in AEM 6.2. The page would be submitted to workflow where a content approver/administrator would review and publish the page. This seems like a common setup for content managment, but I can't figure out how to do it in AEM.
I have done the following:
setup a user that has permission to update but does NOT have
replicate permission on folderX.
setup users with update and replicate permissions on folderX and added them to a group "content-authors-approvers"
created a workflow where the first step of the workflow is the page will be submitted for approval and publication to member of "content-authors-approvers" group
assigned this workflow to folderX
However, when a user does NOT have replicate permission, the "publish" option does not show up at all. This makes sense, really....but then, how does one go about setting up a workflow like this?
From what I've read about this in earlier versions of AEM/CQ5, the replicate/publish option was still available to all users, but it would automatically kick off workflow if the user did not have replicate permissions. (see Start a workflow on page activation without activating the page in CQ5 )
this seems to have changed in 6.2. can anyone help?
I have tried looking up online, but found nothing
There is a native workflow to handle that. It's named Publish Example. see it here: http://localhost:4502/etc/workflow/models/publish_example.html . I believe that it's better then the automatic triggering cause the author actually knows he triggers a workflow (whilst when it happened automatically there was no info about that). To explicitly call it you have to either from /siteadmin select a page and click workflow on it, or do it from sidekick or in touch.
sidekick:
touch - editpage:
I am now making a Form that can be Approve or Reject by approver.
My Forms, Views, SmartObjects works well.
I want to add a withdraw function in Workflow.
Things i want to do : If requester withdraw the form, workflow should be terminated. (It means that the worklist of the current item should be disappear from the approver's worklist.)
I don't want to requester having the worklist item because it is no sense if they don't withdraw the form.
Any ideas for the workflow?
I think you can withdraw the worklist item using the release task in the worklist.
The Release option allows a manager to release an Open worklist item from the current user's worklist so that it becomes Available to other destination users setup by the Destination Rule. Only Work Items with Open status can be released.
Hope this will be helpful for you
If you take a page and put it in a workflow, then if someone wants to modify that page – in an emergency situation and essentially start another workflow on it –
Is that possible to send that page through another workflow?
If you don’t want to send the same page through a workflow, but just want to edit it, can you?
Apparently If one person is editing a CQ page and same page is edited by someone else at the same time, at production level, how the CQ / developer handles the situation?
Thanks in Advance
It is not possible to subject a page to more than one workflow at once, none of the interfaces allow this to happen.
The pages can be edited even when they are subject to a workflow. In emergency situations where in it is not possible to complete the workflow , users with required privileges can terminate the workflow from the instances tab of the workflow console (/libs/cq/workflow/content/console.html). Pages can be usually activated even if they are subject to workflows.
The repository is accessed via repository session. Based on the credentials provided the user gets a repository session. Any changes made via that session is only visible to the other users when the session is saved. Since different sessions are used , multiple users can edit the same page simultaneously. The data in dialogs are loaded via asynchronous GET requests when EDIT is clicked and not on page load , so it is very unlikely that the user will be editing old data. They can still overwrite some other user's changes. Developers do not have to handle these situations unless there is some special requirement. If a user wants to stop other users from editing a page , they can use the lock functionality that comes out of the box. A locked page can be unlocked only by the user who locked it or an administrator. A page or node can be programmatically locked via the JCR API.
I've implemented a custom workflow in Adobe CQ5.6, similar to http://blogs.adobe.com/learningwem/2011/11/30/cq5-4-workflow-example-approve-reject-by-the-reviewer/
I'm using CQ5 inbox notifications only -- no email notifications.
The problem is, after the Approver selects either "Approve" or "Reject", the inbox notification does not get removed, even though the workflow continues / completes.
There doesn't seem to be an option to manually delete a notification, unless you go into crxde and delete the nodes. So the main concern here is that notifications will quickly pile up, making it confusing to figure out which ones are current, and ultimately clogging up the app.
This only seems to happen at this exact step in the workflow. The Author's notifications disappear once they've been dealt with, as you would expect.
Has anyone had anything like this happen before?
Something about the way I worded this question helped me figure out the answer.
The Author's notifications disappear ... as you would expect
This made me think it might be a user permission problem rather than anything to do with the workflow step.
I confirmed this by switching the roles of the two user types, (so the Approver starts the workflow and the Author must approve the change). As I guessed, it was any notification assigned to the Approver, rather than notifications generated by that particular workflow step, which were not disappearing.
Specifically, the permission that was missing was for /etc/workflow/instances. I allowed all methods for that user, and my problem is resolved.
You can edit permissions via /useradmin.html in your CQ5 instance (in my case, http://localhost:4502/useradmin.html )
We are trying to implement a custom checkout policy for a Plone Document Management System. In this, we would like to be able to have Working Copies of published documents after a certain period of time.
Iterate seems perfect for this.
However, we only want the checkout to be available for published documents. So here is the reasoning....
Since the workflow controls several permissions, we added both "iterate : Check in content" and "iterate : Check out content" to the permissions tab in the portal_workflow tool.
We then marked the checkboxes in the permission tabs of the individual workflow states for those people who have checkout rights.
However, in the frontend, everybody keeps having the option to checkout documents regardless of the state the document is in.
What are we missing?
PS: We already checked out the document on "Working Copy Workflow Customization" and in our opinion this relates to changing the workflow for checked out documents, which is not what is intended here...
The problem here I think is the checkout_allowed method in plone.app.iterate/browser/control:Control.
It doesn't check on any permissions before allowing checkout for the user(it assumes if they user can view it, they should be allowed to check it out to home folder and such--I guess that's a reasonable use case).
Then, in the portal_actions/object_buttons/iterate_checkout it simply uses the "View" permission to allow the button to be placed there.
So to be completely correct for this, you would have to customize the checkout_allowed method and the permission used in the action.
To do it quick and simple so the user just doesn't see the button, change the button permission to "iterate: checkout content".