Skip to content

Gender field for FE users

Oliver Klee edited this page Jun 3, 2024 · 4 revisions

Current situation

Currently, different extensions that define or use the gender field for FE users assign different meanings to different values of the field in the TCA:

Extension Type no gender set male female diverse code
sr_feuser_register self-registration 99 0 1 (not available) https://codeberg.org/sjbr/sr-feuser-register/src/branch/master/Resources/Private/Language/locallang_db.xlf#L66
femanager self-registration 99 0 1 2 https://github.com/in2code-de/femanager/blob/v7/Resources/Private/Language/locallang_db.xlf#L36
sf_register self-registration (not available) 1 2 (3) https://github.com/evoWeb/sf_register/blob/develop/Resources/Private/Language/locallang.xlf#L18
feuserextrafields field provider 99 0 1 2 https://github.com/oliverklee/ext-feuserextrafields/blob/main/Resources/Private/Language/locallang.xlf#L15
onetimeaccount self-registration 99 0 1 2 https://github.com/oliverklee/ext-onetimeaccount/blob/main/Resources/Private/Language/locallang.xlf#L36

Why these extensions affect each other

Self-registration extensions that define additional FE user fields are "providers" for these fields. They are usually used in combination with other "consuming" extensions (e.g., the seminars extension that has a CSV export for event registrations) that rely on the values of these fields having special meanings.

Problems with the current situation

  • If a site switches from one self-registration extension to another, the existing users might get an unwanted gender change (at least in the backend).
  • "Consuming" extensions that rely on the gender value schema can only work in conjunction with certain self-registration extensions, but not with others.
  • If the default value for the gender field in the BE is something other than "no gender set", FE users might have the incorrect gender set.
  • According to a German court decision, persons need to be able to provide "diverse" as their gender.

Proposed solution

Why have a gender field in the first place?

Nowadays, forms should try to avoid having a gender field and use a salutation field instead (or none at all).

However, there are cases (mostly for API usage) where providing a gender for users still is required. For those cases, we need a machine-readable, interoperable gender field.

Criteria for a proposed solution

  1. Provide a "no gender set" value and make it the default.
  2. Provide a "diverse" gender value.
  3. The new values must not overlap with the old values so that upgrade wizards can clearly recognized whether an FE user record has already been migrated, has not been migrated yet, or has been newly created.
  4. The new values must not be language-specific in order to allow conversion for APIs and in order to allow localized output.
  5. The values should be the same across as many extensions as possible.

Proposed values

Switch the gender field from an integer to a string (so that the intuitive default value for that type can mean "no gender provided") and use these values:

value meaning
empty string no gender provided
f female
m male
d diverse

How to ensure consistency between the extensions

I see these possible approaches:

  • add the field to the Core (for V13 and up) - this would technically enforce this
  • use the feuserextrafields extension as the "one source of truth" for the gender field and add it as a dependency to the other extensions
  • have an agreement (between the extension authors), but do not enforce the values technically

Upgrade wizards

  1. check if there are any users with an numeric gender value 0, 1, 2 or 99.
  2. if so, convert only those according to the table

These wizards should be repeatable.

If the field gets added to the core, the upgrade wizard should only be active in V13 installations, not in V11 or V12.