How to manage records updates?

[leplatrem]

How to manage records updates?

[almet]

Thanks for bringing this on the table.
We probably need to define what are the use cases we are trying to solve.

So it seems that we have two different problems: edition of the model definitions and edition of some records already inserted in the db.

Edition of the model definition

If what we want is having multiple versions of the same model available a the same time, then we need to have version numbers for them. I propose that we use POST methods for that, when defining a new model.

This seem to be solved by what we have:

1. An user creates a model with PUT /definition/{modelname}
2. he wants to update this model with a new version, so he do so with a POST /definition/{modelname}. We said that only the authenticated users can do that, so they will need to provide the token we gave them in the first place.

We can store internally a version number for those definitions.

Edition of items

This is where it gets tricky. I propose that the creator of the model definition chose the ACL model that fits him better.
We can have the following "ACL models":

• The creator gets full control on everything. He is the only one to be able to read and write data. (as a super user, I propose that he always get this possibility)
• Other people, can view, edit, create or delete items using some specific tokens that the creator generated at model definition time.
• The creator put a model in "free" mode and everyone can access it and do what they want from it.

I like the granularity this approach allows, but it also adds a bunch of extra fields that the client will need to remember. Also, it means that the creator of the model definition have full control on the data, which may or may not be what we want, I'm not sure.

[leplatrem]

Roughly I would say that we don't really need multiple versions of the same model.

Regarding ACL, I like it so. No problem for me to give top level to the model creator.

Except that we miss one use-case here : a user will want to edit its own records (e.g. typo in text, geometry, etc.).

So let's say there would be those levels :

• closed (no get, no post, except if model creation token is provided)
• restricted (can get and post, but overwrite only if password is provided)
• readonly (can only get and post, =restricted with default password)
• limited (can get, post and overwrite only if author of posted data)
• free (anybody can get, post, overwrite)

I also wonder how to keep these distinctions straightforward for users. Using model creation tokens and extra ?password= can fit some of the cases... How could we keep track of authors of posted data ?

[almet]

ISTM that the token can contain the information about the privilege the users can have. Then it's a matter of UI to make things clear.

We can generate all these tokens at model definition creation time, and then the creator gives the token to who he wants, or turn on/off the "free" mode and the "limited" mode.

About users, we can associate a token to each item at creation time and return it to the users, so if they want to edit it they'll need to remember it. Again, it means more stuff going to the client, but since HTTP is stateless…

[Natim]

Ok so we worked on this and here is where we are :

ACL management.

Warning: this is not authentication

Some concepts to take into account:

• users: A user profile
• groups: A list of users
• policies: A policy describes the privileges each role has.
  • For each level privileges are Add, Read, Edit & Delete
  • Rights are defined for the definition, the users, the policy and the data
    • For the definition, the users and the policy we have rights defined for [admin, users, others]
    • For the data, we have rights for [admins, users, authors, others]
  • Policies are public and not editable. It's possible to update one only if it's not tied to any model
  • Daybed creates some policies by default and they are documented.

Daybed data storage

USERS, GROUPS and POLICIES are stored using daybed models with a restricted policy.

• This will help us to let users append policies and manage groups
• Daybed models:
  • daybed_user: It is 'admin-only' for definition, policy, users and data
  • daybed_group: it is 'admin-only' for definition, policy and users but for data authors have CRUD on their groups
  • daybed_policy: it is 'admin-only' for definition, policy, users but other can create and read policies (NOBODY can change/delete a policy)

Policies examples

• admin-only: Only the admins can do it
  • definition, users, data, policy
    • admins : CRUD
• read-only: Only the admins can create the content and other can read it
  • definition, data
    • admins : CRUD
    • others : R
  • users, policy
    • admins : CRUD
• authors-only: Everybody can create data and manage its own data
  • users, policy
    • admins : CRUD
  • definition
    • admins : CRUD
    • others : R
  • data
    • admins : CD
    • others : C
    • authors : CRUD
• normal-policy: Everybody can create data and manage its own data but also read data of others
  • users, policy
    • admins : CRUD
  • definition
    • admins : CRUD
    • others : R
  • data
    • admins : CD
    • others : C
    • authors : CRUD
• wiki-policy: Everybody can do everything on the data
  • users, policy
    • admins : CRUD
  • definition
    • admins : CRUD
    • others : R
  • data
    • others : CRUD

[leplatrem]

Great, that you took time to work on this !

Here are my questions :) I tried my best to get the idea, but some things remain unclear to me :(

Is there a difference between right and priviliege ?
Definition and models are different concepts ? (saw last commits btw)

Why there is no authors for definitions ?

I feel lke there is something that you don't explicit here : the creation of policies. As far as I understand, it will be the association of groups and privileges, isn't it ?

Since users, policy is always CRUD for admins, why do you repeat it ? Am I missing something ?

What difference between normal-policy and authors-policy ? Is there a typo ?

I think we need at least one basic policy where records are secret, no ?

In order to allow the creation of policies and associate them to models, will you need to implememt relationships between models ?

[Natim]

With ACL :)