Hi everybody, I'm desperate.

After 4 months of every kind of exsperiments studies and tests, I can't achive this simple (i think) site configuration:

  1. In my site I have only one type of content type: ARTICLE
  2. Articles are categorized with taxonomy vocaboularies.
  3. I have 2 types of users roles: editors and moderators.
  4. I want that these users were grouped as Departments: every moderator has his own department, with his editors.
  5. Editors and moderators can belong to only and only one Department
  6. A Department can have only one moderator and a number of editors
  7. Taxonomy vocaboularies are unique within the site, shared by Departments
  8. I want that content was subject to a workflow/revisioning process, within his own department, in this way:
    • Editor (or also a Moderator) of Department-A writes an article
    • Moderator of Department-A revises and finally publish the article
    • Obviously other Moderators/editors belonging to other departments cannot view/edit/publish such content
    • These workflow/revisioning process rules are the same in every department (no personalized process)
  9. A content in is initial and intermediate state (creation, draft, revision) can be visible only in his Department
  10. A content in is final state (published) can be viewed by everyone (anonymous users, moderators, editors apart from their Departments), but it can be unpublished only by moderator belonging to the content's original Department.
  11. After a content is unpublished, it can return in the workflow/revisioning process of its Department (invisible to others Departments)

Please see image in attachment where I tried to represent all above schematically.

Yes, I've already tried all necessary modules and made every kind of combination/experiment: Revisioning, Workflow, Module-Grants, Taxonomy-Access-Control, TAC-Lite, Organic-Groups, Rules, Trigger, Actions, I've already tried all revisioning tutorials, red all about these modules conflicts/issue, but... NOTHING! At the end, there was always something that doesn't work!

I think that using Organic Group for creating departments, in combination with Revisioning, Workflow and Rules modules to manage the publishing process was the logical choice, but this solution fails because of these module node access conflicts issues.

Someone can help me? There is a definitive solution or I have to think that this kind of site structure is impossible to do with Drupal 6 ? Surely are my mistakes: what am I doing wrong?

Thank you

MXT
(sorry for my bad english and for cross posting in Access Control Group)

Comments

jcisio’s picture

I'll try to do the same thing, but not now. I think the 3 tutorials at http://drupal.org/project/revisioning solve completely your problem. What doesn't work for you?

MXT’s picture

Yes, i've already done all 3 tutorials about revisioning.

See also the new "matrix" approach I've suggested: http://drupal.org/node/408018#comment-1779526

In my case there is a difference: I don't want restrict user access by taxonomy. The taxonomy tree (articles categories) is unique in my site, shared by every Department.

I want to restrict access to articles in draft status by groups (departments) so I used Organic Groups. Then I want that articles in published status are PUBLIC visible, but only the Moderator of the orginial Department can unpublish these articles and put them in the revisioning process already.

The major problem is caused by access conflicts with OG: see my report here: http://drupal.org/node/701402

Thank you very much if you want to help me!

MXT

jcisio’s picture

I haven't examined the OG module, so I don't know about this problem.

The "restrict access to articles by groups" is something belongs to tac_lite module. And normally use that with module_grants and workflow is the solution. That's also what I planned to do.

BTW, if you have only 2 (or few) departments, the solution is simple. Just use the Workflow module is enough. You define different roles like D1-editor, D1-moderator, D2-editor, D2-moderator. Then create a workflow like this: (creation), D1-draft, D2-draft, D1-public, D2-public, then have the following transition:
- (creation) -> D1-draft only allowed by D1-editor
- D1-draft -> D1-public only allowed by D1-moderator
- D1-public -> D1-draft only allowed by D1-moderator
same thing for D2-... And don't forget to set the access permission for each role at each workflow state.

MXT’s picture

Thank you very much for your suggestion: I'll try it for sure!

I think this is a good workaround, but with the following limitations:

  • For a lot of Departments, there's a "heavy" setup creating each time new moderator/editors roles and relative roles assignment to users and workflow settings (imagine if I have 40 Departments, 30 new editors for each Department and 4/5 states of my articles...) I think it will became too complex to manage...
  • We'll lose all OG modules and relative sub-modules features, e.g. losing in management flexibility, auto-invite editors/subscription, delegating group users management by group moderator, key subscription and so on.

BTW I'll try your solution in the meantime. Any other suggestion/experiences?

