Basically custom fields on an existing page inherits the underline page permissions. Lets say one user has write access to one page and then he also gets write access to the custom fields added in the same page. If you need to give them read only access, you have to configure permission for the particular screen as read only. 

If your requirement is to allow the user to write other fields in the same page while disabling write option only for this custom field, I don’t think its possible through permission sets and presentation objects securing functionality. 

The easiest solution would be to create a custom event. 

If it is ok to create the persistent custom field in a different page and then only add it to this page as a read only custom field then you can control security from that different page though. This is not I have tried but lets think of like creating a separate custom logical until to hold your custom field (checkbox) as a persistent custom field. And for the existing page you add only a read only type custom field - you only display its value on this existing page but won’t allow to edit. For the specific users that you want to allow to edit this, ask them to go to that specific page based on the custom logical unit and do the modification from there. 

Hi @robert_g ,

If you do not wish anyone except a certain department or individuals to update custom fields on a page such as shipments orders you could grant query only on custom fields - grants for custom fields LU Shipments.

Another option which we’ve done is we would set certain custom fields on the shipment screen as read only within a profile we define then we assign that base profile to select individuals or groups of individuals. 

Reqards,

William Klotz

No, this isn’t possible yet, and these kinds of limitations are why custom events have been offered as a tailoring option.

A custom event need not be complicated. You might create a new permission set called CAN_EDIT_FIELD_X, then set up your event and event action on the _CFT table.

BEGIN
   IF NVL('&OLD:CF$_FIELD_X', 'NULL') != NVL('&NEW:CF$_FIELD_X', 'NULL') THEN
      IF security_sys.has_user_role_access('CAN_EDIT_FIELD_X') = 'FALSE' THEN
         error_sys.appl_general('FndBas', 'CANTEDITX: You do not have permission to edit Field X. (If you think you should, ask IT to grant you CAN_EDIT_FIELD_X.)');
      END IF;
   END IF;
END;

Then you’ll grant CAN_EDIT_FIELD_X to the appropriate users.

Thanks a lot for the clarification. In the end up, I created a custom event which triggers when the custom field is changed or added to. Then I setup a person group, used a cursor to loop through the group and if the logged in user wasn’t part of the group then the error displayed.

 

If you put the username in the WHERE clause of your cursor, you can trade the O(n) performance of a brute force linear search with the O(log n) performance of an index search. You’d just check whether the cursor was %FOUND and stop searching when it is. More importantly, this could make your code smaller and easier to read.

BEGIN
   IF NVL('&OLD:CF$_FIELD_X', 'NULL') != NVL('&NEW:CF$_FIELD_X', 'NULL') THEN
      IF security_sys.has_user_role_access('CAN_EDIT_FIELD_X') = 'FALSE' THEN
         error_sys.appl_general('FndBas', 'CANTEDITX: You do not have permission to edit Field X. (If you think you should, ask IT to grant you CAN_EDIT_FIELD_X.)');
      END IF;
   END IF;
END;

I actually had to amend my code and used the second if statement you included and this worked perfectly. Means I didn’t have to call any new/modify API’s also.

Thanks a lot!