submit config

We have two workareas (help and legal) under one branch. in each workarea, we have help and legal directory. Now we want to make user can only edit help content in help workarea; edit legal content in legal workarea. How could we achieve this via submit.cfg ? help workarea is owned by user help and group help_users.

If we do :
^/default/main/testbranch/WORKAREA/.*$
{
^/help/.* { perm=0775 uid=help gid=help_users }
^/legal/.* { perm=0775 uid=legal gid=legal_users }
}
It will make help user could edit help content in both workarea.

Also since we have already submit the content to the stagine with above submit.cfg, if we modify the submit rules, how could we fix the permission of the centent ?

Edited by judy on 10/31/02 03:41 AM (server time).

Find more posts tagged with

Comments

Adam Stoller

You have to use a combination of the submit.cfg (as you already noted) and workarea access permissions. You setup the 'help' workarea so that the "help_users" have access but not the "legal_users", and vice-versa for the 'legal' workarea.

By doing it this way - the directories are protected correctly regardless of which workarea one is in, and the workareas restrict who can perform any work within them at all.

--fish
(Interwoven Information Guy)

Migrateduser

create a script and "touch" everything single file and then run submit the entire workarea. This way all the permission will be changed properly is needed.

judy1

Thanks for reply.
However our current situation is, we have few people in our content team. So they are basically in all groups. Say, author 1 is in help_user group, also in legal_user group. So he would have access to both help and legal workarea. Then submit.cfg would not restrict him to do edit in the directories even he is not in the right workarea.
Is there any tricky thing i could play in the submit.cfg ?

Adam Stoller

If the person will have access to both workareas - then they would have access to the directory in either workarea - yes. I hate to make this sound like a trivial question, but: Does it really matter then?

If you use the access rights on the workareas and the submit.cfg to control access rights on the directories within the workareas - as your content team grows, fewer people will have access to work across the boundaries.

Right now - if you really have only one team with two names - maybe you should just have one workarea (in general) and create other workareas for short-term work as-needed.

Obviously I don't know anything more about your situation than what has been posted within this thread - so I could be over simplifying the situation. If that's the case, perhaps you could provide more of a case-scenario to explain why you feel the need to do what you are trying to do?

--fish
(Interwoven Information Guy)

tvaughan

I wouldn't recommend the 'touch all' solution in the long run because you're cramming your backing store full of meaningless revisions. You'd be apt to run out of inodes quicker than a Bush can say 'war'.

Tom

Adam Stoller

In 5.5.2 (and possibly earlier 5.x - I cannot remember) there is a CLT called iwfsshrink that can help to relieve the backing store of duplicate revisions of the same file (i.e. that differ only in terms of metadata).

I wouldn't necessarily recommend using the touch * approach either, but if you do ...

--fish
(Interwoven Information Guy)

Capture.PNG