Using business process definitions to manipulate read-only fields

You would be able to set the readonly at the viewdefs layer only, this way SugarBPM will be able to manipulate it.

I wonder if viewdefs prevents changing the "read-only" field by performing an API call with any of the users' credentials via e.g. Postman - I guess if succeeded such a change will be treated by the Audit Log as the change on behalf of the username...
I suppose that if it is necessary to avoid manual data editing from the business perspective, the best way to reach readonly is to use field-level security in the application layer - so that it safely works for all interfaces without exclusions
Is it correct?

Is the user a non admin user but able to create workflows and by chance the owner of the process? Just thinking out of the box but this could preventing Sugar from changing the field if roles does not allow it?

Bests

Björn

yea, I also think of distinguishing - on one side the users that could use a field as read-only as it is set in field-level security for the user's role and on the other side an admin user or any other superuser that is allowed to edit the field - and to run the BPM on behalf of that superuser...

However, one example that comes to mind - setup a Process Definition for e.g. Note created and that process definition is a perpetual loop that fetches the records of lets say Accounts according to criterion and update fields in fetched records

In this case, such a process definition could be run on behalf of superuser, allowing them to edit files in target records while regular users are restricted in editing files of those target records (via field-level security).

Make sense to try?

Hi Dave Hodgman,

One way you could work around this is have two fields created on the module:

1. Source field
   1. This field would not be made available on any layouts or be available for mass update or import so that only BPM can make changes to it
2. Display-only field
   1. This field would have a sugar logic formula that consists only of the variable for the source field (e.g. $source_field)
   2. This field would be added to the layout(s) for your users to see. Sugar Logic fields are natively read-only since they are driven by calculation

With that setup, you could have BPM make the changes as you see fit and users wouldn't know any difference since the field they see is mirroring the source field value.

Kind regards,

Chris

Hiding from layout may help to avoid  accedental data editing, however IMHO not sure on whether that approach can ensure data security - if to follow hiding out from UI approach it might remain important to keep the source field name in secret from users along with the ability for them to use their credentials to edit the field in Sugar via quite simple rest API call (postman) with user credentials 

Dave Hodgman -

My suggestion would be to not mark the field as "Read Only" via Studio. The field will then be able to be manipulated via SugarBPM. For the "Read Only" portion you can add an Dependency, https://support.sugarcrm.com/Documentation/Sugar_Developer/Sugar_Developer_Guide_12.0/Architecture/Sugar_Logic/Dependency_Actions/ReadOnly/index.html, which will provide the same functionality as Read Only except it should not interfere with SugarBPM.

Thanks for your response Jeff.  I am a system administrator, rather than a developer, so I don't have the ability to implement what you've suggested. I note that applying a "Read Only If" formula via the Studio seems to be the equivalent of your suggestion, however it still blocks the BPM from accessing the field.

Hi Chris Raffle and thanks for your reply.

That works well!  Thanks for innovative idea.

Cheers,

Dave

Hi Dmytro Chupylka. 

I note your concern but I think Chris's idea is secure enough for our needs.

Cheers,

Dave.