Using business process definitions to manipulate read-only fields

Hi all,

I have a status field that I want to be read-only (so users can't manipulate it) and have the value changed by business process definitions only.  This doesn't seem to be possible.  Business process definitions are denied the ability to manipulate fields if they're read only.  I cannot understand the reason for this.  

Any advice much appreciated.

Regards,

Dave.

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

    André Lopes
    Lampada Global
    Skype: andre.lampada
  • 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?

    Best Regards,
    Dmytro Chupylka

    integroscrm.com
    We make work in Sugar CRM system faster, more convenient and efficient

  • 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?



    Best Regards,
    Dmytro Chupylka

    integroscrm.com
    We make work in Sugar CRM system faster, more convenient and efficient

Reply
  • 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?



    Best Regards,
    Dmytro Chupylka

    integroscrm.com
    We make work in Sugar CRM system faster, more convenient and efficient

Children
No Data