Workflow Issue: Creating new Article Approval WF

I need to seperate our users into two primary groups. Similar to another post on here actually. However I'm looking to use InstantKB's workflow capabilities to faciliate the seperation of users into two groups: Content Developers & Article Publishers

I've created seperate staff depts & permissions for these groups such that the only real major difference between them is that a Publisher will be able to edit articles they didn't create (and content developers can only edit their own articles they created).

Ideally I'd like to have Content developers only be able to create articles for private access (i.e. hide the Public option from the access drop down menu). But I don't see a method for accomplishing this.

So instead I'd like to create a workflow that we implement as part of our business process that has the following stages.

1. Draft - Keeps items in Private access

2. Review - Still in Private Access, while Publisher user reviews article content against misc business standards.

3. Revise - Private access - used when publisher essentially "rejects" an article so it needs to be revised by original author

4. Publish - moves to public access.

Ok so that was the back history, where I'm at today is that the WF i've created doesn't seem to allow anybody but an administrator edit an article when it's in the Draft, Review, or Revise WF Steps. I can only re-edit something as a Publisher or Content Developer once it's been published.

So In effect my WF isn't quite behaving as anticipated.

For each of the steps I've still got all users as having Edit permissions within the WF Steps So theoretically I'd have expected the any user to be able to re-edit an article at any stage of the WF, but such is not the case.

Anybody have any thoughts on this? I can provide additional detail as needed.

thanks much.



11 Years Ago by mrLloyd

An update on this. I've noticed it is not WF related at all. even with a staff user setup with default staff dept & permissions I'm unable to edit any document that is set to Private Access. Am hoping it's just a defect I missed somehow and am currently going to upgrade our installation (currently on 2.0.1). will post up how it all turns out.



You must as an admin grant yourself the permissions to work in a certain area/tab if you have locked down the security to ensure you are included in the staff members able to edit articles. This seems to be a common mistake when tabs are tightly secured/set up with specific user groups in mind. Do please let us know how you get on with resolving this, I'd be interested in the root cause. Obviously this behaviour does not manifest in all/many installations, otherwise we would certainly know about it, especially ias it would come up in our QA Testing.

Kindest Regards,

James Trott

Hi there,

I don't see any attachments. One thing to check is that your staff members actually have permission globally to edit articles.

You can control edit permissions from within the Admin CP > Staff > Staff Permissions.

If you click the edit button next to the permission set used for your staff members. This will display a drop down menu containing all your tabs. If you click for example the Knowledgebase tab this will take you to the permissions page for staff members under the knowledgebase tab. Here you'll see options to disable editing of articles by staff members within the knowledgebase tab. Please ensure these edit options are enabled.

If you don't set any edit permissions at a WF step the global staff edit permissions will be applied. If you specify specific edit permissions at a WD step this will override the global staff permission set and will ensure only staff members who have permission to edit an article at a WF step can edit the articles. For users who don't appear in the edit permissions for the WF step will receive a message informing them they don't have permission to edit the article.

Please do attach any images you feel may help us provide a more accurate response. I look forward to assisting further :)
Kindest Regards,

Ryan Healey
Blog | Community | Docs

This problem is exactly what the Workflow module was designed to    solve. It allows site administrators to set up predefined steps, called    states, through which every piece of content must    pass before publication. A complex site with strict legal requirements    might need “Editorial review,” “Legal review,” “Executive approval,” and    “Ready to publish” states. When a node is in one of those states, only    users in specific roles are allowed to move it to the next state,    ensuring that the right people give the content their stamp of approval    before it goes live.

price per head
barack obama facts


Existing Account
Email Address:


Social Logins

Select a Forum....

InstantASP Forums