Home
TeamSite
Group permission on folder
jmcdonald
I'm trying to get an understanding of Teamsite security on branches, workareas, and folders. Our site is running Teamsite 6.1.0 on Windows 2000. For the most part we use Content Center Professional.
Step 1:
We create a branch, and we have the option of setting a group - which I understand grants users in the group administrator access to the branch.
Step 2:
We create a workarea under the branch, and again we have the option of setting a group - which grants access to Teamsite users (let's say editors/authors)
Step 3:
This is where it unravels for me - creating a folder under the workarea. When you create a folder, it does not ask for a group, and inherits the permissions of the parent workarea. But when you examine the properties of the folder, you do have the option to input a group. What is this for and how does it differ from the group it inherited from the parent workarea?
Any direction would be appreciated.
Jim McDonald
Find more posts tagged with
Comments
nipper
One point you need to remember is that the submit.cfg file will also set the permissions on files
as they are submitted. So you can set for branch 1, owner me, group blah, and branch 2, owner you group foo.
There is still an issue as to what groups owns files that are newly created before submit. On Unix
those are set by te users primary group. On DOS I am not certain,
HTH
Andy
Adam Stoller
The group permissions on a workarea determine who can access that workarea.
The owner and group permissions of files and folders within a workarea determine who can access / modify the file or folder.
Since you can have multiple workareas on a given branch - each workarea can be assigned to different groups of individuals to work within.
Since each workarea reflects *all* the content within that branch, it is still desirable to limit access to certain files and folders for particular groups - and that access remains consistant regardless of which workarea it is viewed within.
For example:
Workarea WA has access for group-A
Workarea WB has access for group-B
both workareas contain the following:
/foo/fileA
/foo/fileB
/bar/fileA
/bar/fileB
/baz/fileB
/foo => "everyone" has access
/foo/fileA => "group-A" has access
/foo/fileB => "group-B" has access
/bar => "group-A" has access
/baz => "group-B" has access
Users in group-A can enter WA and: (a) create new files in /foo, (b) modify /foo/fileA, (c) create new files in /bar, (d) modify files in /bar, but they cannot modify /foo/fileB, create files in /baz, nor modify /baz/fileB
Conversey users in group-B can enter WB and (a) create new files in /foo, (b) modify /foo/fileB, (c) create new files in /baz, and (d) modify files in /baz, but they cannot modify /foo/fileA nor create or modify files in /bar.
At least that's how it's supposed to work.
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
jmcdonald
Thankyou for the clarification - it just seems odd that on creation of branch and workarea, the TS interface gives you the option to share them with some group, but not on creation of a folder (only when you view properties after creation)
Doesn't seem consistent, but I guess not everything has to be...at least I understand the underpinnings now.
Edited by jmcdonald on 06/22/04 06:28 PM (server time).
gsundeep
Ghoti,
Since each workarea reflects *all* the content within that branch
Is this must or optional to keep *all* your branch content in all workareas.At least, in our case we have separate workareas and different content in them.
may be i am wrong, but you would please clarify this.Sorry, for creating confusion .
Thanks,
Adam Stoller
In general - it's the "rule" that each workarea on a branch contains all the content for that branch. That's what GetLatest / iwupdate is for - to keep each workarea synchronized with the staging area.
It's the "exception to the rule" where each workarea contains different content - indicating that you've never used GetLatest - as it breaks some of the fundamental principals of TeamSite whereby everyone should be able to have a virtual copy of all files in the branch within their workarea so that they have a virtual web-site within which to view their work.
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
gzevin
Adam,
while I do concur with what you said - I found that the p[ractice of getting latest is not used so widely as you might think - and, as a result, I saw a lots of nasty problems..
One of those was the presumption by IWOV, that everybody was adhereing to this Get Latest practice - and their 5.0.x -> 5.5.2 conversion tool took that for granted....with disastrous results for my client
Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU
Adam Stoller
I'd blame that on poor customer-educaton on how to use the tool. If they're going to shell out $$'s for something, they really should be properly instructed on how to use it properly. (what appears redundant, within that last sentence, is intentional and not redundant)
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
nipper
I hate to disagree with you fish, but Greg is correct. TS is a very solid tool. I initially beleived in the
1 WA 1 user approach. Meaning lots of Get Latest, of course Authors could not do a get latest.
We have moved to large shared WAs. Mostly one per branch, sometimes two. (User and developer)
In those cases the only time a Get latest is performed is when a developer updates somethig (say DCT)
and we push it to the user workarea.
We have 200 users in 1 WA, but the work is very granular and one user does not affect another, so we
can do this without an issue. Our biggest problem is locks, which wil happen 1 WA or 200.
I just wanted to state that even though this is not in the best practices, it works very well in our environment
and it is impressive that TS works well in such diverse cases.
Andy
Adam Stoller
It's alright to disagree - I'm not *always* right ;-)
However ... to augment my argument for why not doing Get Latest is more a case of not understanding the tool:
Having a single workarea on a branch tends to negate the need for doing a Get Latest.
Having shared workareas should not negate the use or benefit of doing a Get Latest.
Having multiple workareas per branch makes doing a Get Latest periodically, more important - to avoid conflicts and to ensure that any content which relies on or interacts with other content does so correctly with regard to the latest submitted version.
Not doing a Get Latest is most frequently the result of either (a) not knowing anything about Get Latest, (b) not understanding how Get Latest deals with modified files, (c) not understanding how conflicts arise and how they get resolved, (d) misunderstanding the purpose and/or use of Overwirte mode when submitting files.
If your branch has a single workarea with 200 users in it - you probably don't need to worry about Get Latest because the latest, or latest modified version should always be in the workarea.
If you have multiple workareas on a branch - it becomes of question of whether doing a automated Get Latest every day is reasonable or whether it is believed that the individuals working within those workareas understand the issues sufficiently to run Get Latest at opportune times based on what they're working on.
A lot of it also comes down to process - if changes do not get submitted to staging without being approved, then all non-modified files in all workareas on that branch should be updated from staging daily [at least] in order to ensure the use of a common baseline for development.
If changes get submitted to staging without being approved then the process comes into question and either they need reviews or they need more branching structure to allow for rough development environments where anything goes and other integration branches where everything needs to work.
Another factor in all this is whether you're doing primarily content development or application development -- the latter tends to require more scrutiny with regard to the consistancy of a baseline.
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com