Automic Workload Automation

Sorry - seems like I've asked similar questions, but still trying to work this out.  At this point I am trying to confirm that you CANNOT set up a user group to allow READ access to ALL folders, but only EXECUTE access to a single folder.  I can't see a way to do this.  Am I missing something or can someone show me how this can be done?

Thanks in advance.

Hi Laura,

not tried yeat but I guess you have to use the following

1 - FOLD - \* - R

1 - FOLD - \folder* - X

NOT - FOLD - \folder - R

But: what should an X autorization on a FOLD object provide?

Sorry for delay in responding to my own post peter_grundler_automic .  In looking at the online HELP and the authorization table, you are right - there is no X ability on a folder.  

This is my scenario I have 2 folder paths:

\FOLDER1\SUB_FOLDER1     (RWD)
\FOLDER2\SUB_FOLDER2     (R)

The user needs to have access to both folders so obviously they get R access.  But they should have full access to SUB_FOLDER1 - so I also granted them W and D access as well there.

The user should be able to create, execute, etc. jobs, jobplans and includes (keeping it simple).  

But they only should be allowed to do this in SUB_FOLDER1, not SUB_FOLDER2.

Without naming conventions on the object I do not think that there is any way to restrict them from creating a job in SUB_FOLDER2.  

Can anyone confirm?

Thanks.

hmmm could work creating 2 groups
[edit] no, must be one group

one for allowing RWX FOLD1, SUBFOLDER1, etc
one with NOT WX in SUBFOLDER2

but this is just my 2 ....hmmm no just 1 cent...

I just ran some tests with that (Version 10.0.3).

I didn't put any of the permissions into a group, but directly into the user, but I highly doubt that matters for the result.

Permissions:
a) Group 1 FOLD \PERSONAL_FOLDER\SECTEST\FOO RWXD
b) Group 1 FOLD \PERSONAL_FOLDER\SECTEST\BAR R
c) Group NOT FOLD \PERSONAL_FOLDER\SECTEST\BAR X

With this setup:

1. user can view, create, edit, execute objects in FOO - as expected *)
2. user can view, but NOT create, edit objects in BAR - as expected           (edit: mistake in original post corrected!)
3. user can execute his self-created objects in FOO - as expected
4. user can execute objects made by someone else in BAR, confirming the documentations claim that there is no "X" (or NOT "X") propagation from folders to the objects contained therein.

*) of course user also needs the respective namespace permissions to create an object in general, i.e. at least write permissions for the object type and pattern *.NEW.*

So no, it seems you can't limit execute rights based on what folder objects are in. You can only limit execute rights based directly on the objects names (or name patterns).

Best,
Carsten

Thanks Carsten_Schmitz_7883 - I appreciate your thorough testing / reply to this question!

LauraAlbrecht608310 You're welcome.

Actually, there's one more correction: My test user is able to edit objects in BAR that were created by someone else, too (if he has edit permissions on the objects namespace itself), and that's even if you put a NOT for Writing on the folder.

Normally, "not" beats "grant" in Automic, but folder permissions are just not propagated to that extend. It's a rather lightweight permission model, sadly.

Just a hint - if you do not include the objects within the forbidden folder to a group - they can be accessed via the (quick) search window, if one knows the name...

Automic AE is not Windows..... :-)
so theres no heritage of access rights...

Yeah ... I wouldn't implicitly trust anything in those regards. Other times, it may also be Script sabotaging the permission model. E.g. I remember when I discovered that PREP_PROCESS_REPORT could access reports people were not otherwise allowed to see ... (that one's been fixed since).

Wolfgang Brueckler said:

Just a hint - if you do not include the objects within the forbidden folder to a group - they can be accessed via the (quick) search window, if one knows the name...

That's why I name my objects like passwords. Good luck editing  JOBS.%eB4$8a2!J(?Wq.NEW.1  ;)

Hmmmm sounds a bit complicated... :-)

Just for the sake of completeness, here is a Document enclosed that describes a basic Naming Concept

https://community.automic.com/discussion/9498/object-naming-standards-question