Readonly fields changes made from system should be tracked in updates.

Code changes made on Readonly fields are currently being untracked as direct queries are being used. Need an API on server end that enables the changes but also does the change tracking.

Ref: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/2021-July/040115.html

A very simple use case, tracking approval date for any record. What one would do is create a readonly field for Approval date and would like to update it when the Status is changed to Approved.

The field should be readonly, as approval date is required in many audits and also in many cases this dates just can not change.

Another example, calculating certain values, such as the margin in Invoice. Ideally once an Invoice is generated that itself should be locked.

If a field is changed due to workflow setup by admin then it would be locked for profile - so the safe assumption to make is change happened through system unless some manual tweak is done by admin.

Sorry I did not get your point @prasad "If a field is changed due to workflow setup by admin then it would be locked for profile".

Workflows are available only to admin users. And the permissions are based on the Assigned to user, what is the link between who created the workflow and profile of assigned to user?

I meant if admin setup workflow to update a field, usually they would lock the field write on Profile to match the process.

Ah okay, even the admins should not be able to edit the field, that is when we introduce readonly fields.

And as I can recall, readonly fields are not availablefor mapping in the Update/Create record workflow actions. Neither one could update them using Models, one has to do direct database query.

Admin are more like sudo-users, overrides are allowed for them. Good to have less admins in the CRM. If workflow updates are locked on such field there should be reason - we need to review the purpose.

But I would also agree to the point that, it is a reaodnly field so yes, it should not be updateable even from workflows!

So then we need a another indicater for the field, for fields which can be updated using only workflows.

In certain cases, compliances/regulatory needs even admin can not be allowed.

In many casses, It's very hard to lock the field write on Profile. Because the installation can has many profiles and many new profiles. You have to remember this fields by creating new profile, insteat of ONE readonly setting.

It would be wonderful to have a “system” user allowed to do changes on read only fields

it happened to me many times to have fields used to just display calculated values.

Problem is that using display type 2 for those fields doesn’t allow modification using vtlib or vtwsclib so we can only do direct database queries, but this way change events (logging) don’t fire up.

What can we do about it?

I agree on creating a special kind of field that is readonly but modifiable by admins via workflow or direct edit (Unlike fields like for example "Modified Time", which should not be editable by admins/workflows). Those fields should also be editable via vtws_update (again, for admin users) and via Vtiger_Record_Model. I constantly find myself needing to create queries for read only fields when it would be really convenient to use existing apis.

In each module I have created a block called "Calculations and automatic field updates - DO NOT EDIT". The block is collapsed and located in the bottom of the module to "hide" the fields from the users.

I just wish there was an option to hide this block from non-admin users", it should only be visble to admin users....

@mobilcmcdk You can. Using Roles and their permissions allows you to do that on a per field basis dependent on a Users role. Unfortunately you can do it for Admins unless you specifically have an Admin role in your hierarchy.

We could add a new display type to make a field only modifiable by admins. So that if a calculation is made by workflow, user can't overwrite it, but admin can. What do you think?

It could be done by way of a new vtws_revise_field type method. This could be called by either a workflow (i.e. Update Fields) or by a third-party application/extension module or event handler or REST call or whatever.

In a similar way to how the vtws_revise doesn't require mandatory fields to be populated, vtws_revise_field should be able to override the displaytype and/or profile access on a per-field basis. But - of course - it should still trigger ModTracker.

Hi @lord_alan thank you for your solution, yes vtws_revise is broken , as you stated, it doesn't check mandatory fields, so I'm trying to find a general solution, that works on vtiger field model level.

@angelo.paglialonga ??? vtws_revise isn't "broken" - it was actually designed to be an alternative to vtws_update so that you do not need to provide all the mandatory fields.

I was suggesting a new method called something like vtws_revise_field($data, $user) which would bypass any permissions/read-only settings for a field specifically for this use-case.

@lord_alan vtws_revise is indeed broken, but in a different way. See #1561 (closed) for example.

@lord_alan I would expect rules to be enforced globally in vtiger following checks and permissions for the save action, dodging them just doesn't sound right. Honestly vtws_revise should be changed or modified to permit saving only having all mandatory fields in input, otherwise it's a bad design choice to me, what do you think?

@angelo.paglialonga No. That was the whole point of vtws_revise()! if you want to make sure all mandatory fields are populated then use vtws_update(). As the developer you have the control to decide the method you want to use.

We have plenty of clients who just need to update ONE field in a record from a remote system. vtws_update() is a PITA for this use-case. (If you want to update a User record, you can't even use vtws_update() right now because when you do a vtws_retrieve() the roleid is always returned empty.)