Vault Error: 303 Issue on Check in

[tschaeferZNBXX]

I have users which when they check files in they receive the 303 not having permissions issue.

We have combine Object and State based security.  

Users have read/write rights for both the state and folder.

They are in the correct groups and roles.

Why would they receive this error if they have the permissions?

@tschaeferZNBXX for clarity @Jason.Courtemanche edited the original subject: Error 303 Issue on Check in

[rtowne72]

Are they in a group that has explicit deny roles set?  I had a user who had this set and it was preventing him from doing the same thing, once I set the permission to blank in that group he was able to  make the change.  This was actually a group that belonged to a business unit group, had me a bit befuddled at first.

[Jason.Courtemanche]

Hi @tschaeferZNBXX

I'm just checking in to see if you need more help with this. Did the suggestion that @rtowne72 provided work for you?
If so, please click Accept as Solution on the posts that helped you so others in the community can find them easily.

Regards,

Jason

[ihayesjr]

To make sure you have a complete understanding of security, you can review this class: Security Awakens: Defending Against the First Order

[tschaeferZNBXX]

Right so question when it comes to transitions:

Would a transitional state outside of WIP affect WIP files?  All security is set correctly along with folder level security and I do not use DENY for any users.

[ihayesjr]

Security is based on its current state not other states in the lifecycle. Are you sure you are looking at the right file or folder the user is checking into?

[Thomas_Helm]

Hi,

you should also check if you have used the group everyone somewhere in folders or state security. If this group has only read access, it would overwrite the write access for all other users/groups.

Cheers

Thomas

[ihayesjr]

Let me add some clarification to Thomas' comment.

If a subfolder only has the Everyone group which has only the Read permission, then the user will not be able to check in the file in that folder.

If the subfolder has both the Everyone group with only the Read permission but has a different group with all permissions, then the user will be able to check in the file in that subfolder.

Permissions are least restrictive meaning in the ACLs if any group setting gives the user Modify permission, then the user has modify permission. The only exception is the Deny permission which will deny the permission regardless of other group settings.

[tschaeferZNBXX · Accepted solution]

We believe it is a permissions issue with Vaulted Factory Assets.

We modified the Custom Objects Configuration for Factory Layout.  There was a permission in the security of these which was set to deny.  Changed that and it worked as expected.

Was unaware of this setting because the group had all right to modify custom objects so we thought that would cover this.  This is a prime example of not using the DENY option.

Having these security settings deep inside custom objects it is easy to forget about them.