AmpersandTarski / Ampersand

Build database applications faster than anyone else, and keep your data pollution free as a bonus.
http://ampersandtarski.github.io/
GNU General Public License v3.0
40 stars 8 forks source link

Role graphs #1376

Open stefjoosten opened 1 year ago

stefjoosten commented 1 year ago

Problem

Currently, when I define an information system, I have to spend serious time making interfaces. I see code duplication for different roles in my interface specifications. As a consequence, I make too many errors and spend hours or even days to fix them. This makes my interfaces difficult to maintain, especially if I have many.

In the current syntax, I can enumerate roles after the keyword FOR. This allows me to define the interface for an arbitrary set of roles. In practice, however, there is a partial order of roles. For instance: image To reproduce such hierarchies with the current mechanisms is possible, but yields a terrible maintenance burden in practice.

Proposal

I want to specify this role hierarchy directly in Ampersand. So I propose a statement:

ROLE "Functional Maintainer", "Technical Maintainer" ISA Maintainer.

The meaning of this is that all restrictions that apply to a Maintainer also apply to Functional Maintainer and Technical Maintainer. If a user has role $A$, and $A$ ISA $B$, then $A$ has all interfaces and all CRUD restrictions of $B$.

Then we need three operators between roles, so I can say, for instance

INTERFACE PersonalInfo FOR User - "Technical Maintainer"

The operators are \/, /\, and -. Their meaning is: The role $A$ \/ $B$ gets access to the interfaces for both $A$ and $B$ and has the CRUD restrictions of $A$ and $B$. The role $A$ /\ $B$ gets access to the interfaces that $A$ and $B$ have in common and has the CRUD restrictions that $A$ and $B$ have in common. The role $A$ - $B$ gets access to the interfaces for $A$ except the ones for $B$ and has the CRUD restrictions of $A$ except the ones for $B$.

Michiel-s commented 1 year ago

Interesting feature.

I do want to mark that this will impact the prototype framework (backend implementation in particular). When we start on this issue a related issue is needed in that repo.