A better way to handle user props

This post is meant to answer the question:

What happens if I need to app custom props to Users (the User DB)?

I can tell you what we did, and what we should have done, so hopefully you don’t make the same mistake.

What we did was the straight forward thing: we added custom props right on the User. This worked nicely and things were looking fine, except there’s one small problem: that information is part of the user’s profile, meaning they can edit it.

This might be okay for certain props such as “Nickname” or “Hobbies” but for other props such as “Leftover vacation days” (how many vacation days did this person have remaining when we moved into Fibery) this might not be a good solution.
I could add a rule that alerts me when a person changes a field they’re not meant to, but this approach seems too convoluted and reactive.

What we should have done, and what we started implementing now, is to make a separate Database (such as “User Settings”) and store there all the properties that should belong to an user but not be editable by them. Then we associate that DB to the User with a 1-to-1 relationship and that’s it.

We get the flexibility that we need to add User props without the worry that they might change things they shouldn’t.

We are going to make improvements to access control for users, and it may eventually be possible to limit that regular users can’t make changes to their own profile. I suspect what you need though is something closer to field-level permissions (which we don’t plan on doing) for which your solution (a separate db to hold ‘sensitive data’ is the way to go).

1 Like