Open harmeet-status opened 9 months ago
would you imagine the form causing the DMN file to be updated? if not, how would the system "remember" that the new group permission (for example) was supposed to exist, so it wouldn't be deleted the next time the "set permissions" process model was run?
Yes the form which would be part of a new update permission process models, would be able to update the DMN table, so that we can manage the DMN table from the form itself.
Recommend implementing this with Data Stores which are implemented already, but require UI. All told this is 7 days - stretched across the following tickets, that would provide enough functionality that the Data Store could replace the DMN table as the means of managing permissions.
@danfunk we discussed that we would have 2 types of datastore
We would use no. 2 for permissions. @danfunk is this correct?
it is not explicitly stated on this ticket about the desire to be able to edit permissions directly in prod outside of source control. but that desire exists, right? we want to make sure we are designing a solution that satisfies the constraints, because we can definitely add forms without making things directly editable in prod (which would be a smaller change), but we don't want to do that if it doesn't solve the problem that this ticket was filed to address.
there are currently two different data sets (DMN files), 1) group permissions (what do groups have access to do) and 2) user to group mappings (which users are in which groups). if it is true that you desire the ability to edit permissions directly in prod outside of source control, is it required to edit both of these data sets, or just one?
We definitely want to edit permissions in Prod directly, without source control.
Thanks. That does make me want to ask, “why?” I assume the answer is because it takes too long, involves too many steps, requires approvals, etc. we might separately try to address these issues, since they affect everything that Sasha and Marius do, not just permissions.
However, the simplest solution that satisfies that requirement is to remove the version controlled permissions files (currently two dmn files per environment), and just have users manage permissions through forms that edit the database directly. The biggest issues with this are lack of traceability (who broke prod and when?) and the inability to create environments from scratch in an automated fashion. These issues might push us towards some sort of a hybrid solution that is part version control and part live edited database data. Whoever comes up with a proposal that addresses all of the requirements and constraints gets a cake.
We want to bring the permissions administration of Spiff in-line with other systems. We don't need the overhead and delay of version control for this feature.
Editing forms would work, provided that we have a way to specifying at the command line, the ability to run a seed process model to setup the base permissions when deploying onto a new environment. Some parameters we can pass through.
Otherwise all run instances of the process model will be run by a logged in user, so we can have full traceability. Doesn't this solve all the problems? How could prod break, while applying permissions?
Basically as a first pass, we alter the BPMN permissions process to allow you to add additional users to a group.
The process model could include a form:
type ahead for a user (possibly set this up as a repeating section in the form)
dropdown for group assignment
this saves this to the data store which can be viewed and modified from the datastore view as well. So you can edit the data store, and then re-run the permissions process.
Allow group permission to be edited in a form rather than a DNM table.