Romca, thanks for helping me out last time.

We need to get our proofreaders and editors to get involved online.
That means that as soon as the article is submitted, we need to let them know and have them working on it.

I assign our proofreaders and editors to the corresponding ejournal category, but this does not allow them to view and edit submitted materials in the WORKING category. What else must I do, so that they can do their work?

Also, if an article is moved to published, Chief Editor and user=1 (?) are suppose to retain rights to edit and delete it. But ejournal still gives a message that only the Chief Editor can delete and does not allow the deletion to take place. Strangeley, it does allow the Chief editor to edit the file, though... Is this a bug or a feature? :)

P.S. Thanks again for being so helpful!

CommentFileSizeAuthor
#4 Workflow.jpg9.06 KBbaraban

Comments

romca’s picture

romca commented

Hi,
to get editors involved asap: there is an e-mail in the e-journal settings. When articles is inserted, ejournal sends email to that e-mail with the text of article. So, you can redirect it from there to different e-mails

working area:
editors and proofreaders can edit the article, but only when they know the url (it is sent in the email), to allow them to see the working area is my todo task. I agree it should be there for them too.

chief-editor not able to delete:
I have to investigate it, it seems to me to be a bug

cheers,
romca

baraban’s picture

baraban commented

1. Thank you! That is the way I set it up and wanted to make sure that I was not missing some deeply hidden wonderful function :) As a suggestion, in your next version of this software, you should probably not hard code the text of those emails and allow Chief Editor to send those emails to some or all of the proofreaders and editors. Also, it would be really nice to build in some type of workflow into this process. I doubt that it would make much sense to use the worflow module for this, but some reduced builtin workflow functionality would be absolutely great. If you want my suggestions on this, I thought about this quite a bit and would be happy to share my process with you.

2. I used "Article" flexinode and story as ejournal content types. For drupal to allow my proofreaders and editors to edit the submitted flexinodes, I had to set access control to allow "edit any Article content" for proofreaders and editors. This option is not available for the story node type, so drupal blocks access to submited story nodes, unless I give proofreaders and editors the more general "administer nodes" privilege, which I definitely do not want to do! So, how do you solve this problem? Is using story nodes a bad idea for this reason? Any other tips are most welcome!

romca’s picture

romca commented

Hi Baraban,
I see you need e-journal for a real work, and I am glad it can help.

> As a suggestion, in your next version of this software, you should probably not hard code the text of those emails and allow Chief Editor to send those emails to some or all of the proofreaders and editors.

yes, i agree, have you seen that in todo there is something like "add the e-mailing functions" - in fact, it was foreseen from the very beginning, but I never found enough time. Maybe now we will finish it together ;-)
- btw, the text of the e-mail can be changed (but not dynamically) in translations, but i know, that is not what is needed

> Also, it would be really nice to build in some type of workflow into this process. I doubt that it would make much sense to use the worflow module for this, but some reduced builtin workflow functionality would be absolutely great. If you want my suggestions on this, I thought about this quite a bit and would be happy to share my process with you.

- i have already thought about it and did some work, but i am happy to see your suggestions. pleaso do share!

2. I used "Article" flexinode and story as ejournal content types. For drupal to allow my proofreaders and editors to edit the submitted flexinodes, I had to set access control to allow "edit any Article content" for proofreaders and editors. This option is not available for the story node type, so drupal blocks access to submited story nodes, unless I give proofreaders and editors the more general "administer nodes" privilege, which I definitely do not want to do!
- for authors: I use flexinode "edit my articles"
- for proofreaders and editors this should be done by e-journal, could you have a look into the {node_access} table? Basically, the permission workflow did not change for e-journal from 4.6 to 4.7, but maybe drupal 4.7 is different in this aspect.
you should see this in the table (in one row)
nid = nid of the article you want to grant your proofreader right to edit
gid = groud id of editors and proofreaders is "1"
realm = ejrn
grant_view = 1
grant_update = 1
grant_delete = 0

So, how do you solve this problem? Is using story nodes a bad idea for this reason? Any other tips are most welcome!
- i would use flexinode instead of story, but i repeat, e-journal should do the grant setting correctly

hth

roman

baraban’s picture

baraban commented
StatusFileSize
new Workflow.jpg9.06 KB

That is exactly correct! I get a line just like that, for example:
613 1 ejrn 1 1 0

But, if I log in as a proofreader or an editor and node 613 is a "story" node, (and not an Article flexinode with additional access permissions set), Drupal does not allow me to edit that node.

