User managment and workflow question

I have a user who is an editor. I would like to create a new workarea for him but I need to give him author access (so that he wont be able to publish content from this new workarea directly to production).
First question... Is it possible to give the same user two different access level on two different work area?
Second Question : If above can be done then how can I set up a workflow which will notify the admin whenever this user submits the job? Only Admins will be able to submit the content to production on review.

Find more posts tagged with

Comments

iwovGraduate

A user can have multiple roles. Just add the username to the corresponding uid file.

You can configure a workflow which will be invoked on submit for that particular user, irrespective of the role they login as. This workflow will send the associcated files for approval to your "admin". Look at the autor_submit* workflow examples.
However if that user also has an editor role, he/she can bypass the default submit workflow by using "Submit Direct" as editor role. Not sure how you can prevent that. Maybe somebody else has a better solution.

Hope that helps.

INVIN0000000970SIM-L-C0.zip

Adam Stoller

Just to stir some old water here....

TeamSite roles are TeamSite server-based, not TeamSite branch (or workarea) based. If a user has the ability to login as both an Editor and an Author - then they can login within either role and use the funcationality associated with that role in any branch / workarea that they (as a user) have access.

If you want to prevent editors from being able to use Submit Direct - put the following in your iw.cfg file:

[ui_remove_menu_items]
submit_direct="editor"

This also pre-supposes that the Submit button is not configured to run submit_direct for editors (also setable within iw.cfg)

--fish
(Interwoven Senior Technical Consultant)

InvoiceDetail55.ssd.zip

13adam13

Saif, how are you performing the move to production. In our environment, we are using a Perl script to figure out which branch is deploying, and then run the appropriate deployment script. Also, within this same script, we do a test to make sure that the user is either an Admin or master, and we also ensure the the user is a member of the group for the branch. This has been pretty successful for us.

Further, if you want to ensure that an admin is aware of all submits performed to staging, then you can configure one of those wonderful trigger (iwatsubmit, I believe) to run when some submits. You can filter out those done by admins, and then send emails to all the right people when it happens.