File permission

Hi:

I have a customer who wants to protect all the non-templatized files from being modified by users (i.e. using launchpad to download and edit), but it would be a disaster to go through the whole site to set permission to read only for each file, especially with a growing website.

My original thought was to set all directories to readonly but the templatedata directory, and all HTMLfiles will be generated through workflow. But it did not seem working although when users click edit on templatized html files TeamSite UI brings up DCR for editing.

I am wondering if there is an good way to provide a solution?

Any help is highly appreciated!

Thanks

Find more posts tagged with

Comments

iwovGraduate

You can keep those non-templated pages in a separate branch to have a better control over permissions. You'll probably have to make a bunch of other design choices/changes and possibly some architecture changes. Since I don't have any specific information about your requirements/architecture/etc. I can't comment much on that.

Setting permissions individually in directories/files within a workarea usually becomes an administrative nightmare.

Adam Stoller

It may not be the solution you're looking for - but you might consider handling this on the back-end where you have more control.
I.e. - within your workflows - you can check whether any file attached to the workflow is non-templated (by checking EAs) and if it is - check to see if the file already exists in STAGING. If it doesn't exist in STAGING - do you allow it to be submitted? If it does exist in STAGING you can either reject the job completely or just reject those files (perhaps even updating them from STAGING) and then remove them from the job -- if there are no files left after this has been completed, abort the job (I'm assuming email notification of some sort would be sent when such a situation is encountered).

It's basically going along the lines of user-training followed by programmatic enforcement -- if they keep getting emails about changed non-templated files not being allowed (and having them reverted), eventually they should get the message....

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

mike_jaixen

We accomplish this via the approval and deployment workflow. We check all the files being submitted and deployed, and people who attempt to deploy huge (i.e. 700K JPG's from digital cameras) or non-standard files (.swf flash animations or raw HTML) are rejected; we provide a "grovel for permission" on rejected files in case there someone actually needs to put a file like that out there. So they can edit the files all they want, but they won't get deployed anywhere. It's a simpler compromise, since if someone does something they shouldn't have done, we can always go back to the last good version.

Freedom

Thanks for all your help.

It seems like WF is the feasible solution. What if the customer wants to limit users' ability to create non templated files?

Thanks

Adam Stoller

If the workflow guards against un-approved non-templated file submission then all that will happen is that you may end up with a bunch of non-versioned files sitting in the user's workarea (you workflow could even remove them if you wanted -- but I'd be careful regarding just how much "power" you give the workflow...)

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

Freedom

I think the alternative way is to disable the "edit" button on the UI and create a "edit" function that can meet the needs. Right?

Adam Stoller

You said you wanted to prevent "users' ability to create non templated files" -- just blocking the edit button isn't sufficient.
There's Import, and New File through the GUI and any number of ways to do things through the filesystem (granted one could submit through the filesystem without being blocked by the workflow concept too).

I think the WF solution offers the broadest coverage and allows the most leniency too (if designed to do so).

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