Community Tip - Need to share some code when posting a question or reply? Make sure to use the "Insert code sample" menu option. Learn more! X
All our normal users can't move WTParts and WTDocuments, only the admin can do this. Where can I change this?
Solved! Go to Solution.
Ruben, in which contexts/domains are you creating your permissions for the Subfolder object? Are you opening the Policy Admin from the Utilities page of the target and source domains or from within Site or Org utilities? You should be opening it from the source and target utilities page.
If you can see the container (product/library/project) in your product/library/project lists then you are a member of the team.You can see which specific role you're associated with on the container's team page.
The associated domain is listed on the Manage Security page for the folder
To be honest, if you guys have active maintenance a tech support case may be the easiest way to resolve this. A webex could help clear up where/how the permissions are getting created.
There are 3 ACL's related to move - look in Help on this. Fairly good diagrams and explanations in Windchill help. Search for, for example, "Create by Move."
Where possible, put this permission at Org level so it will apply to all Products and Libraries.
I tried to change a few things in the administrative domain, but it doesn't work. I even got myself a full control and it still doesn't work. The window looks like this:
Or do I have to restart windchill to complete the changes?
If Create by Move works on it's own please post and confirm. I suspect you may need to set ACL to enable a Delete permission in the outbound location.
See this http://www.ptc.com/cs/help/windchill_hc/wc101_hc/index.jspx?id=AccessControlChp_ReqPermissionMoveObj&action=show
on the source folder you need modify
on the target folder you need modify
on the object being moved you need change domain, change context and create by move.
delete is not required, this action is not related to move
Don't forget also that picking one permission set automatically picks other.
Regards Darren
I get what I need to change, but I don't know where I can do that and how.
Forgive I just got the admin rights and I'm a newbie for this.
Exactly what you do depends very much on your access control stratergy. I can provide an example of one stratergy.
If you would like every participating member of every product, library and project to be able to move any type of document at any state from any folder to any other folder in any other product, library or project then you could do the following. The user must be a participating memeber of the target container team also.
In policy admin tool
Add the following to the "default organization" domain
Type - WTDocument
States - ALL
Permissions - change context, change domain, create by move, read
Roles - Context Team Role: Team Members
Type - Subfolder
Permission - modify, read
Roles - Context Team Role: Team Members
To limit this to certain types of documents then select the subtype of document instead of WTDocument.
To limit this to certain contexts then put the rules in each affected context "default domain" rather than organization default domain.
To limit this to certain roles/groups/users then create seperate rules for each affected principal instead of Team Members.
You will also need permission to read and modifify the cabinet in the target content, but you should have this already OOTB.
Regards - Darren
No restart needed - changes via Policy Administrator are effective immediately.
Have to go very methodically with a test user (in IE, File, New Session, launch Windchill gives a separate login for test user).
Hi Darren,
I tried what you said, I even tried the following:
Type - WTObject
States - All
Permission - Full control
Roles - Context team role: team members
This is the error I get when I try to move something from folder to another context and folder.
I don't get what I do wrong.
Ruben
Darren
Agree with Darren - Move permissions can be tricky.
Suggest:
- Create a test user (if you can). Do not add them to any groups or context teams.
- Make that test user Manager of both contexts (move from, move to) to ensure that they can Move
- Then, remove them from the Manager of both contexts.
- Create a test Group (Org level) and add the test user to the group.
- Apply ACL's methodically to the Group with the test user.
- Map the test Group to the Members Role of both Contexts.
- Apply Full Control All ACL to the object to be moved in both contexts
- Back off and apply only the 3 Move-related ACL's in the two contexts
- Once working, consider not applying the needed ACL's in each Product/Library at all; instead, apply at Org level, to be used just once and applicable everywhere.
Darren,
Sorry for all my questions, but I realy want to figure this out
Ruben, in which contexts/domains are you creating your permissions for the Subfolder object? Are you opening the Policy Admin from the Utilities page of the target and source domains or from within Site or Org utilities? You should be opening it from the source and target utilities page.
If you can see the container (product/library/project) in your product/library/project lists then you are a member of the team.You can see which specific role you're associated with on the container's team page.
The associated domain is listed on the Manage Security page for the folder
To be honest, if you guys have active maintenance a tech support case may be the easiest way to resolve this. A webex could help clear up where/how the permissions are getting created.
Hi Lori,
I did use the policy admin for organization or site.
If I use the policy admin for the two folders like you said, then it works like a charm.
Now I did the same in the organization policy admin to default pdm. After this I can move wtparts and wtdocuments to every folder I want. Thank you for helping me!
This thread and the one about folder structures are sort of related.
Users LOVE to create zillions of highly-nested folders in Windchill - not needed at all really. If you don't have many folders and rely on search / reports always, then permissions for moving between them becomes something no longer needed and only moving between contexts remains an issue.
Note that you cannot move an object between contexts if the lifecycle / versioning are different.
so...
For moving between folders in a given context, there is probably very little downside for enabling this for all users - can't do too much damage. Can put the ACL's for this just once at Org level.
For moving between contexts, there may a lot more considerations. Can give this permission also just once at Org level, to a select group who will follow all needed related rules.
Sprinkling hundreds of move-related ACL's thru many products and libraries creates a maintenance nightmare.
Hi Ruben,
Are you using different domains for each of your folders within a product or are they all using the Default domain? OOTB any folder created within a Product will use the Default domain of the product. That means that all folders will have the same permissions applied and you should be able to move to any folder within that product.
You will still need to ensure that the permissions are set correctly for each product domain.