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.
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
And there is also a workaround with LookUps
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).
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.
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.
No, a read-only field is read-only for everyone, including the ‘Fibery ghost’.
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.
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).
Whether a field is read-only is defined in the schema, so it’s not something you define/change when creating an entity.
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.
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?
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”.
Sorry, I misunderstood your questions.
No, you can’t set the value of a read-only field at entity creation time.
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.
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.
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
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)
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).
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.
and maybe have similar limitations I have not yet discovered?
Doing so would imply that every entity in a database has the same (static) contents for that field.
That sounds more like a constant than a “field”.
