Users

Elephant Users is based on the BrightSide Contacts module. A user is always a contact.

Contacts becoming users

Any contact can be transformed into a user, by giving a connector called Email. Users with this connector can authenticate into the User area and manage their own profile.

If enabled, the User area can also admit new sign-ups. The sign-up process validates the user email. Registered users get the Social Group Guest, with no permissions attached. Administrators receive an email and push notification with the new user name and email.

User's permissions are controlled by the Elephant Security System, explained in Security .

Complex names

ComplexName property gives the choice of treating users with a chain of formality. The API also offers a guessing option, using the European way of treatment, excluding titles and gender.

The non-said rule of We Are All Equal

Turró.Org applications enforce the rule of We Are All Equal, and avoids saving data as titles, gender, race and religion. Users are measured only by the type of involvement and the degree of engagement.

Complex name properties

Property

Description

Required

Can be guessed

Full

Is the full name. For entities, this should be the unique given value. Things like the Trade Name, are managed in the entity profile or by connectors like TradeName.

Friendly

Should be the friendly way to address the user. It's guessed to be the first name.

Formal

Should be the more formal way to address the user. It's guessed to be the first encountered surname.

Complex name return

ComplexName will always return a value, despite the property being empty.

Property

Returns

Name

The full name.

Friendly

The Friendly value. Fallback to the Formal value.

Formal

The Formal value. Fallback to the Name value.

Profile management

In Elephant nomenclature, a user is a contact with an email and able to sign in. Users can also sign up, if the website allows it (has a sign up context)

Automated relations

Elephant gives the user the opportunity to enrich his profile, while getting more permissions. Any user can send a request for a new relation, and acquire permissions once validated. There are some limitations, though, to make sure a single user has not contradictory roles (ex. student and docent)

Profile completion

When configured, the profile completion gives the user some tips about completing the profile. Tips may vary, depending on the relation type and what has already been completed.

Using user's profile, any user can add relations to existing companies or learning centers. Relations created by users are moderated, administrators must validate all proposed relations.

When a user has no relations, it is offered several options, depending on the existence of companies or learning centers. If none of them are in your contacts database, nothing will be offered.

The differences among these relations, are:

Type Description
Professional Has a current relation with a company.
Student Has a current non-responsible relation (staff) with a learning center.
Docent Has a current responsible relation (not staff) with a learning center.

After a relation request has been sent, the profile will update the status.

Notifications

Recipient Description
User Receives a notification when the relation is accepted.
Admins Depending on the relation status, the subject can be:
  • Modified : Relation when validated and modified.
  • Not validated : Relation when not validated and created/modified.
  • Not validated : Docent relation when not validated and created/modified.
Not validated : Docent relation
This notification requires a different procedure. The reason are the special permissions a docent acquires. Usually, the flow is:
  • Contact the user, to validate that is a docent.
  • If true, validate the request and edit the contact, to change the relation type (other than staff)