Jump to content


P4 Protect, Group Write access to everything BUT anything matching a specific folder name

p4 protect p4 admin

  • Please log in to reply
5 replies to this topic

#1 jknobel

jknobel

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 10 October 2017 - 05:08 AM

Hey there,

Basically what I'm trying to do is allow access to a group of users to everything in a depot except folder(s) matching a specific name. I'd only like to give that permission to a different specific group.

e.g.
Group Developers can read/write everything in the Project depot except folders matching Console
Group ConsoleDevelopers (A sub group of developers) can read/write the Console folders

I've tried the following to no success.
p4Protect.PNG

Which is odd as the last line no access group Developers correctly overrides the original developers access to that specific stream.

Are folders not written the same way in p4 protect as they are in Stream views or am I just doing it wrong?

Any help would be greatly appreciated!

If you need anything else from me please let me know.

Cheers

#2 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 325 posts

Posted 10 October 2017 - 05:30 AM

Protections (and most specs) use absolute paths rather than stream-relative paths.  I think this is the protection structure you want (if you run "p4 protect" you can just paste this in):

	write group Developers *  //Project/...
	write group Developers * -//Project/Console/...
	write group Developers * -//Project/EngineStaging/...
	write group ConsoleDevelopers * //Project/Console/...

I tried to simplify it a little for readability -- since the ConsoleDevelopers group never gets access to anything else in //Project, removing access from that group is unnecessary. Similarly, you only need to remove Console/... access from Developers.

#3 jknobel

jknobel

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 10 October 2017 - 05:36 AM

View PostSambwise, on 10 October 2017 - 05:30 AM, said:

Protections (and most specs) use absolute paths rather than stream-relative paths.  I think this is the protection structure you want (if you run "p4 protect" you can just paste this in):

write group Developers * //Project/...
write group Developers * -//Project/Console/...
write group Developers * -//Project/EngineStaging/...
write group ConsoleDevelopers * //Project/Console/...

I tried to simplify it a little for readability -- since the ConsoleDevelopers group never gets access to anything else in //Project, removing access from that group is unnecessary. Similarly, you only need to remove Console/... access from Developers.

Thanks for the reply! Yeah sorry I tried to simplify it potentially a little too much so my question didn't come across as well. Problem is that works if the folder is at root, ideally what I'm looking for is to prevent folders being accessed if they are called Console anywhere in a stream. (Console will be replaced with specific platform names). Much like you can do with ignoring in Stream Views.

Hope that makes sense

#4 jknobel

jknobel

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 10 October 2017 - 05:40 AM

Additionally I'm wanting to restrict all users by default to not be able to access folders matching Console, not just developers, hence the wild card usage.

#5 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 325 posts

Posted 10 October 2017 - 06:54 AM

Ah, so you want something like:

	write group Developers		*  //Project/...
	write user  *				 * -//.../Console/...
	write user  *				 * -//.../EngineStaging/...
	write group ConsoleDevelopers *  //.../Console/...

I'd recommend against doing this, personally, and organize your depot such that those "Console" and "EngineStaging" directories are somewhere more specific rather than scattered at arbitrary locations through the directory structure.  The above setup will let ConsoleDevelopers create a "Console" directory at any part of the depot hierarchy (even though they may not be able to see the containing folder, which may lead to some weird conflicts), and as you add platforms you may see performance problems with the mappings.

The initial idea of just having //Project/Console1, //Project/Console2, etc will lend itself to much easier depot management.  Remember that if you need to pull files into specific juxtapositions for a build this is easy to do with workspace views; it's better to optimize your basic depot structure for the way that most of your developers are actually working and for the way that you need to control access.

#6 jknobel

jknobel

    Newbie

  • Members
  • Pip
  • 6 posts

Posted 10 October 2017 - 07:48 AM

View PostSambwise, on 10 October 2017 - 06:54 AM, said:

Ah, so you want something like:

write group Developers * //Project/...
write user * * -//.../Console/...
write user * * -//.../EngineStaging/...
write group ConsoleDevelopers * //.../Console/...

I'd recommend against doing this, personally, and organize your depot such that those "Console" and "EngineStaging" directories are somewhere more specific rather than scattered at arbitrary locations through the directory structure.  The above setup will let ConsoleDevelopers create a "Console" directory at any part of the depot hierarchy (even though they may not be able to see the containing folder, which may lead to some weird conflicts), and as you add platforms you may see performance problems with the mappings.

The initial idea of just having //Project/Console1, //Project/Console2, etc will lend itself to much easier depot management.  Remember that if you need to pull files into specific juxtapositions for a build this is easy to do with workspace views; it's better to optimize your basic depot structure for the way that most of your developers are actually working and for the way that you need to control access.

I completely agree, problem is the console code/content is additive to the existing engine code base and not something that can be out of it. Ideally I'd house the code/content in a seperate stream but because it's additive that won't work with view management due to streams not supporting overlay mapping. Which is a real pain...

Thanks heaps tho, that worked!





Also tagged with one or more of these keywords: p4 protect, p4 admin

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users