Thanks

MXT

jcisio’s picture

As I said, I don't know about OG stuffs so please forgive me ;)

That solution is only good when you have a few department. In fact, it's rather good! When you go beyond a limit, there will be two main problems:

  • Performance: there will be many states. It *depends* on how informations are saved/loaded that there might be performance problem. I have no idea, but the workflow module seems lightweight.
  • Complexity: that's correct if you use the workflow module. Why don't you write a small module that manages all thoses states for you and never bother the workflow administration page?
tryitonce’s picture

subscribing for future reference - thanks

I hope this helps - at least to exclude some options -

Did you try to use permissions and Content Access module? I know, there are some issues with compatibility.
This would allow you to prevent editors to delete their own content. But editors could at any time edit their then published articles. Would they have to go back for review before republishing?

and

Would it help to change the author or the Content Type after publishing? If the editor / author is changed the editor can't get back to it. Changing the Content Type after publishing could move the restricted article into general public access - like Content Type - D1-article, etc. for the writing and pre-publishing period, then Content Type "article" after publishing. If returned for editing it goes back to D1-article CType. This should work with OGs.

PepeMty’s picture

subscribing...

Warm regards from sunny México!
Pepe
:-)

WorldFallz’s picture

I'm not sure I understand the problem-- but I often find that http://drupal.org/project/og_user_roles, which don't mention in your op, fixes access problems with og.

MXT’s picture

Yes, I've tried OGUR also, but without success.

The problem is that when an article is in "published" state, that is "visible for all users, apart of groups", OGUR roles disappear.

I'll try to explain better:

The best result I've reached is with this configuration:

(main) Installed modules:

  • Organic Group
  • OG User Roles (OGUR)
  • Workflow
  • Triggers

ATTENTION: NOT installed modules:

  • Module grants
  • Revisioning
  • Taxonomy-Access-Control
  • TAC-Lite

Main operations:

  1. Setup a "Department" group (make all private)
  2. Setup an "Article" groups content-type
  3. Setup "editor" and "moderator" roles
  4. Create 2 groups (departments) and assign some users to them (no core roles to this users!)
  5. Assign (only throught OGUR) roles to respective users (only a moderator for group)
  6. Setup a workflow (draft, to-revise, published)
    • Assign "visible" by anonymous and authenticatd user only to "published" status (so all user can view articles), and "editable" only to moderators
  7. Setup a workflow trigger for the "to-revise -> published" event, assigning "Make post publicly visible" OG action
  8. Setup a workflow trigger for the "published -> to-revise" event, assigning "Make post private to its groups" OG action

Ok, all works fine, eccept for the last step: last trigger can't be evoked because nobody can edit articles: these are in "visible for all, apart of groups" status, OGUR roles for "moderators" doesn't works. That's why (I think) OGUR roles works within a "group context" and it doesn't work if the post is now "public" (no roles to manage articles).

Does someone has any idea to resolve the problem?

Thank you very much

WorldFallz’s picture

yes-- ogur works within group context, that's the entire point of the module in the first place. I'm not sure I completely understand the problem, but don't remove the group context-- a post can be public or private and still keep it's group context.

tryitonce’s picture

Hi,

1. - is this meant to be like this - last para ==>>
......... these are in "visible for all, apart of groups" status, OGUR roles for "moderators" doesn't works.
is it in "visible....." or "invisible....."?

2. - your OGUR "moderators" could also be "general moderators" and thus have access to all published articles whether OG or not.
In this case you could use one of the node access modules - or just trust your moderators only to recall their own departmental articles for review.
3. - it might also help if you changed the author name / ID on publishing to that of the moderator.
4. - I think WordFallz is also pointing you in the right direction by suggesting to leave the article tied to the OG department and be public to all. That should keep the article within the OG at any stage.
5. - referring back to 3. - you could for each department set the author of articles by default to the ID of the moderator. So, any editor's article is only published under the moderators ID. Thus the moderator of the OG is the one who controls the article and recalls it back to his department for editing. Instead of using the moderators ID you could have a separate ID for publishing articles with the author name / ID of the department.

Good luck .....

Tebb’s picture

Hi MXT,

Did you try WorkBench (http://palantir.net/blog/introducing-workbench-new-approach-managing-con...) and did it solve your issues?

Regards.