Allow non-admins to edit own registration information

Created on 18 December 2024, 4 days ago

Problem/Motivation

I think it should be possible for non-admins to edit their registrations even after the registration close date, and possibly even if registration is no longer enabled.

While it's true that non-admins should not be able to increase their spaces or do other things like that might be similar to newly registering, there are plenty of uses cases for benign updates, like changing their dietary needs or any other information on custom fields on the registration type.

It's hard to know when sites might want users to stop being able to edit this additional info: I think making this unrestricted is a better default.

Proposed resolution

This overlaps with πŸ“Œ Replace HostEntity::isEnabledForRegistration Active but may be worth discussing separately. I suggest
(1) isRegistrationValidForHost() only checks isAvailableForRegistration() if the registration is new or changes the number of spaces.
(2) Replace πŸ› Access & validation mismatch creating/editing a registration on a disabled host Active with a check on isRegistrationValidForHost() instead

Remaining tasks

User interface changes

API changes

Data model changes

✨ Feature request
Status

Active

Version

3.3

Component

Registration Core

Created by

πŸ‡¬πŸ‡§United Kingdom jonathanshaw Stroud, UK

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @jonathanshaw
  • πŸ‡¬πŸ‡§United Kingdom jonathanshaw Stroud, UK
  • πŸ‡ΊπŸ‡ΈUnited States john.oltman

    The use case makes sense and I am good with this as long as existing installs are not affected. Meaning it is done with a checkbox setting on the per-host-entity Registration Settings form (a new base field), the Registration type, or global Registration settings, and an update hook sets the box to unchecked for existing sites. If you want new sites to default to checked, no problem. If putting in global settings, https://www.drupal.org/project/registration/issues/3490561 πŸ› From address in registration setting is overwritten Active provides an example.

    This should definitely wait until the related issue #3464736 is Fixed, so as to avoid rework.

  • πŸ‡¬πŸ‡§United Kingdom jonathanshaw Stroud, UK

    Makes sense re existing installs.

    What's tricky with regard to πŸ“Œ Replace HostEntity::isEnabledForRegistration Active the behabior we give to the new isRegistrationValidForHost() we are introducing. I'm not fond of the idea we bake into it the legacy idea that any existing registration is invalid for the host if the host is not longer available in the sense defined by isAvailableForRegistration().

    But if we don't keep the legacy behavior in isRegistrationValidForHost(), then we have to deliberately implement the legacy behavior elsewhere in addition alongside calls to the new isRegistrationValidForHost().

    Here's a proposal that gives us maybe the best of both worlds:

    In πŸ“Œ Replace HostEntity::isEnabledForRegistration Active :
    (1) isRegistrationValidForHost() only checks isAvailableForRegistration() if the registration is new or changes the number of spaces. It doesn't have the legacy behavior.
    (2) The logic in RegistrationAccessHandler added in πŸ› Access & validation mismatch creating/editing a registration on a disabled host Active for 'update' is changed to consider isAvailableForRegistration(), keeping current behavior that blocks access for non-admins to edit registrations on closed hosts.
    (3) The RegistrationConstraintValidator is changed to consider only isRegistrationValidForHost(). This looks like a behavior change for ordinary users, but actually its not because they can't access the registration edit form to edit it anyway if the host is closed. This will have the consequence that admins are able to edit registration information (but not spaces etc.) on closed hosts. So this is a behavior change, but probably beneficial and only for admins.

    In this issue:
    (4) We add a setting that give site builders control over whether RegistrationAccessHandler should or should not block access to edit depending on isAvailableForRegistration(). I suggest a global setting to keep it simple, as I think sites needs here are so various that I don't have a lot of confidence its that widely useful for more than BC.

Production build 0.71.5 2024