Lesson
3
Member mastery
The Studio’s configuration can respond to the current member’s role, offering a more guided experience for content creation.
Log in to mark your progress for each Lesson and Task
Review Roles in the documentation
If members of a specific role should not be able to edit a field – but will benefit from seeing its current value – mark it as read-only by inspecting the current user's roles.
// Lock this field unless you're an administrator
defineField({ name: 'discount', description: 'Contact an Administrator to change this value', type: 'number', readOnly: ({currentUser}) => { const isAdmin = currentUser?.roles.some((role) => role.name === 'administrator')
return !isAdmin },}),
Note that this will only protect the field in the Studio and not from an API request.
Customize a field's
readOnly
property per-userThe same function is available in the hidden
key, so fields are not visible to specific users.
Note that the field's value will still appear in the data, and an invalid field can still be hidden – potentially leading to confusion.
// Hide this field unless you're an administrator
defineField({ name: 'userId', type: 'number', hidden: ({currentUser}) => { const isAdmin = currentUser?.roles.find((role) => role.name === 'administrator')
return !isAdmin },}),
Customize a field's
hidden
property per-userReview Studio Tools and Tool API in the documentation
Tools can be conditionally loaded depending on – among other variables – the current user.
Perhaps you only want Administrators to see the Vision plugin for testing GROQ queries. The code below will return a filtered list to all non-administrator role users.
sanity.config.ts
export default defineConfig({ // ...all other settings tools: (prev, {currentUser}) => { const isAdmin = currentUser?.roles.some((role) => role.name === 'administrator')
if (isAdmin) { return prev }
return prev.filter((tool) => tool.name !== 'vision') },})
Customise Tools per-user
You have 3 uncompleted tasks in this lesson
0 of 3