• State Not Answered
  • Replies 9 replies
  • Subscribers 59 subscribers
  • Views 7376 views
  • Users 0 members are here

ProjectWise - Users Cannot Modify/Delete Subfolders They Create

jcallicott
Offline

I have a simple - or so I think - question regarding ProjectWise folder security:

I have a situation where users cannot delete, rename, or otherwise modify a folder they themselves created.

Here is the background: my organization is preparing to launch several projects in ProjectWise (08.11.11.574). Like many organizations, we have a simple but standard folder directory structure (FDS). The folders are pretty intuitive as to what goes where, so we want this same FDS available for consistency on all projects. So we have set folder security on these folders so that users cannot modify or delete them. "Write" and "Delete" are checked off. No problem.

However, we also want users to be able to create subfolders at the ends of this FDS. So in folder security, we enable "create subfolder". Still no problem.

And we want users to be able to create, move, rename, or even (gulp) delete documents they create in those folders. So in document security, we allow File Read, File Write, Read, Write, and Delete. Again, still not a problem.

Now, suppose a user wants to rename, move, or even delete a subfolder that's not a part of the standard FDS - it got created by them or some other user. For example, suppose the folder "Roadway" is part of the FDS. A user creates a subfolder underneath that called "Interim". Now, suppose it's a few weeks later and that folder "Interim" is no longer needed. Or, when it gets created, it gets mis-typed as "Ineterrim" or some other undesirable name. In the former instance, the user decides to delete the folder.

Problem.

In the later example, the user decides to try and rename the folder.

Problem.

As far as I can tell, the user is stuck - it can't be done. The subfolder "Interim" (or its mis-spelled cousin) has inherited its properties from "Roadway", which means that "Write" and "Delete" are also off in the new subfolder. They can create, edit, and modify documents (including deletion) in the new subfolder, but not the new subfolder itself.

Any suggestions? I have even looked into workflow-based security, but the problem there was that to make that work the users need to be able to change the state. That means they would be able to change the state of the standard FDS folders too. Of course, the other thing is that it creates extra steps and isn't really going to get us where we need to get.

Is there maybe a way the user could change the subfolder's permissions through access control tab and then manage to get at it that way? Of course, that assumes the user created the subfolder. What if they are trying to modify or delete a subfolder created by another user (who may well no longer even be with the organization)? Either way, seems overly complicated.

This situation is regularly accommodated in Windows via permissions. I'm sure ProjectWise can similarly support it, but I've busted my brain trying to figure out how. I think I have to be be missing something obvious, or it's maybe really, really subtle. Regardless, I'm open to suggestions and would love to hear any ideas.

Thanks!

  • 0 Offline in reply to Kevin van Haaren

    Kevin,

    I thought of doing the same thing - a state change command that would in effect delete the folder.  I even went to that session at Bentley together this year and got a lot of insight out of it, even though we opted not to go that route.  We figured it was more administrative load to hunt down and deal with the soft-deleted files/folders rather than get requests to delete folders one in a while.  

    I appreciate all the replies!  

    I'm surprised this topic hasn't come up more on these boards in the past...

  • 0

    This leads to an interesting topic, I don't have an answer to your issue but I'm also looking at creating a standard folder structure and feel I have to re-think what users want (carry existing windows folder structure into PW) with how PW works in handling documents and folders.

    Today's windows world project after project we find empty folders. Our company windows folder template is broken into 9 disciplines and each discipline breaks subfolders and can go as deep as 5 levels, the entire template consists of 141 folders ..... just crazy to me and more than 75% of those folders are empty!!! No I had nothing to do with creating that structure.

    With utilizing metadata I'm planning 9 discipline folders and no more than 5 subfolders for each discipline allowing no users the ability to create or add folders in PW that's two levels, in fact you can actually use just ONE folder in PW but the reality is that new users to an EDMS system like PW can relate to a one folder system.

    I'm always curious how companies structure their project data especially in EDMS like ProjectWise.

  • 0 Offline in reply to Dale Carlin

    Dale,

    I sounds like we think similarly. We tried to make the folder structure as simple as we could, yet keep a series of folders the same from project t project for consistency's sake.  But one difference is that we are allowing users the ability to create folders if they need them.  it's just strange how this is working out in regard to users being able to delete files, but not folders.  

  • 0 Offline in reply to jcallicott

    we try to restrict who can create & delete folders on a project to a small number of people (the project picks who they are). We've found letting everyone on a project to create files at will leads to a mess. Folders that no one knows what they're for. Tons of duplicate files as people create folders and dump files into them then reference in their own working files. We really wouldn't want to everyone create folders at the end of a file structure as the deeper in the tree something is the easier it is to hide duplicates and clean up.

    By restricting who can create/delete folders the project itself has control of folder structure and forces people to contact the appropriate people to have their folders created. Some projects do want certain groups of people to be able to create folders just in certain parts (e.g. CADD folder or Project Management folder). We do this too, but it's always towards the top of the folder structure so we don't have to change permissions on a ton of sub-folders.

     

Communities
Support and Services
Training and Learning
Social Media