Sometimes you need more than just assigning permissions for users to edit parts of a website - you might need to have a certain cycle in place where the job to create content is passed on to a user who does it but cannot publish without a review from a person responsible for the final content. Having such an approval cycle is exactly what workflows are for. In other cases they are just a useful way to collaborate on content because you can pass it back and forth between people in a work group.
So what is this in practice? On the "FC Bigfeet" site you will already find a simple workflow in place. The workflow is designed to let a user called "news" receive the task (To-Do item) to create a news-item for the website. When he is done he sends the To-Do task back to the sender who will review the contents and if all is OK, he will finalize the process which means the item is automatically moved to the news archive and possibly shown on the front page as well!
First, let’s take a look at the user called "news". Try to login as "news" (password "football"):
You have been used to see the Page module and some other stuff - but the "news" user has been restricted to see only the Task Center module! This is enough for him since he will just have to check his Inbox of Tasks. That is empty at this point, so he has not been assigned any tasks yet.
Well, logout again and return to the backend as the "admin" user. You will now start a new workflow process by assigning a To-Do task to the "news" user.
Create task
So go to the Task Center module, click "Tasks"...
Then create a new workflow. There is only one kind right now (you will be shown how to configure other workflows later):
Most importantly you have to select a target (#1). This can be either a group or a specific user. We have selected the user "news" as we planned. Then a title (#2) and description (#4) wouldn't hurt - this is simply the job description the target user will see - to make sure he knows what to do when he reads this. The deadline (#3) will set the deadline of the task and later it will help you to keep track of which To-Do items have passed their deadlines (hopefully none of course).
Finally you can have the system send an email (#5) to the target user when you press the "Create" button - cool, if the target user is not exactly a TYPO3 junkie logged in all the time - then most likely sending him a mail is a good idea! (Requires the PHP function mail() to work!)
After the creations you will be returned to your overview of To-Do elements:
The "Outgoing To-Do items" are the ones you have created and which are awaiting some action from another person. In this case the "news" user.
Click the title if you want to see the details:
As you can see the information is all there. Currently no status has been assigned from the "news" user.
Accepting the task
Log in as the "news" user:
Tip: If you start a new browser window of Microsoft Internet Explorer from the icon on your desktop (contrary to using CTRL+N) then you will be able to log in as another user - the "news" user - and thus have two different windows running as a user each. This is possible because Internet Explorer doesn't share cookies between those two windows.
In the Task Center the "news" user will see this:
Nice. The "News" task is there! Click it in the left frame. You will now see the details as you did before as "admin" user:
As the "news" user you select "Add Status" to "Begin task now", then enter a status note like "OK!" and press the button.
Now you will see a form for a news item appear:
This item has just been created for you as a part of the "Begin task now" status you added. This element is attached to the task now and all you need to do is enter the content. When that is done and you press "Save document and close" you are returned to the Task Center. Pressing the title of the To-Do Item again allows you to see the updated details:
As you can see the element is attached here and by clicking the edit pencil you can edit it again - until you are ready to inform the "admin" user that now it is all done!
When the item is edited and ready to be published (in your opinion) you change status to "Pass on to another user/group" (this could also have been used to pass the task on to a colleague if someone else should rather solve the task!), select the recipient (in this case the "Sender"), add a note if you find that necessary and press "Send new status".
And your To-Do list is now blank, just waiting for the next job.
Finalizing the workflow
Back as the "admin" user you will see that the To-Do task has been returned to you now:
When you click the item title here you will see the details. Click the edit pencil in order to review the content:
Apart from checking the content of the news item (a little tame here, isn't it... ) you should also determine whether this element is worthy of a position on the front page. That field was not accessible to the "news" user - it is an excludeField.
When you are happy with the item you activate the final stage by selecting "Finalize workflow" in the "Add Status" selector:
That's it. This step finally moved the news element to the news archive and made it online on the frontpage:
"Done"
The last thing now is to dump the To-Do item in the garbage bin: Simply check it "Done" and select the action "Delete marked To-Do items":
A workflow like the one we have just cycled through is configured as a record in the page tree root. As with all records in the page tree root you will have to be "admin" to edit and create then:
Such a record contains these fields:
Apart from a straightforward title and description (#1) the record first and foremost defines from which table (#2) in TYPO3 elements should be created! This means the workflow system can be used to control the creation process of not just pages and page content elements or news items - but any item!
Obviously some tables are more interesting in this context than others but the principle applies to it all. As you wish.
The "Draft Page"
The next principle of great importance is the "Draft Page" (#3).
The sysFolder "News items draft page" is created as a safe repository where the "news" user can create whatever he likes and it will harm no one. This sysFolder works as the Draft page. When the "news" user sets the status "Begin task now" the News-element attached to the task is automatically created in this folder!
The News-item stays in this folder until the workflow process gets finalized by the sender - then it is removed from here and inserted on the "News" page - as the "Move to page when finalizing" field (#6) obviously indicates.
Target groups and review users
Between the "Draft page" and "Final page" you will find the fields setting "permissions" for the workflow. By "Target groups for workflow" you specify which users can receive a task for creating this item. In this case only users that are members of the "News editor" group can receive the tasks.
The workflow here is a simple "[Editor] -> [Author] -> [Editor]" workflow. In some cases you want a third person involved. That would make the flow look like "[Editor] -> [Author] -> [Reviewer] -> [Editor]". If that is the case you create a relation to a reviewer user in field #5.
Finally the "Unhide when finalizing" flag is telling the finalizing process whether to un-hide the element if possible upon finalizing.
Did we forget something? Ahh, yes, the "Groups allowed to assign workflow" field - that was not discussed. So let’s just lean back and let the little funky "?" icon do the talking:
Just remember...
In order for this workflow to work - in terms of permissions for the "news" user - you will have to make sure of a few things.
The member group
The "news" user is member of the "News editor" group. That group has "Access Lists" enabled like the "GENERAL" group we already know. But the settings are of course different:
As you can see (below) only the User and Task Center modules are enabled, the News table is the only one allowed for editing and the Allowed Excludefields are of course selected only in relation to the News table:
The permissions of the Draft page
Those must be properly set of course. In this case - since we are creating elements on a page - we can do with this setting (below); the "News editor" group as owner with permission for creating new page content:
The DB mount
Also - even if no page tree is available for the "news" user - he needs the DB mount set:
This is because TYPO3s default permission system even checks if a page where a record is created is within the DB mounts of the user.
Workflow To-Do
In itself we have a little To-Do list for the development of the workflow system in TYPO3. The most obvious need is the ability to (re-) enter an existing element into a workflow. That is still not possible. Or maybe is has become possible in the mean time since this tutorial was written. In that case - please remind me to remove this notice... :-)
