Bug: UserField "Editable after signup" automatically forces "Show on signup"

[copymonopoly]

When creating a user field (UserField) in the admin panel, there is a sequence-dependent behavior:

1. Initial state:

   • “Show on signup” is checked by default
   • “Editable after signup” is unchecked

2. Sequence A:

   • First uncheck “Show on signup”
   • Do not check “Editable after signup”
   • Saves successfully: the field is neither shown on the signup form nor editable after signup

3. Sequence B:

   • First check “Editable after signup”
   • Then try to uncheck “Show on signup”
   • Frontend automatically re-checks “Show on signup” when you uncheck it

[Moin]

I don’t think it’s a bug. It’s intended to work that way. But I agree it would be helpful if this was possible

@Moin

But I think there is still a problem: you are forced to allow either editing or showing at signup.

discourse/frontend/discourse/admin/components/admin-user-fields-form.gjs at d82dc69d1d4cbf7dd5ed449ae299908282637b3f · discourse/discourse · GitHub

 @action
  setEditable(value, { set }) {
    set("editable", value);

    if (value === false) {
      set("show_on_signup", true);
    }
  }

It is possible to create a field with all options disabled because you don’t need to change the editable setting for that. But once you change it once, there is no way back to this configuration.

Based on the pull request FEATURE: Allow hiding user fields on signup form by Drenmi · Pull Request #34672 · discourse/discourse · GitHub this was an intentional decision:

Fields that are optional but not editable need to be on the signup form, or they can never be filled in

I wonder if the use case to have the field filled by staff was not taken into account

[copymonopoly]

Just to clarify — the bug isn’t about these options being mutually exclusive.

The real issue is: originally, a field can have both “Editable after signup” and “Show on signup” unchecked. But once you check “Editable after signup” even once, the frontend enforces that at least one of these two options must be selected from then on.

This behavior is sequence-dependent.

[Moin]

Fields that are optional but not editable need to be on the signup form, or they can never be filled in

The goal of the current implementation was to prevent admins from creating a user field that is neither editable nor shown on sign up. So if something is a bug, then it’s that you can still create the field without these properties. I would prefer if instead of fixing that, the @team would consider the use case of staff-only user fields and fulfill that feature request. That’s why I posted in the feature topic.

[hugh (Hugh Lashbrooke)]

@ted Could you have a look at this one please? IIRC you worked on this set of options recently.