I just released a new community package for handling role based field permissions.
This is something our customers coming from previous versions of Kentico needed. We had quite a few fields configured with macro's in order to hide or disable certain fields.
So what can it al do? Here's a usecase for it:
Meet Maria, content lead at a busy marketing team running Xperience by Kentico.
😬 The problem: Her Article content type has a "Legal disclaimer" field that Legal carefully signed off on. But any junior author can open the article and edit it — and they do, by accident.
🎫 Before: Maria's only options were "trust everyone" or "open a developer ticket" every time a field needed locking down. Neither scaled.
✨ Enter Field Permissions: She opens the Article content type, clicks the Field permissions tab, and in a few clicks says: only the Legal role can edit "Legal disclaimer."
🔒 For everyone else: the field is now read-only with a friendly note — "Contact Legal to change this." No code, no deployment.
🙈 One step further: The sensitive "Internal cost" field? She sets it to Hide — authors don't even see it exists.
🆕 But creation still works: "Internal cost" is required when an article is first created. She ticks Show in create mode, so authors can fill it in once at creation — but can't touch it afterwards.
🎯 The result: Legal keeps control, authors stay productive, and Maria never files another "please lock this field" ticket.
Field Permissions turns "we need a developer for that" into "I'll do it myself in 30 seconds" — role-based, per-field, right inside the Kentico admin.
This package does help us, but the main difference is that it's stored in content, and content cannot be released using CD. Something which hasn't been added yet is macro support or another way to bind code to these permission configurations.
Since I guess more Kentico partners who upgrade from KX13 to XbyK must have run into this: how do you handle this?
How could we get these configurations easily from dev to prod? Or would you prefer enabling this functionality for certain editors so they can configure it themselves? (of course we need a different UI approach for that)
Any thoughts on this would be welcome, it might even lead to additions to make this package even more useful.