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