Also, Drupal does not allow my proofreaders and editors to simply view the nodes, no matter if they are story of flexinodes. So, assuming that 612 is a flexinode and I set permissions as before, http://www.odessapage.com/new/en/node/612/edit would work for proofreaders and editors, while http://www.odessapage.com/new/en/node/612/ would not and generate "You are not authorized to access this page." instead. Any ideas on what would cause this behavior in the 4.7 version?

Regarding the workflow: A very simple generalized one would work for us. (See the attached picture to better follow the words)
Basically, as soon as an author (or an author want-to-be anonymous user) submits an article, an email goes out to everyone in the Editor role and only editors can access and edit the node. If an editor rejects it, the article gets sent back to the author for futher work with editor's comments and only the author may now edit it. If an editors accepts it, an email goes out to all of the proofreaders. If an editor approves it, it is sent to the Chief editor to be included in the next journal.

If an article is accepted, everyone of the proofreaders must check out the article (CVS style) and make their corrections one at a time. (Drupal's node version control is used to preserve each of their revisions). After the last of the proofreaders is done, an email goes out to all the editors that the proofreaders are done with the corrections. And the editor that gets to it first has the same
three choices as before.

There are only three minor issues with this workflow.
1. Official roles do not always correspond with function, so in our case, some of our acting proofreaders are actually editors in title. This could be taken care of by having two role tables one official and one "acting as".
2. Chief editor is unable to send the article back for rework only not included it in the issue. In our case this is completely sufficient, but I imagine somebody may want to ad another path to the workflow.
3. The process stalls if not all of the proofreaders do their job, This can be taken care of by adding a maximum time before the articles are sent back to the editor.

Hope this helps... As far as helping you put the finishing touches on the software, I would be happy to help in any way I can. Just please keep in mind that I am not a programmer. I am good with logic, do product/program/project management best and can also do quite a bit of QA and even fix some nasty bugs that do not require major changes to the code. But once you have to get through three levels of Drupal abstraction and join five database tables, I am not the guy to do it! :)

romca’s picture

romca commented

Ciao Baraban,

many thanks for the offer of help. I am sorry for the late reply, I am bit overloaded and bit sick last days. I am looking into your problem right now and seems that the node_grant did not change substantially in 4.7 (except that instead of three, now there are 4 options - create,update,delete,view), the story.module does not seem to interfere with the grants. The only thing which comes to my mind is their status. Are these nodes (which you try to edit) published? Do they have a status "published"? They need to be published if we want the node_grant system to work (e-journal will prevent anonymous users from viewing them before they are published as articles from the issue).

If they are published nodes, then do you use any other grant module, which could interfere with e-journal?
(if yes, try to disable that module, go to "edit journal" and click at the button "Check access rights" - it will redo the access right for all your articles)

Regarding the workflow:
I think I will have to separate proofreader and editor roles
Chief-editor should have alway right to interfere, no matter what others do - ejournal module should keept track of what is going on with all articles in the queue. So the little change into the workflow would be: "article is not sent to the chief-editor after it was approved by editor, chief-editor will always know status of all the articles" (but we can send him messages about approved articles, of course ;-)

Regarding the issues:
1. I don't see it as a problem, that people can have two roles assigned
2. I don't quite follow, but it is probably solved by what is proposed above
3. Yes, some control points are needed

I appreciate your offer of help, thanks a lot!

baraban’s picture

baraban commented

You are right - I do create new nodes as "unpublished". The reason I do that is because, if they are "published," anonymous readers can read, (edit !) and comment on them, despite the fact that they are in the "" issue and even though I have permissions for this node type set not to allow edits by anonymous users! How can this be?! Help!

As far as workflow goes, to avoid upheaval among the troops, I had to rig the workflow and actions modules to work with e-journal. I also had to make a small hack to the node module so that the state would only change after all of our proofreaders had completed their edits. Fighting that battle along with having to meat the deadline for our April issue prevented me from looking at this thread for over a week!

baraban’s picture

baraban commented

P.S. This may help you help me: Anonymous edits are only allowed if the article is marked "proofreader approved," but viewing and commenting is available regardless of the proofreader mark.

romca’s picture

romca commented

dear baraban,

excuse me for writing with such a delay. I was just moving from one country to another.
Please try following: (probably in the testing site first)
- go to the permission table of drupal and have a look if there is something as "all" (i don't remember exactly, but there could be one domain which can grant access to all, this one should be changed or deleted)
- in the e-journal, click on CHECK ACCESS RIGHTS button

then the access rights should work fine for "published" nodes even if they are accessed by other users before their publication
Pls let me know and sorry again for the delay,

roman

romca’s picture

romca commented
Status: Active » Closed (fixed)