Beamline policy rules #182
Conversation
|
RE failing lints. The suggested changes change the behaviour so I 'm not sure if I'm trying to work against the way OPA expects rules to be written by making them undefined when the input is not present. |
tpoliaw
force-pushed
the
beamline_rules
branch
from
f6e433c
to
afc4380
Compare
tpoliaw
force-pushed
the
beamline_rules
branch
2 times, most recently
from
48908c7
to
a241bbb
Compare
| is_beamline_admin[subject] contains beamline if { | ||
| some subject | ||
| some role in data.diamond.data.subjects[subject].permissions | ||
| some beamline in data.diamond.data.admin[role] | ||
| } |
There was a problem hiding this comment.
Not sure this name really makes sense given it maps to a list of beamline names. We could rename it or use a double mapping like:
| is_beamline_admin[subject] contains beamline if { | |
| some subject | |
| some role in data.diamond.data.subjects[subject].permissions | |
| some beamline in data.diamond.data.admin[role] | |
| } | |
| is_beamline_admin[subject][beamline] := true if { | |
| some permission in data.diamond.data.subjects[subject].permissions | |
| some beamline in data.diamond.data.admin[permissions] | |
| } |
Though this evaluates to undefined if they're not an admin, so not exactly what we want 🤔
There was a problem hiding this comment.
Okay, after a bit of messing around:
| is_beamline_admin[subject] contains beamline if { | |
| some subject | |
| some role in data.diamond.data.subjects[subject].permissions | |
| some beamline in data.diamond.data.admin[role] | |
| } | |
| is_beamline_admin[subject][beamline] := true if { | |
| some permission in data.diamond.data.subjects[subject].permissions | |
| some beamline in data.diamond.data.admin[permissions] | |
| } | |
| is_beamline_admin[subject][beamline] := false if { | |
| data.diamond.data.subjects[subject] | |
| data.diamond.data.beamlines[beamline] | |
| some permission in data.diamond.data.subjects[subject].permissions | |
| some _beamline in data.diamond.data.admin[permissions] | |
| beamline != _beamline | |
| } |
Feels like a more concise solution should exist tho
There was a problem hiding this comment.
That (the first one) only includes beamlines where the user is an admin so the value is always true at which point we might as well use a set again. Rename it to something like beamlines_for_user? I can't think of a better name so open to suggestions
There was a problem hiding this comment.
Yeah, feel like it would be better to go with something like the latter. beamlines_for_subject or subject_beamlines would make sense if we were to keep it as a list.
On another note, we should probably avoid calling them beamlines and prefer instruments instead as it includes microscopes etc
There was a problem hiding this comment.
I've renamed it. I'll start using instrument when the data bundle stops listing beamline for each session and the beamlines subtree is renamed.
There was a problem hiding this comment.
Maybe it should be beamline_admin_for_subject instead. It's a bit unclear otherwise whether it's a list of beamlines a subjects is on sessions for.
tpoliaw
force-pushed
the
beamline_rules
branch
2 times, most recently
from
f486150
to
3420bc4
Compare
* session.access: user can access session * session.named_user: user is a named member of the visit * session.matches_beamline: visit is on the given beamline * session.session_beamline: beamline for the given visit * proposal.access: user can access proposal * proposal.named_user: user is a named user on the proposal * admin.admin: user is super admin * admin.beamline_admin: user is admin for the given beamline Rules are only defined if the required fields are included in the input. `admin.beamline_admin` refers to the beamline passed as `input.beamline` not as the beamline for the session defined by `proposal`+`visit`. Previous function `session.beamline` has been renamed to `beamline_for` to distinguish it from the `session.beamline` rule.
tpoliaw
force-pushed
the
beamline_rules
branch
from
3420bc4
to
ae8b7d6
Compare
Setting as a draft for now as I'm sure there must be a better way of doing it. The aim was to make the rules only defined if the required fields are present in the input but still be present (but false) if the conditions weren't met. eg
input = {}=>result = {}input = {"user": "name"}=>result = {"admin": true}orresult = {"admin": false}.Setting the default to
falsewould probably be ok but means you could get misleading results, eg if you passuser,proposalandvisit, gettingbeamline_admin = falseback suggests the user is not the admin for the beamline for the visit which may or may not be correct.