Permissions: setup up perms for logical and physical flow operations

[davidwatkins73]

Description

Similar to #6061

Resourcing

We intend to contribute this feature

[jessica-woodland-scott-db]

Logical Flows

• [ ] Determine whether edit button should be displayed
  • [ ] Identify the list of users which have the ability to edit flows across all applications and actors
  • [ ] Check to see if current user is included in that list
• [ ] Server-side check to determine if user has permission to edit logical flows on either source or target
• [ ] Override for context-based check based on LOGICAL_DATA_FLOW_EDITOR role
• [ ] Bulk upload should be controlled by override role

Datatypes

• [ ] Editing datatypes on logical flow should be restricted to if user has edit permission on either source or target
• [ ] Editing physical datatypes also restricted to above

Physical Flows

• [ ] Server side check to see if user has permissions to edit physical flows on either source or target
• [ ] Edit button hidden for those without permission on source or target
• [ ] PHYSICAL_FLOW_EDITOR override for allowing non-context based check
• [ ] Bulk upload should be controlled by override role

Other

• [ ] Add unique index on permission_group_entry so an application can only belong to one permission group
• [ ] Default for is_default on permission_group should be false not true
• [ ] Default provenance on involvement_group should be 'waltz'
• [ ] permission_group_entry table should use entity refs rather than application_ids

[jessica-woodland-scott-db]

with default_permissions as (
    select distinct pgi.parent_kind, pgi.subject_kind, pgi.qualifier_kind, pgi.qualifier_id, i.entity_id, p.email
    from permission_group_involvement pgi
             inner join involvement_group_entry ige on pgi.involvement_group_id = ige.involvement_group_id
             inner join permission_group pg on pgi.permission_group_id = pg.id
             inner join involvement i on ige.involvement_kind_id = i.kind_id and pgi.parent_kind = i.entity_kind
             inner join person p on i.employee_id = p.employee_id and p.is_removed = 0
    where pg.is_default = 1
      and pgi.operation in ('ADD', 'UPDATE', 'REMOVE')
      and pgi.parent_kind in ('APPLICATION', 'ACTOR')
      and pgi.subject_kind = 'LOGICAL_DATA_FLOW'
      and (i.entity_id  not in (
        select distinct pge.application_id
        from permission_group_entry pge
                 inner join permission_group pg on pge.permission_group_id = pg.id
        where pg.is_default = 0
    ) and i.entity_kind = 'APPLICATION')),
    overridden_permissions as (
        select distinct pgi.parent_kind, pgi.subject_kind, pgi.qualifier_kind, pgi.qualifier_id, i.entity_id, p.email
        from permission_group_entry pge
                 inner join permission_group pg on pge.permission_group_id = pg.id and pg.is_default = 0
                 inner join permission_group_involvement pgi on pg.id = pgi.permission_group_id
                 inner join involvement_group_entry ige on pgi.involvement_group_id = ige.involvement_group_id
                 inner join involvement i on i.entity_id = pge.application_id and ige.involvement_kind_id = i.kind_id and pgi.parent_kind = i.entity_kind
                 inner join person p on i.employee_id = p.employee_id and p.is_removed = 0
        where pgi.operation in ('ADD', 'UPDATE', 'REMOVE')
          and pgi.parent_kind in ('APPLICATION', 'ACTOR')
          and pgi.subject_kind = 'LOGICAL_DATA_FLOW'
    ),
    all_permissions as (select * from default_permissions union ( select * from overridden_permissions))
select * from all_permissions
-- select distinct email from all_permissions
where email = '[email protected]'

[davidwatkins73]

Three basic queries needed:

qry	desc	input	output
Show edit button	does the user have permission on any app (or actor) to do flows	{user, operations, subjectKind}	true or false
Entity permission checker	given a set of refs (typically one or two, but perhaps more when dealing with bulk flows) gives back a list of permissions for each ref	{ref, user}	[{ref, permission (incl subject etc)}...] we may want filters on the query to restrict results, but probably of marginal value
Find available entities for a given permission	primary usage for flows, i.e. give me a list of all apps I could link a flow to, only needed if the starting endpoint is not permissioned to the user (in this case all entities of the right type are available)	{user, parent_kind, subject_kind, qualifier, operation`}	[{ref}...]

So, for flow edit, we will

• determine if button is available using first call
• when in edit mode do the second call with the starting point, if we have perms then any counterpart can be selected, otehrwise....
• if we don't have the right permissions for the starting point, do the second call as we need to restrict the counterpart endpoint to something we do have permission on