# Customize Fields via Rules **URL:** \ **Category:** Ideas & Features\ **Tags:** flexible-domain\ **Created:** [April 4, 2021, 5:44am UTC](https://community.fibery.io/t/customize-fields-via-rules/1523 "2021-04-04T05:44:29Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![Matt\_Blais](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/matt_blais/32/1464_2.png) [@Matt\_Blais](https://community.fibery.io/u/Matt_Blais)\ **Post date:** [April 4, 2021, 5:44am UTC](https://community.fibery.io/t/customize-fields-via-rules/1523/1 "2021-04-04T05:44:29Z")
I’d love the ability to customize the UI appearance of an entity’s fields – and most importantly, to be able to make some fields **“read only”**. A **“read only”** single-select field would be very useful to define an entity as a particular “subtype” of its Type (or subclass – another roundabout attempt at polymorphism?) We don’t want a user to be able to accidentally (or ignorantly) change this! Lacking this ability, Formula fields will probably be overused (by me), because it is the only way I see to define a “fixed” or “constant” field that could be set by a script but not (easily) changed by a user. But Formula/Text fields cannot define rows/columns in a Board view 😭 and maybe have similar limitations I have not yet discovered? What I would like to be able to control, for **each field** in a Type: - UI **read-only** status (prevent UI from changing value) - Script **read-only** status (prevent scripts/API from changing value) - UI visibility (hidden?) - UI foreground & background color I suppose this sort of customization should also be dependent on the _User’s Role_. It certainly makes sense to be able to prohibit certain Users/Roles from changing certain fields - or Types. I imagine these options could be controlled by adding Rules to a field in the Type definition. ---
**Author:** ![Polina\_Zenevich](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/polina_zenevich/32/480_2.png) [@Polina\_Zenevich](https://community.fibery.io/u/Polina_Zenevich)\ **Post date:** [April 6, 2021, 1:37pm UTC](https://community.fibery.io/t/customize-fields-via-rules/1523/2 "2021-04-06T13:37:18Z")
Hi, Matt! Thanks for the ideas - need to think about it. Not sure that we would approve per-field permissions at least in the nearest future. But your request is noted. And we definitely plan to improve permissions and access levels. Btw, that is already possible to create a read-only field [using API](https://api.fibery.io/#field) And there is also a workaround [with LookUps](https://help.fibery.io/en/articles/3908489-lookup-field) ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [April 6, 2021, 2:28pm UTC](https://community.fibery.io/t/customize-fields-via-rules/1523/3 "2021-04-06T14:28:40Z")
> [@Matt\_Blais](#): > > But Formula/Text fields cannot define rows/columns in a Board view I think formulas can be used for rows/columns, provided the result of the formula is one of the supported data types (e.g. you can’t use text or date fields as rows/columns, but formulas that return a type or a user will work). ---
**Author:** ![Matt\_Blais](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/matt_blais/32/1464_2.png) [@Matt\_Blais](https://community.fibery.io/u/Matt_Blais)\ **Post date:** [April 6, 2021, 2:30pm UTC](https://community.fibery.io/t/customize-fields-via-rules/1523/4 "2021-04-06T14:30:27Z")
> [@Polina\_Zenevich](#): > > that is already possible to create a read-only field [using API](https://api.fibery.io/#field) Thanks - where is this possible in the API? ---
**Author:** ![Polina\_Zenevich](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/polina_zenevich/32/480_2.png) [@Polina\_Zenevich](https://community.fibery.io/u/Polina_Zenevich)\ **Post date:** [April 6, 2021, 3:08pm UTC](https://community.fibery.io/t/customize-fields-via-rules/1523/5 "2021-04-06T15:08:51Z")
[https://api.fibery.io/?shell#primitive-field](https://api.fibery.io/?shell#primitive-field) Described here, I suppose 🙂 We use this possibility quite a lot in Fibery, so if you need some help from developers - let us know 😉 ---
**Author:** ![Dimitri\_S](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/dimitri_s/32/1683_2.png) [@Dimitri\_S](https://community.fibery.io/u/Dimitri_S)\ **Post date:** [April 7, 2021, 2:57am UTC](https://community.fibery.io/t/customize-fields-via-rules/1523/6 "2021-04-07T02:57:20Z")
I like one of the ways Google Sheets handles restricted ranges where its just a warning that what you are trying to edit is restricted and there is an option to disable the warning for 5 minutes. Doesn’t even require permissions handing, and when used sparingly is very effective at preventing the average person from doing something that would breaking things. ---
**Author:** ![Matt\_Blais](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/matt_blais/32/1464_2.png) [@Matt\_Blais](https://community.fibery.io/u/Matt_Blais)\ **Post date:** [September 14, 2023, 7:23pm UTC](https://community.fibery.io/t/customize-fields-via-rules/1523/7 "2023-09-14T19:23:26Z")
@Polina_Zenevich - Regarding UI “read-only” fields: > `"command": "schema.type/create"` > … > `"fibery/readonly?": true,` Is there a `"command": "schema.type/update"` that will allow us to toggle the `"fibery/readonly?"` status of an existing field? Ideally, Admins would be able to toggle the Readonly status of any field, when editing the field definition. **ALSO -** For a field that is marked readonly, can **scripts and automations** change its value? ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [September 15, 2023, 7:03am UTC](https://community.fibery.io/t/customize-fields-via-rules/1523/8 "2023-09-15T07:03:13Z")
> [@Matt\_Blais](#): > > Is there a `"command": "schema.type/update"` that will allow us to toggle the `"fibery/readonly?"` status of an existing field? > Ideally, Admins would be able to toggle the Readonly status of any field, when editing the field definition. The schema can theoretically be modified, but toggling the read-only status of a field is a really bad idea. A schema modification like this will cause purging of caches in the core and a number of other services, which will result in some pretty serious performance hits. > [@Matt\_Blais](#): > > For a field that is marked readonly, can **scripts and automations** change its value? No, a read-only field is read-only for everyone, including the ‘Fibery ghost’. ---
**Author:** ![Matt\_Blais](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/matt_blais/32/1464_2.png) [@Matt\_Blais](https://community.fibery.io/u/Matt_Blais)\ **Post date:** [September 21, 2023, 7:09pm UTC](https://community.fibery.io/t/customize-fields-via-rules/1523/9 "2023-09-21T19:09:18Z")
> [@Chr1sG](#): > > No, a read-only field is read-only for everyone, including the ‘Fibery ghost’. So is the value of a read-only field set permanently when the entity is created? ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [September 21, 2023, 8:34pm UTC](https://community.fibery.io/t/customize-fields-via-rules/1523/10 "2023-09-21T20:34:05Z")
Not necessarily. A formula like Tasks.Count() will change as the number of linked Tasks changes. But the value can’t be changed by automation (incl scripting) or by users. ---
**Author:** ![Matt\_Blais](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/matt_blais/32/1464_2.png) [@Matt\_Blais](https://community.fibery.io/u/Matt_Blais)\ **Post date:** [September 21, 2023, 9:14pm UTC](https://community.fibery.io/t/customize-fields-via-rules/1523/11 "2023-09-21T21:14:34Z")
I wouldn’t expect to be able to change a Formula field. But for the other field types (text/number/Date/etc) – and Rich Text fields – if a field is defined as “read-only”, does that mean its value is frozen at entity creation time? - Can we set values of read-only fields when creating an entity via via the API? - Can we set values of read-only fields when creating an entity via a Form? For Rich Text fields this could be useful, for creating things like Dashboards that you don’t want users to be able to change, but you don’t necessarily want the entire entity to be read-only for all users (which we can’t do yet anyway). ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [September 21, 2023, 10:07pm UTC](https://community.fibery.io/t/customize-fields-via-rules/1523/12 "2023-09-21T22:07:39Z")
> [@Matt\_Blais](#): > > - Can we set values of read-only fields when creating an entity via via the API? > - Can we set values of read-only fields when creating an entity via a Form? Whether a field is read-only is defined in the schema, so it’s not something you define/change when creating an entity. > [@Matt\_Blais](#): > > For Rich Text fields this could be useful, for creating things like Dashboards I’m not sure what benefit there would be in making a rich-text field read-only for dashboard purposes 🤷‍♂️ Doing so would imply that every entity in a database has the same (static) contents for that field. I kinda assume that a dashboard gets its value from being a dynamic summary of current information. The need you’re describing seems to basically be per-field permissions, which, as Polina said before, is not planned (and I suspect very unlikely to happen in the foreseeable future, if at all). The next best thing is to split a database into two types, linked one-to-one, and set permissions so that some users can edit db1 entities but not db2 entities. Then, the fields in db2 effectively become the read-only fields, leaving the fields in db1 accessible to all. We do have some considerations about making fields in related entities more immediately accessible (without needing to create lookups) but not sure when and how this will happen. ---
**Author:** ![Matt\_Blais](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/matt_blais/32/1464_2.png) [@Matt\_Blais](https://community.fibery.io/u/Matt_Blais)\ **Post date:** [September 21, 2023, 10:33pm UTC](https://community.fibery.io/t/customize-fields-via-rules/1523/13 "2023-09-21T22:33:51Z")
> [@Chr1sG](#): > > Whether a field is read-only is defined in the schema, so it’s not something you define/change when creating an entity. I understand that – I’m not talking about changing the “read-only status” of a DB field just for a specific entity; I’m talking about defining a particular entity’s read-only field value _when creating the entity._ Because when else could it be defined? > [@Chr1sG](#): > > I’m not sure what benefit there would be in making a rich-text field read-only for dashboard purposes 🤷‍♂️ Doing so would imply that **every entity in a database has the same (static) contents for that field.** This makes no sense to me. We don’t specify _any_ field values when creating the schema. One of us is really confused here. Does a “read-only” field necessarily have the same for every entity in the DB? 😵 That sounds more like a constant than a “field”. ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [September 21, 2023, 11:35pm UTC](https://community.fibery.io/t/customize-fields-via-rules/1523/14 "2023-09-21T23:35:34Z")
> [@Matt\_Blais](#): > > I’m not talking about changing the “read-only status” of a DB field just for a specific entity; I’m talking about defining a particular entity’s read-only field value _when creating the entity._ Sorry, I misunderstood your questions. No, you can’t set the value of a read-only field at entity creation time. > [@Matt\_Blais](#): > > Because when else could it be defined? Here are some scenarios for read-only fields. - you create a formula field. The value of that field can vary from entity to entity, but can’t be edited. - the database has Created By and Creation Date fields. These cannot be edited and the value is set (by Fibery, not by the user) when the entity is created and will vary from entity to entity. - you add a new field (which is not read-only). You change the values of this field for some entities. You then make the field read-only via the API. The values are now set in stone for existing entities. Any new entities will not (and cannot) have this field value set to anything. - you create a new field via the API, and set it to be read-only, _and_ define a default value. All entities created will have the same value forever and always. > [@Matt\_Blais](#): > > We don’t specify _any_ field values when creating the schema. Actually, example 4 above is where it _is_ possible to create a read-only field _and_ specify its value in the schema. And since it is read-only, it’s default value is its lifetime value for all entities. But of course, this is effectively the same as creating a formula field which returns a constant. > [@Matt\_Blais](#): > > Does a “read-only” field necessarily have the same for every entity in the DB? 😵 That sounds more like a constant than a “field”. Not necessarily. As I said, it depends on the field. A formula field is a read-only field whose value is not necessarily static. Other ‘built-in’ read-only fields (Created By, Creation Date) will have a value that is static but not the same for all entities. Example 3 would also allow (some) entities to have differing values, but the values for all entities would be static. Example 4 would imply the same value for the field for all entities for ever. So they would be static **and** identical. But a field with a static (=constant) value is still a field. When I wrote this > [@Chr1sG](#): > > I’m not sure what benefit there would be in making a rich-text field read-only for dashboard purposes 🤷‍♂️ Doing so would imply that every entity in a database has the same (static) contents for that field. > I kinda assume that a dashboard gets its value from being a dynamic summary of current information. I was thinking of example 4, so I can see why it would be misleading if you were thinking of example 3. However (and this is kinda important) > [@Chr1sG](#): > > toggling the read-only status of a field is a really bad idea. A schema modification like this will cause purging of caches in the core and a number of other services, which will result in some pretty serious performance hits. So yeah, you could make a field as read-only at some point _after_ some entities have been created and given unique values, but you mustn’t be regularly turning ‘read-only’ setting off and on again And once set, any entities created subsequently would just have empty field values (assuming you didn’t also set a default value in the schema). I hope this is somewhat clearer 🤞 ---
**Author:** ![Matt\_Blais](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/matt_blais/32/1464_2.png) [@Matt\_Blais](https://community.fibery.io/u/Matt_Blais)\ **Post date:** [September 21, 2023, 11:42pm UTC](https://community.fibery.io/t/customize-fields-via-rules/1523/15 "2023-09-21T23:42:32Z")
> [@Chr1sG](#): > > You then make the field read-only via the API. _Sigh_ 😢 It would just be really useful to have a toggle for each field in the DB setup, where it could be marked “Read-only for non-admin users”. And changed as needed. Nothing to do with caching and changing the schema – just a way to prevent non-admins from **using the UI** to change certain fields, because we can’t have field-level permissions. Right now we have to do this ugly work-around with a Formula field and a hidden field. 🦨 ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [September 22, 2023, 6:10am UTC](https://community.fibery.io/t/customize-fields-via-rules/1523/16 "2023-09-22T06:10:45Z")
Related > [@'Locking' entities](https://community.fibery.io/t/locking-entities/911): > > Would it be possible to make it so that an entity can be locked for changes (and unlocked again when needed)? It’s sort of a permissions issue, but I need the permissions to be dynamic, rather than fixed by the admin at app level For my use case, simply switching the entity between ‘apply-normal-permissions’ and ‘nobody-can-edit’ is what I need. Depending on the implementation, the users who have lock/unlock permissions could be asymmetric (an engineer can lock an entity but it can only be unl…