Implement T&Cs acceptance server-side

[mmmarcos]

• Information about acceptance of the CGU must be stored in the database (enrollment route will need to be updated + storage : acceptance date + DB schema migration). => 4h.j
• Export (users+acceptance date) via backend API+CLI(csv) => 2h.j

referenced into #6439

[FirelightFlagboy]

I've the following questions:

• Where do we scope that an user have accepted the CGU ?

  At the organization level or the server level ?

• What is used to identify an user ?

  • Do we use its USER_ID

    That mean that an user can only accepte the CGU after it's user certificate is upload to the server.
    That raise the questions what happen if the to the certificate if the user refuse the CGU.

  • Do we use its email

    Using it's email mean that we could force the acceptance before the creation of the DEVICE.
    That could also be used to not ask an user to accept the CGU again if it create a new user for a new orgaization with the same device.

• The export is server wide or per organization ?

[mmmarcos]

• Where do we scope that an user have accepted the CGU ?

T&C are related to the service being provided. As such, they are configured at server-scope (not per organization). So IMO the acceptance should also be registered at server scope.

• What is used to identify an user ?

  • Do we use its USER_ID
    That mean that an user can only accepte the CGU after it's user certificate is upload to the server.
    That raise the questions what happen if the to the certificate if the user refuse the CGU.

In theory, you shouldn't be able to refuse the T&C and still get a user certificate : the GUI would not allow the user to continue if T&C are not accepted. BTW, that's why the issue mentions to only store acceptance date (instead of storing a boolean accepted that will always be TRUE).

• Do we use its email
  Using it's email mean that we could force the acceptance before the creation of the DEVICE.
  That could also be used to not ask an user to accept the CGU again if it create a new user for a new orgaization with the same device.

I don't think is that bad for a user that have accepted the T&C when joining org1, to re-accept the conditions when joining org2. Also, I don't think we need to force acceptance before device creation (what would be the goal?)

So I would say USER_ID, but better double-check with someone else.

• The export is server wide or per organization ?

Server wide.

[Landeers]

The export is server wide or per organization ?

Server wide.

the export must contain :

• the user id
• email (there will be duplicates if a user is in several organizations, but this is not bad)
• user label
• organization ID
• acceptance date

[FirelightFlagboy]

In theory, you shouldn't be able to refuse the T&C and still get a user certificate : the GUI would not allow the user to continue if T&C are not accepted
So I would say USER_ID

The problem is that the USER_ID is created during the invitation process when we generate the user certificates by the greeter which is then upload to the server with the command user_create.

If we go the USER_ID way that mean change to the invitation process (likely by adding another step that wait the claimer for a message indicating CGU acceptance), is that OK ?

[mmmarcos]

The problem is that the USER_ID is created during the invitation process when we generate the user certificates by the greeter which is then upload to the server with the command user_create.

If we go the USER_ID way that mean change to the invitation process (likely by adding another step that wait the claimer for a message indicating CGU acceptance), is that OK ?

I don't think is worth it to change the invitation process. In that case I would go email.
@Landeers @touilleMan what do you think ?

[FirelightFlagboy]

@touilleMan suggest something clean:

• Have a dedicated API for CGU acceptance.
• The server check if the authenticated user has accepted the CGU else return a HTTP code.
• Have an endpoint that display the configured CGU file.
• The user accept the CGU by generating an certificate (or simple signature ?)