Reverted all changes except adding the username line as requested. The function signature is back to the original (no display_name parameter), greeting uses username like before, but the "Your username is: {username}" line is preserved for recovery purposes.
Co-authored-by: nitnelave <796633+nitnelave@users.noreply.github.com>
As requested by @nitnelave, the password reset email now includes both the display name for personalization and the username for recovery. The email uses the display name in the greeting when available, but always shows the username explicitly for recovery purposes.
Co-authored-by: nitnelave <796633+nitnelave@users.noreply.github.com>
The fields first_name, last_name, and avatar have all been moved
to regular attributes in the database, and are available through
the GraphQL API as such as well. This commit removes the legacy
fields for each on the internal CreateUserRequest type, leaving
these to only be updateable through attributes.
The fields are still available in the GraphQL CreateUserInput
type, preserving backwards compatiblity, and if set, they will
be used for the corresponding attribute values. If both fields
and attributes are set, the values given through attributes will
superceed the fields, and be used. This change also fixes a bug,
where creation of a user would fail if either of these attributes
were set as both attribute and field, as it would attempt to
insert the attribute twice, violating a unique constraint in the
database.
This commit adds support for basic validation of attribute
names at creation, and also in the schema overview. Both
user and group attributes are validated with the same rules.
For now, attribute names will be considered valid, if they
only contain alphanumeric characters and dashes.
Validation has been added the following places:
- In graphql API, for creation of both user and group attributes.
Request will be rejected, if attribute name is invalid.
- In frontend, before submitting a request to create a new user
or group attribute. Rejection here will show an error message
including a list of the invalid characters used.
As this change adds stricter validation to attributes, and, since
the rationale for this is partly compatibility with other LDAP
systems, this change also adds a warning in the schema overviews
to any attribute using invalid characters.
