user rights --> move

[rvanveerdeghem]

All our normal users can't move WTParts and WTDocuments, only the admin can do this. Where can I change this?

[MikeLockwood]

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.

[rvanveerdeghem]

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?

[kpritchard]

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.

[DarrenStorey]

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

[rvanveerdeghem]

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.

[DarrenStorey]

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

[MikeLockwood]

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

[rvanveerdeghem]

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.

You cannot move these objects because you do not have the necessary permission to change context for one or more of its versions.

You cannot move these objects because you do not have the necessary permission to change domain for one or more of its versions.

I don't get what I do wrong.

[DarrenStorey]

Ruben

• Are absolutely sure you have states set to ALL
• Are you definitely a participating memeber of the container team on both source and target contexts?
• Did you also define the permissions for Subfolder on both source and target contexts. If the ACL set in domain which is a parent of both target forlders?
• Have you got any conflicting DENY permissions in this domain or any of the affected lower domains, these would take precedent?
• Check the domain allocated to each folders (source and target)
• Go to the domain of the folders and generate a policy report for WTDocument and SubFolder
• Are you using advanced lifecycles for the document? If so you may have additional permissions defined in the lifecycle template, which take precident. Check all revisions of the document share the same LC template? Different revisions can use different versions of the template or even completely different templates?

Darren

[MikeLockwood]

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.

[rvanveerdeghem]

Darren,

• 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

[LoriSood · Accepted 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.

[rvanveerdeghem]

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!

[MikeLockwood]

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.

[LoriSood]

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.