Showing results for 
Search instead for 
Did you mean: 
Showing results for 
Search instead for 
Did you mean: 

user rights --> move


Re: user rights --> move

Agree with Darren - Move permissions can be tricky.


- 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.

Re: user rights --> move


  • The states were set to All
  • how can I see if I am a participating member of the container team?
  • I changed the permissions for subfolder like you said, but I can't select any source or target context
  • I don't have any deny permission
  • where can I check the domain of a folder
  • I think we have some lifecycles, but I don't know if they are advanced or not.

Sorry for all my questions, but I realy want to figure this out

Re: user rights --> move

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 7-9-2014+7-22-49+PM.png

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.

Re: user rights --> move

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!

Re: user rights --> move

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.


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.

Re: user rights --> move

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.