Generalize permissions

[fosterlynn]

Make the permissions / authorization piece configurable by installation.

Initial thoughts for discussion:

• We need something by context agent, probably based on a user agent having an association with the context agent (member, etc.)
• We need something by functionality. This could be a number of different granularities, but initially I'm thinking of going broad-brush, something like operational, context agent level configuration, installation level configuration.
• We need sensitivity to currency, which has higher level of risk. I think of waiting until the freecoin security piece is clear, then mapping that into the OCP/NRP code, perhaps using the behavior == "currency" property of EconomicResource.

[ivanminutillo]

does permissions work only between context and agent? or also between agent and agent?

[fosterlynn]

does permissions work only between context and agent? or also between agent and agent?

can exist a relationship between two agents without a context ?

In OCP, relationships can exist between any two agents of any type. In practice, at least one of them is a context agent. So in OCP, say in the case of "Lynn is member of Mikorizal Software", Mikorizal Software is the context agent.

(In ValueFlows, we added the context agent to accommodate peer relationships between agents who are not context agents, like "Mikey is mentor to Alice, in the context of Enspiral." This is not supported in OCP, although it could be added.)

[fosterlynn]

Here are some beginning thoughts about how permissions might fit into the app. This doesn't include the currency / wallet question, I'll fit that in when we know what it looks like.

Installation level: choice of "anyone can view", "only logged in users can view". (For example in Sensorica, anyone can view; in Freedom Coop, only logged in users can view.)

Context agent level: choice of "anyone can view", "anyone in the installation can view", "only people with member type relationships to the context agent can CRUD". This would not override the installation level flag, so "anyone can view" wouldn't be valid here if the installation was flagged as "only logged in users can view".

Association type level: choice of "operations only", "operations plus context agent configuration". (We also have a behavior choice already on association type, but I think we should leave that for actual behavior and not mix them.) This would work like if a user/agent has a certain association type in relation to the context agent, then that user/agent has that level of permissions for that context agent. Configuration would include functions like CRUD on exchange types, patterns, facet values, probably resource types (?). Operations only could view all of those things.

User/agent: Something like the current "admin flag", or maybe exactly the current "admin flag". This applies outside the context and association type levels, and gives some installation level permissions, but less than superuser. I'm not sure what all those are for FC (I think of the ability to answer membership requests, and to view all data), but that would be a good place to start. And I'm not sure how this relates to current "staff" permissions on the User.

This isn't everything we would need to think about related to security of course, just the base app functionality / logical model, and that needs more detail on exactly which functions apply to the different security levels. It also doesn't address how each function checks this. Where we have django views, each view could run a method that checks, perhaps. In the mobile friendly react version, I have no idea, maybe something in each API call? It seems like it would be nice to have the whole thing in one method if possible. If not, that's OK too.

[fosterlynn]

Some of this is done, per this issue: FreedomCoop/valuenetwork#389