PROTECT/READ PROTECT Issue

[Jaymer]

in another thread:

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.

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.
-- 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 " ?

[PointsWell]

What I do in these situations is CREATE BO with BO.Attribute=Value No VALIDATION NO RULES

EDIT BO using form name

Then your PROTECT will work as you need it to.

This route requires a cleanup process if the user presses cancel to prevent detritus building up.

If the UI is involved in initiating something then it is not system. If it is a timed process it is system running the process.

[PointsWell]

An alternative is to Leave the field as unprotected set it but omit it from the form and instead use an HTML field to show the value

[Jaymer]

sure, but then to use the same Form for BOTH types of users, I need to selectively Hide a field based on AccessLevel.
So I need the HTML Cell to show the Shortcut. I can use SECTION_START SECTION_END to show/suppress this, but I'll still have a gap on the form.
Then Above/Below that I need to have the Combo Box for Admin users to select normal values.

Normally, READ PROTECT does this nicely, but thats the problem, so can't use that.

And its a PITA to place HTML fields on forms if you already have forms designed, because spacing gets messed up and issues if you do/do not have columns on the form, etc.

Separator sections are hidden easily - but that involved putting 1 field in a section - and then you can't have other fields on the same line.

Nothing is an elegant solution.

There is also the way to just hide a field: markup.css ("display", "none"); attached to the field SCRIPT on the form.
But it needs to be conditional based on AccessLevel so I'm not sure of the exact JS/JQuery to make that happen - just haven't played with it.

[PointsWell]

Then use the previous option CREATE BO WITH BO.Attribute=Value NO VALIDATION NO RULES then VIEW or EDIT BO

[Jaymer]

Then use the previous option CREATE BO WITH BO.Attribute=Value NO VALIDATION NO RULES then VIEW or EDIT BO

This is a non starter

[Jaymer]

OK, here is another use case:

A user form contains a field: BonusYN
When Admin is editing the form, you want to see the field.
When User is editing his own form, field should be HIDDEN.

Simple RULE in the user table:
IF RegularUser.AccessLevel='User' THEN READ PROTECT RegularUser.BonusYN FROM ALL EXCEPT SYSTEM

Form behaves likes it should.
All is good until this rule in the OrderHeader table:
IF OrderHeader IS NEW AND OrderHeader.ps_Rep.BonusYN='Yes' THEN OrderHeader.RepBonus = '10.00'

The rule will not work because of the READ PROTECT. The "catch 22" - the fact that you don't want the user to see a field ALSO makes the field un-accessible in ALL RULES & Formulas.

I MUST BE doing something wrong - or do not understand this concept. OR there is a BUG because I would think the "FROM ALL EXCEPT SYSTEM" would mean that a RULE calculation is being executed by the server and thus shouldn't be affected by the RP.

[PointsWell]

OK, here is another use case:

A user form contains a field: BonusYN
When Admin is editing the form, you want to see the field.
When User is editing his own form, field should be HIDDEN.

Simple RULE in the user table:
IF RegularUser.AccessLevel='User' THEN READ PROTECT RegularUser.BonusYN FROM ALL EXCEPT SYSTEM

Form behaves likes it should.
All is good until this rule in the OrderHeader table:
IF OrderHeader IS NEW AND OrderHeader.ps_Rep.BonusYN='Yes' THEN OrderHeader.RepBonus = '10.00'

The rule will not work because of the READ PROTECT. The "catch 22" - the fact that you don't want the user to see a field ALSO makes the field un-accessible in ALL RULES & Formulas.

I MUST BE doing something wrong - or do not understand this concept. OR there is a BUG because I would think the "FROM ALL EXCEPT SYSTEM" would mean that a RULE calculation is being executed by the server and thus shouldn't be affected by the RP.

Anything started from the UI is not a SYSTEM process.

You're easiest way of avoiding this issue is to use multiple forms.

I see PROTECT rules as an absolute to hide and protect data that exists. You are going to hit all type of issues as you have using it in the creation of data in conjunction with access levels. Other than in tenanted situations where one tenant absolutely cannot see another tenant's data READ PROTECT I only use it to control data access based on status e.g. if order.status="shipped" then protect order from all except system

[Jaymer]

You're easiest way of avoiding this issue is to use multiple forms.

Given such a comprehensive RAD tool as AwareIM, this is a poor alternative.
Duplicating a form to hide access to 1 field?
Gotta be a better way.

[PointsWell]

You're easiest way of avoiding this issue is to use multiple forms.

Given such a comprehensive RAD tool as AwareIM, this is a poor alternative.
Duplicating a form to hide access to 1 field?
Gotta be a better way.

Strictly speaking it is the more secure method, an error later won't expose the fields.
It's also the more maintainable as you will be removing the complexity of code for the simplicity of a form, you're not going to come back to it in 18 months and forget why there is a whole bunch of code with conditions showing and hiding attributes.

Simplicity rules for me.

[ACDC]

Strictly speaking it is the more secure method, an error later won't expose the fields.
It's also the more maintainable as you will be removing the complexity of code for the simplicity of a form, you're not going to come back to it in 18 months and forget why there is a whole bunch of code with conditions showing and hiding attributes.

Simplicity rules for me.

I agree, also forms have automated access rules based on the logged in user. So you don't have to worry about making provision for it in the rules. This concept is definitely deep-rooted in AwareIM