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; } } }

Limit User Access to One Directory

Collin

Is there a way to limit user access to just one directory? Thanks!

Find more posts tagged with

Comments

nipper

On Unix, this can be accomplished by using differnet groups and permissions, restricting access to the other directories.

IMHO this is not a good solution since it will be a pain to maintain. You may want to look at different branches and workareas for a more maintainable solution. Don't know (or care) how you would do that on the fake OS with a 640K memory limit. :-)

Andy

Migrateduser

We use a query run by workflow to determine if the submitting user is allowed to submit to a particular directory. This does _not_ restrict users changing files in their own workarea. We wouldn't want to do that anyway. But it does prevent changes from going into STAGING unless the change is authorized.

MattP

Yes, this can be done on windows as well. For domain users, they need an isolated group. Then the permissions set to the appropriate directory. Don't forget to modify submit.cfg.

Matt

Matthew Petitjean
BOC Group
Murray Hill, NJ 07974 USA

Bowker

Well not exactly one directory.

Depending upon which version of TS you are running you may have difficulties.

We're on Win2K and TS 5.5.2

Inorder to use Templating you MUST have write access to ALL FOLDERS leading down to the one you want to modify. That is true for BOTH the generated document and the template file (DCR). For example:
If you want to have access to generate: www/aboutus/history/index.html which is generated from /templatedata/standard/standard-page/data/aboutus/history/index.dcr then you must (at least we've found this true) have write access to:
/www
/www/aboutus
/www/aboutus/history
/templatedata
/templatedata/standard
/templatedata/standard/standard-page
/templatedata/standard/standard-page/data
/templatedata/standard/standard-page/data/aboutus
/templatedata/standard/standard-page/data/aboutus/history

As you might imagine - we weren't happy. On TS 5.0.2 this was not the case.

MattP

you are right about the templatedata, I forgot about that. However, we do not have the same issue you have. I have set permissions to one directory and not all the directories leading to it.

If you want to discuss more, send me an email.

Matt

Matthew Petitjean
BOC Group
Murray Hill, NJ 07974 USA

Adam Stoller

You should only need write access (implied read/execute) on the directories where you will be writing files. You should only need read/execute (without write) access to directories leading to the directories where you will be writing content.

If you find this not to be the case, contact Interwoven Support to open a case with them for further investigation (and try to remember to include information like what platform you're on)

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

Bowker

Have you ever lived by a rule and later discovered that it may not be true?

When we started using TS 5.5.2 on Win2K we had all sorts of trouble with permissions on files and the only way (at least we thought) was by granting write access all the way down. We didn't like the answer, but it appeared from all the empirical evidence, that without write access to all the parent folders of a file, editing and generating templated files was not possible.

After my post yesterday, Fish replied that should not be the case. I created a test case and I can't reproduce the issue we had. Therefore it appears that as long as the person who wants to update a file is in the "group for sharing" and has write access to the file (or directory to create a new one) and read access to all the parent directories, that's all you need.

I would truly like to have the ability to have more than one group on the "shared with" group. Local groups that contain domain groups are not the easiest thing for us to get created/maintained.

Adam Stoller

Until all non-Windows systems [read: Solaris,AIX and hopefully Linux,MacOS-X,...] support [well] the concept of files and/or directories being shared amongst multiple groups, I think it is hard to justify conditionalizing that much of the underlying base / core product to satisfy those who run the server on Windows only.

This isn't saying I don't think it would be nice if all OS's supported this functionality - I do - but I think there are some things that are best left at the lowest-common-denominator - and the core of TeamSite is one of them. Once you start conditionalizing the code in one spot to support multiple group sharing, you have to make sure you found *every* other location in the code where the issue comes up and then as you start fixing bugs and/or adding enhancements you have to make sure you provide the same fix all over and/or that it applies in all cases, etc. Not a trivial undertaking.

Maybe some day in the future .... but I wouldn't hold my breath.

(Personally, I'd rather the server code be ported for MacOS-X and linux before something like this was attempted)

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