So what I'm finding is, that the very field I want to protect (ie. NOT let the user Edit) is ALSO a field that I need to set a value into - yet, because its PROTECTED, the assignment won't happen.PointsWell wrote:Protect won't work for the same reason.
Your Enter New with Status=value will not save that value because the user is initiating the creation of the object and the user can only read the field not write to it. So the Status=value will not be available to the end user unless the system initiated the Enter new with status = value.
Protect will only let an applicable end user read that field if that field exists already.
-- Catch 22 --
EDIT: 2nd use case posted below
I have an entry form that can be used by a regular user AND an Admin.
On ENTRY OF NEW RECORD:
The Admin can use a Combo box to assign a user.
If the user (ie. company employee) is entering the record, then I want to default the user to the Combo box value - and NOT let the user change it.
So I have a Process that finds Instance of LIRU, and a CREATE NEW xxx WITH yyy that sets the correct relationship.
But the value will not "stick" in the new record.
It will be NULL after Save.
I'm doing:
IF LIRU.AccessLevel<>'CustAdmin' THEN
PROTECT theBO.ps_User FROM ALL EXCEPT SYSTEM
and I would think that "system" is the process running the rule, and this would protect it from being changed on the screen.
It DOES prevent the screen combo selection.
I must have a fundamental thinking incorrect about this whole mess.
Because I keep finding fields that I NEED TO PROTECT from the user changing, and yet those fields are important fields that keep messing up fomulas, relationships, etc. cause the Rules cannot set values.
In the above quote, what exactly determines that " unless the system initiated the Enter new " vs. " the user is initiating the creation of the object " ?