Can admins create user fields that are only visible/editable in the admin panel?

[copymonopoly]

I noticed that custom user fields are always visible to users during signup or in their profiles, depending on the settings.

Is there currently a way to create a user field that’s only visible and editable by staff (for internal use), not exposed to users?

If not, would this be something the team might consider supporting in the future?

[Moin]

There is a feature request for that: Option to include user field that is only editable by staff
You may want to share your use case there to support the request.

Depending on what you want to use the field for, it may be sufficient to hide the user field for everyone except staff with a theme component.

[Anton_Akhmerov]

I run discourse for university courses, and the custom user field would be the student number. A theme component seems like an OK stopgap solution, but making a custom field completely invisible to anything but staff or system API would be cleaner.

[Moin]

Actually, I wonder if the option to hide the user field on sign up, which was added recently, makes user fields that users cannot see possible.

I think user fields are only shown to users when they are editable. So if you hide it on sign up and disable editing (and showing and searching) the field should be hidden for the user.

Configuration of the user field with all options disabled

The sign up form without the user field:

The user field is not visible for the user in their preferences:

The user field is visible for admins on the user’s profile:

[copymonopoly]

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

When creating a user field (UserField) in the admin panel, there is a sequence-dependent behavior: Initial state: “Show on signup” is checked by default “Editable after signup” is unchecked 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 Sequence B: First check “Editable after signup” Then try to uncheck “Show on signup” Fronte…

Really appreciate your help earlier! I’ve drafted a bug report showing this behavior clearly.

[copymonopoly]

Hey, I noticed a setting in the admin called “Staff user custom fields”. I’m not entirely sure what it’s for or how to use it.

Could you help me understand how this works? Thanks!

[Moin]

So far I had no use case for using custom fields through the API. So I cannot tell you more than what I learned from

Adding non-visible user custom fields to the API

This guide explains how to expose user custom field data through the API without displaying it on a user card. Required user level: Administrator This guide will walk you through the process of making User Custom Field data accessible via the API without displaying it on a user card. This can be useful when you need to programmatically access custom user data while keeping it hidden from general view. Creating a User Custom Field First, create your User Cu…

[ToddZ]

Have a look at Discourse User Notes, a plugin now included in core. It’s meant for staff to internally share notes about users. (Loves cats – Golfs with the CEO – etc.)

[tobiaseigen]

@copymonopoly did the suggestions from Moin and Toddz help you resolve your issue? FWIW, we here on meta make very active use of user notes to share information amongst staff about our members. It works well (arguably better than custom user fields) because notes are right at your fingertips:

@Discourse

If a user has a user note, whenever they post you’ll see a little notes icon. Clicking it will bring up the notes:

You can also access user notes via data explorer and likely also add/access them via the API.

[ToddZ]

@copymonopoly

I noticed a setting in the admin called “Staff user custom fields”. I’m not entirely sure what it’s for or how to use it.

I wasn’t sure about this either but found a couple of clues…

It makes more sense next to the companion setting Public user custom fields:

And they have to do with who can access which records via the API:

Using the API to retrive the value of a custom user field from a user

If you whitelist a user custom field in public user custom fields site setting then you can get it in /u/USERNAME.json API endpoint. Else if you whitelist in staff user custom fields setting then you can get it in the same API endpoint if you used a staff user’s / global api key.

Interestingly, the fields above don’t seem to select from available user custom fields, but take any text input – so you’d have to enter the field names precisely read this doc carefully.

[Moin]

@ToddZ

so you’d have to enter the field names precisely.

Is it the name? Based on the doc I shared above, I thought you need the ID

@Discourse

Enter the custom field in the format user_field_X, where X is the ID number you noted earlier.
For example, if your custom field ID is 7, you would enter user_field_7.

[ToddZ]

@Moin

Based on the doc, I thought you need the ID

Oh, I missed that in the doc! The field accepted whatever I typed & I made a bad assumption.

Also may be a case where it’d be nice for the setting description to have a link to documentation.

[JammyDodger]

@ToddZ

Also may be a case where it’d be nice for the setting description to have a link to documentation.

I think what would be would be having a custom field lookup for those admin settings that works in a similar way to the one in the ‘add user to group through User Custom Field’ Automation:

I think it was mentioned previously somewhere, but I don’t know if it got any traction.

[copymonopoly]

Thanks a lot for the suggestion!
Originally, I was planning to use custom user fields because I wanted to write a small component that displays specific information I add for each user. So I hadn’t really considered the Discourse User Notes core plugin.

But it does sound like User Notes might be able to achieve something similar, and it could be a helpful approach. I really appreciate the recommendation — I’m currently looking into it!