PROTECT/READ PROTECT BUG?

Jaymer

An External user belongs to a Company, ps_Cust.
A user can log in and create a new Order.
Each order has ob_Cust.

User has a button "New Order".
Script: CREATE NEW Order WITH Order.ob_Cust = LIRU.ps_Cust

This works fine.
But the NEW_Order FORM has the ob_Cust combo box on it (to show the customer name) - Because an Internal user can use this same screen to create Orders - and that person would need to use the Combo Box to select the Customer for the Order. But you don't want the External User to change who the order is pointing to - cause he can only create Orders for his company.

Enter PROTECT Order.ps_Cust FROM ALL EXCEPT SYSTEM AND Administrator

This appears to work VISUALLY, but behind the scenes it does not store the data correctly.
Basically, fields that are PROTECTed will not get saved to the db correctly.

1) the LOG shows the correct instance getting assigned in the CREATE NEW Agenda item
2) The entry screen shows the ob_Cust Combo box set correctly,
3) No logging, Tomcat or Server messages indicate that those values should not be saved, YET the SQL table shows the truth.
The ob_Cust field will be null. (REN & RID).
Enen a non-reference field that gets set in the CREATE NEW line will show on the screen but NOT get saved.

Is there a workaround - well, yes, but I don't find it acceptable:

1) Make a diff form for internal and external user. For this user above, use HTML box to show the field
1b) Thats bad, because HTML fields require you have columns - and messing with columns takes more time to design and mess with. Less of an issue if you already have columns, but its a hassle when your form needs a column just cause you want to have a button over on the right after a field.
1c) And a 2nd form is unnecessary redundancy for the project when READ PROTECT should be the solution (unless I don't know what RP is for)

2) While you can't conditionally hide a field on a form without READ PROTECT, you can hide a Seperator/Group. So if these fields (I have several) were lucky enough to be all nicely grouped horizontally on a form, then sure, I could put them in a group and hide as a whole. But they're not.

I would think most people would say "just make a 2nd form and use HTML to show these fields" and move on... but I hate redundant forms just for minor visual tweaks.

PointsWell

Your issues arises from the owner by field being a weird kinda mandatory field that has to be set to create an ownership but if you make it required then it all goes wrong.

If you read protect it then logically the end user has no access to that field at any point. If a particular user has no access to a field then they cannot write to the field and they cannot see the field at all. For their purposes the field does not exist.

If you use css to hide this then you are subverting the security of the application as you have moved security from being server based to client and worse you make it secure by obscurity not through design.

If you want the owned by field to be visible but not editable then you will have to go the route of html.

Personally I'd view the disabling of a users ability to edit a field as not a visual tweak but a security / data consistency issue.

Jaymer

I just solved this to my satisfaction.
The other MAY be a bug, or just a misinterpretation of what a PROTECT really does under the covers.

1) READ PROTECT, in this case, is not the answer. Doing that made those 2 fields unavailable, as you said, so thats not the fix.
2) Since I only needed to PROTECT it, which is giving it READ ONLY Access (i have 2 fields that should never be able to be changed by a Cust access level) , then using Access Levels and going into the BO and setting "read only" on those 2 attributes worked perfectly.

Having done that, my other need was to hide a particular drop down box when Cust was entering a new record (a simple status field) - but not for an Internal user.
So I moved that into a Separator and put a condition on it.
PROBLEM: I can't get the Sep group to hide with this condition:
NO WORK: LoggedInSystemUser.AccessLevel='Cust'
WORK: LoggedInSystemUser.AccessLevel='Cust' OR 1=1
WORK: 1=1
NO WORK: LoggedInSystemUser.AccessLevel='Cust' OR LoggedInSystemUser.AccessLevel='Cust'

Since the status is Unknown when a Cust is entering a new rec, then using this is acceptable:
WORK: Orders.Status='Unknown'

So, there still may be a bug if my original PROTECT rule was valid and AIM just didn't write data correctly, and there may be an issue with AccessLevel hiding a Sep Group on a form.

NOTE: I named my field ob_Cust but its just a peer relation. Its not mandatory in my Orders BO.

PointsWell

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.