If the sponsor writes a valid but non-existent email in a guest invite
we retried sending this email indefinitely. Instead of leaving django q
in an endless loop, we now send an email to the sponsor warning about
the problem instead.

Since we may not want to enable the identity check, it must be
togglable. This commit adds environment variable
REACT_APP_ENABLE_IGA_CHECK for toggling the check in the frontend, and
django settings variable IGA_CHECK for toggling the check in the
backend.

Move serializers only used by gregui.

Queries iga for an external id matching ours. If a match is found, the
name of the owner is returend. Otherwise we return null. Uses the new
iga module to fetch the data.

Verify that the backend accepts unicode for text fields and that it
survives to the database and back again

Andreas Ellewsen authored 3 years ago and Jonas Braathen committed 3 years ago

If a sponsor verifies a nin that is already in use by an account in
cerebrum, the guest will gain access to that account, which in turn
allows the guest to change the password of that account. This makes it
possible to abuse the guest service to steal the account of users.

A feature that checks for this problem, and helps the sponsor make a
decision on it, will be introduced in the near future. At that point
nin verification can be enabled again.

Resolves: GREG-202

This ensures that identity values created from values written in the
frontend by guests are given a source value signifying so.

Resolves: GREG-186

If the user logs in through the frontpage we now check if they have
completed the registration process. If they have completed it halfway
before, we find their info through the GregUserProfile of the user and
redirect to the register page. If we dont find any profile connected to
the user they are treated as anonymous users as before.

Resolves: GREG-164

Resolves: GREG-173

Issue: greg-112

It has been decided that a sponsor at a unit should have access to all
roles at that unit. This includes all units accessible through
hierarchical access.

Resolves: GREG-150

Dates can now be changed after they have started and ended. This means
that there is no situation which needs disabling the input fields, and
disabling has been removed.

Start and end date can now be in the past. The following rules apply:
 - Start dates can be any date in the past, and no more into the future
   than the max days property of the role type.
 - End dates follow the same rules
 - End dates must be equal to or later than start date.

Notification publishing has been reviewed to ensure duplicate
notifications are not created when start or end date is today.

Resolve: GREG-148

- Combine the /invite and /invitelink endpoints into one
- Return error messages from the backend
- Handle errors in the frontend
- Lower number of queries ran when calling the userinfo endpoint