Agreements

The Agreements API help web administrators to deal with legal issues regarding data protection, terms and conditions.

Why an agreement API?

You may need to warn the user about things like:

  • What you do with the collected data.
  • The terms and conditions of the offered services.
  • Fine-grain previous points by certain actions.

The Agreements API provides a lightweight method to store when a user accepts what the agreement proposes. In order to achieve this, there are some restrictions you should be aware of:

  • Each agreement has a single use. Once a user accepts, the agreement can't be deleted.
  • Modifying the text, when users already accepted the agreement, it's a bad practice. Currently, you are able to change the text, but in the future this will change, forcing a read-only mode, or deleting all acceptances.
  • If you intend to create specific agreements for temporal events, take in mind the single use restriction. Make the text as generic as possible. The benefits are, fewer interactions user/agreement, and a full memory of the acceptance.

How does it work?

First of all, you create an agreement. The main fields are:

Field

Usage

Title

Title of the agreement. Is what it shows in listings and the subject in notifications.

Text

Body of the agreement. Accepts del {site} macro, replaced by web site name.

Required to notify

Describes this agreement as required when sending email notifications to users.

Required to access

Describes this agreement as required to operate for authenticated users.

Peremptory

Will force sending a Pending signature notification each time encounters a failed intent, up to ten notifications.

Action

Defines de agreement as related to a user action. Those actions are reported by the modules (see module-actions). When unknown, let it blank.

Social groups

Defines de agreement for specific social groups. The input requires comma separated social group id's (as in Grups socials ). When unknown, let it blank.

What final users will see?

When the required signature forbids sending notifications, a Pending signature notification will be sent. The user will be able to Accept or Decline the agreement from the notification email.

When the required signature forbids operating, the user will be redirected to the agreement, expecting to Accept or Decline the agreement.

The agreement flow


Notifications

Modules chose whether to treat users as Observers or Participants.

Agreement

Not set

Accepted

Declined

Wants
Participant

Send

Send

Don't send

May want
Observer

Don't send

Send

Don't send

Module

Recipients

Sendables

Since sendables are configured by administrators, recipients are manually selected. Those who explicitly declined to receive notifications, despite being selected, will not receive any email.

Publications

Only those who explicitly accepted to receive notifications and are category subscribers, will receive the email.

Dossiers

Only those who explicitly declined to receive notifications, will not receive the email.

Newsletter

Each Newsletter decide how to treat the subscribers.

The generic rule to follow explains itself better in terms of participation. When a user participates in a module, the participation will prevail to the not signed status.

Publication category subscriptors are not considered participants, but observers. In this case, not signed prevails.

Module actions

API provided by modules

Key for the action

Marketplace new entry

marketplace-new

New project idea

project-new

New challenge

challenge-new

New response to challenge

challenge-response-new

Printer version
English05/23/18 14:24Lluís Turró Cutiller
English06/15/18 09:00Lluís Turró Cutiller
English07/24/18 10:26Lluís Turró Cutiller
English01/05/19 10:46Lluís Turró Cutiller
English07/30/20 17:42Lluís Turró Cutiller
English03/18/24 22:34Lluís Turró Cutiller