nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

permissions of people inside the workarea

Evert

hi all,

after phase one of the project is done, we're looking at phase two. one of the bigger issues we're looking for is having a more granular method of access control. atm once you have access to a workarea, you can do anything in there. with the new requirements we must be able to control what folders can be acessed, written and read by different users.

any idea, concepts, links without having to create a new branch for each folder?

regards

Evert Smit
Business Project Manager
Credit Suisse Group

Find more posts tagged with

Comments

gzevin

you did not say which platform you are running TeamSite.

on Solaris (and Linux) it's pretty easy to ensure this granularity by making folders writeable by dufferent groups, thereby making them accesible by users sharing that group (and workarea).. On Windows I believe it's also possible...

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

jed

I do not know the exact setting off the top of my head, but do a support site search for something like mask_workarea_access. If this is not found in a KB, it might be in one of the old release notes. With this setting, you have more granular access to permissions (on solaris at least).

I have no support site access right now, so I am unable to track down the exact flag.

Adam Stoller

The article appears to be: https://support.interwoven.com/kb/kb_show_article2.asp?ArticleID=50543 however it was originally written and last listed as modified on 2003-10-31 and does NOT contain any information about for which version(s) of TeamSite it applies -- however it does appear to be documented in the TeamSite 6.5 Administrator's Guide [for Unix] on page 66. Neither article or documentation is particularly verbose, but they might provide the functionality for which Evert is looking.

(thanks for the pointer, jed, - I hadn't heard of this option before)

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Evert

ts 6.1 on solaris 9

based on groups, wouldn't we run into teh 16 group limitation with about 800 branches ?

thanks
Evert

Evert Smit
Business Project Manager
Credit Suisse Group

Migrateduser

There's several ways around that, too. One of which is by using map_secondary_to_primary_gid - a lengthy post on the topic is located at http://devnet.interwoven.com/forums/cgi-bin/showflat.pl?Cat=&Board=PRODUCTS_TEAMSITE&Number=27877&page=&view=&sb=&o=&part=all&vc=1.

Dave

Current Environment(s):
(1) TS 6.1 SP1 on W2K3
(2) TS 6.1 SP1 on W2K
(3) TS 6.1 SP2 on Win2K

Adam Stoller

The map_secondary_to_primary_gid is a hack that has (a) performance implications and (b) confusing semantics.
If you really need it - use it - but if you can avoid it do so.
6.5's TeamSite Groups is a better mechanism though it would be nicer if the iwgroup CLT could be used by any *master* user [not just 'root'] for administrative tasks and if it could be used by *any* user for query operations [feature request already filed for this last part].

I *think* that if your Solaris system is configured to authenticate directly against LDAP that you should be able to configure TeamSite to do so as well and be able to eliminate the need to create local disk accounts on the TeamSite server. I don't think there is any way to circumvent the NFS-imposed 16-group limitation at the OS level or even via LDAP (I could be wrong here - haven't done much LDAP integration work) and there doesn't seem to be any direct tie-in from LDAP to the iwgroup CLT in 6.5 (you could create your own process for extracting information from LDAP into the appropriate XML format and feed it to iwgroup though).

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

reportA.JPG

reportB.JPG

Migrateduser

He's using 6.1, not 6.5. He stated this very clearly.

Current Environment(s):
(1) TS 6.1 SP1 on W2K3
(2) TS 6.1 SP1 on W2K
(3) TS 6.1 SP2 on Win2K

Adam Stoller

I understood that he was using 6.1 - I was simply trying to indicate what additional features would be available if/when they move to 6.5 - sometimes its significant enough to push forward an upgrade, sometimes its insignificant enough to wait for the next major release ...

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

I wish it was that easy to push all the buttons necessary in an organization to influence them to upgrade. I'm still dealing with 3 implementations of 6.1. I'm not complaining, but I'd sure like to get my hands on 6.5!

Dave

Current Environment(s):
(1) TS 6.1 SP2 on W2K3
(2) TS 6.1 SP1 on W2K
(3) TS 6.1 SP2 on Win2K

gzevin

you probably would, if the users HAVE to share all these 800 branches but I also am thinking of moving towards 6.5 with etamsite-based groups.

(also - IMO - 800 branches is something out of whack - don't you agree?

)

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Evert

OT:
hmm don't think it is outta whack, really, as they are 800 different sites, managed by about 60'000 people. Smiley Happy

Evert Smit
Business Project Manager
Credit Suisse Group

gzevin

Ok then

however - do they all need to share so many branches?

I agree, that some users would, but not that many

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Evert

well, that is really a good questions. i am nto technical enough, but as your acces concept is based on rbanches and in 95% these people only are allowed to edit one site, we had to create a branch per site. also the requirement to have per site it's own edition die not make things easier. if you have better ideas however, gosh i'd love to hear em.

regards

Evert Smit
Business Project Manager
Credit Suisse Group