.acl() usage

[wizardofzos]

When using the .acl(...) suffix method sometimes the 'column names' get stripped of their prefix. It's workable, but would be more consitent is (for instance) this

>>> r.datasetAccess.gfilter('SYS1.S*.**').acl()
                  NAME VOL  USER_ID  AUTH_ID  ACCESS
0   SYS1.SECRET.*.**        USER1  USER1     ALTER

Would be

>>> r.datasetAccess.gfilter('SYS1.S*.**').acl()
            USBD_NAME VOL  USER_ID  AUTH_ID  ACCESS
0   SYS1.SECRET.*.**        USER1  USER1   ALTER

[rob-vh]

After reading this twice, I understand this is not a bug report but a suggestion for improvement. An idea in IBM speak. I designed .acl() to work on all 6 data frames: DSDB, DSACC and DSCACC, and GRDB, GRACC and GRCACC. I would not like it to show 6 different column headers (and field names). But more importantly, .acl() is designed to work off the DSBD/GRBD, in which case it is supposed to pick up the relevant records from the corresponding ACC and CACC frames, integrating normal and conditional access. And it did this a month ago, but I see I messed up and now it forgets about the CATYPE and CANAME columns when you start with the base definitions.

[rob-vh]

Yup, found the bug. PR coming up. Anyway, if we would keep the fields prefix in the output of .acl(), you would see

>>> r.datasets.acl()
            DSBD_NAME               VOL  USER_ID  AUTH_ID  ACCESS

>>> r.datasetAccess.acl()
            DSACC_NAME              VOL  USER_ID  AUTH_ID  ACCESS

>>> r.datasetConditionalAccess.acl()
            DSCACC_NAME             VOL  USER_ID  AUTH_ID  ACCESS

>>> r.generals.acl()
            GRBD_NAME               VOL  USER_ID  AUTH_ID  ACCESS

Or you would have a discussion about "reporting from DSACC, but faking the prefix to be DSBD". Do you have a architectural need for the prefix in column names?

[rob-vh]

https://github.com/wizardofzos/pyracf/pull/35

[wizardofzos]

Yeah :)

I think it's only natural for users when they 'do something with users' (our pyracfs .users IBMs USBD) they should get the field names as in our 'offsets.json' (read: the recordtype names from the ibm docs)

Architectural need is that one above..... if I ask users... I expect to get USBD column names.. if I as for general records I expect to get GRBD ones.

Of course there are some features now in pyracf that do some 'correlation of data'. For those the column names are various, as they come from different DataFrames (DSACC and DSCACC for example) Maybe (hunch) they should all get 'custom pyracf column names' that then are visible in the docs :)

Back to the sun... the sea ..... and the wind

[rob-vh]

I could add a parameter: .acl(short_column_names=True) that you can switch off to get documented column names.

>>> r.datasets.acl()
            DSBD_NAME               DSBD_VOL  USER_ID  AUTH_ID  ACCESS

>>> r.datasetAccess.acl()
            DSACC_NAME              DSACC_VOL  USER_ID  DSACC_AUTH_ID  DSACC_ACCESS

>>> r.datasetConditionalAccess.acl()
            DSCACC_NAME             DSCACC_VOL  USER_ID  DSCACC_AUTH_ID  DSCACC_ACCESS DSCACC_CATYPE DSCACC_CANAME DSCACC_NET_ID DSCACC_CACRITERIA

>>> r.generals.acl()
            GRBD_CLASS_NAME  GRBD_NAME               USER_ID  AUTH_ID  ACCESS

>>> r.generalAccess.acl()
            GRACC_CLASS_NAME  GRACC_NAME               USER_ID  GRACC_AUTH_ID  GRACC_ACCESS

>>> r.generalConditionalAccess.acl()
            GRCACC_CLASS_NAME  GRCACC_NAME               USER_ID  GRCACC_AUTH_ID  GRCACC_ACCESS GRCACC_CATYPE GRCACC_CANAME GRCACC_NET_ID GRCACC_CACRITERIA

Since there is no field DSBD_AUTH_ID in the offsets.json, I should not create on (for r.datasets). Also, no field DSACC_USER_ID etc, so cannot fake those either.

Would you like me to add this code for digital users (again, for warm-bodied users, the default will be short names)?

[wizardofzos]

Maybe I'm too sun infused, but I think that it's good to not have the 'IBM' names when we combine unloads. It might also seem 'choping off' the prefix as done now is the way to go (queries about this behavior can then be redirected to the docs :) )

Maybe even the .acl() should only be applicabale to datasetAccess, generalAccess (+conditionals) ?

to query what users/groups can access a resources... the datsetAccess/generalAccess (+condintionals) are perfect, Downside is the user needs to query them both.... I'd see a good future for a completely premerged dataframe that thas all the access for all the authids on all the resources.....(classname dataset for de DSACC?)

That could then be one of the real 'added values' in pyracf, in an own (not infused with USBD_* etc column names but more 'logical' ones for 'auditors' that do python?)

Thoughts?

[rob-vh]

Maybe even the .acl() should only be applicabale to datasetAccess, generalAccess (+conditionals) ?

no

Downside is the user needs to query them both

r.datasets.acl() is what I consider the default view that users should take. It shows the combination of normal + conditional ACL, so you can see when a conditional is overridden by a normal permit, like below, when the conditional is nixed by the UACC(CONTROL).

>>> t.generals.gfilter('OPERCMDS').acl()
   CLASS_NAME                       NAME   USER_ID   AUTH_ID   ACCESS   CATYPE  CANAME NET_ID CACRITERIA  
0    OPERCMDS                    JES%.**         *         *   UPDATE  CONSOLE    SDSF                   
1    OPERCMDS                    JES%.**   -group-      SYS1  CONTROL   
2    OPERCMDS                    JES%.**    -uacc-    -uacc-  CONTROL   
3    OPERCMDS                    JES%.**   IBMUSER   IBMUSER    ALTER   

btw, I see I have to make those columns left aligned, default right align is confusing for me ;-)