Hi,
I’d like to be able to save some additional values for backoffice users (code access, don’t need UI).
Is there any sort of property bag I could use?
biapar
(Biagio Paruolo)
May 17, 2025, 2:23pm
2
How mean “don’t need UI”?
It’s values that I would read/write from code, they don’t need to be visible/editable in the backoffice (its also ok if they are)
sebastiaan
(Sebastiaan Janssen ⚓)
May 18, 2025, 2:28pm
4
Any values you can see in the UI in the Users section can be set by code, there are no custom properties you can add to users though. So if you want to store something like “job title” for an Umbraco backoffice user, you could store that in a new custom database table that you make yourself.
KevinJump
(Kevin Jump 🐶🐖🍞)
May 19, 2025, 8:43am
5
In v15 there is the UserdataService
(you would use IUserDataService
in your code). which i think has been revived to make storing data for user tours etc, more generic.
v14/dev
← v14/feature/user-data
opened 11:52AM - 21 Mar 24 UTC
### Prerequisites
- [x] I have added steps to test this contribution in the d… escription below
### Description
The original goal was to make sure the tour endpoints had no knowledge of what the tour data was and just store it instead of checking the validity. While investigation the code paths and talking to stakeholders for the use cases it became clear a more generic feature would be a better fit instead of trying to push things into a semi happy state.
Userdata is a collection of user bound data identifiable by key or group/identifier. It is not considered an entity but rather a bucket of anything one would like to store against the user without validation/knowledge on the server side. This allows syncing of client related information across multiple hosts. Example: tours and user settings like theme and language.
### Cleanup
- tour endpoints removed
- tour viewModels removed
- tour mapping and related DI registrations removed
- usertourStatus model removed
- TourOperationStatus removed
- Removed tourfiters (way to filter out tours inserted by other plugins/core)
- Removed tour defenition models (BackOfficeTour,BackOfficeTourFile,BackOfficeTourStep)
### Breaking changes
- Tourservice removed
- UserDataService repurposed, was marked as obsolete as it was superseded by ISystemTroubleshootingInformationService but the naming was to pefect...
- UserData model repurposed, similar to previous remark
- Iuser does not have tourdata field anymore
- Tour definition classes have been removed
- Global enable/disable tours is removed => frontend concern
### Testing
- Consider taking a v13 database with a user that clicked around the backoffice a bit and thus should have tours data. Migrating the db to v14 and check wether the UserData get endpoint returns the tours data.
- Test other UserData endpoints
- Make sure nothing else is broken
this lets you store key/value pairs against a user, I don’t think there are any reasons why you couldn’t use it for your own data.
5 Likes