Hide Save / New buttons when read-only

[jannes]

How to hide Save / New buttons on a form when data is configured as read-only.
Now the user can click an "Add New" button but is not able to enter fields because the fields are read-only.

It is possible to check Person.AccessLevel = 'Administrator' etc.., but I would rather like to test the object-properties itselves like :
Person.FieldAccess <> 'Read Only'

When using the check via AccessLevels you have to change the software very often when AccessLevels are altered.

[Jaymer]

1. Use Applicable to hide “add new” if no rights
2. Call a process when displaying a form instead of the built in “edit object “. The process can check criteria, then
VIEW CustInfo USING xxx NOEDIT
ELSE
VIEW CustInfo USING xxx
…to be in read only mode. Save button will not be there

[jannes]

Which criteria can be checked in the process?

I would like to check the Access property of a BO.
See attachment.

I couldn't find a way to do so...

[PointsWell]

The image you've uploaded is the Access to BO / Process / Query. That relates to the RegularUser.AccessLevel attribute and controls the RegularUser access to the objects in their generality, ie. can a RegularUser WHERE RegularUser.AccessLevel = 'User' create/read/no access ANY instances of a BO

You can lock an attribute using PROTECT rules and you can create rules based on AccessLevel and other attributes to lock individual attributes or the whole object.

If you are looking to have a form show EDIT SAVE CREATE based on what the user is doing with the form then you need to have two forms

1. Edit - this form would have the panel operations for Save and Cancel
2. View - this form would have the panel operation Edit

AIM does not know what the state (i.e. Edit or View) of a form, so you cannot test for this.

Also, if you are using Applicability to hide and show buttons this has an overhead. If you have lots of conditions and you have lot of conditional actions then you have a bigger overhead when displaying.

[jannes]

Thanks answering.

So, unfortunately it is not possible to easily hide/display a SAVE | NEW | DELETE button based on the table access / permissions.

There is a lot of overhead needed to achieve this.
The meta-data is in the system, but we can not use these properties via business-rules.

It would be great if we (in AIM 8.7 ?) don't need to develop a read-only copy of the each form (without SAVE | NEW | DELETE buttons) anymore.
@Support, what is your idea ?

[PointsWell]

Thanks answering.

So, unfortunately it is not possible to easily hide/display a SAVE | NEW | DELETE button based on the table access / permissions.

There is a lot of overhead needed to achieve this.
The meta-data is in the system, but we can not use these properties via business-rules.

It would be great if we (in AIM 8.7 ?) don't need to develop a read-only copy of the each form (without SAVE | NEW | DELETE buttons) anymore.
@Support, what is your idea ?

Hmm I feel like two questions are being answered here which was not my intention.

It is possible to hide buttons easily, it's just not without cost.

Applicability

Code: Select all

loggedInRegularUser.AccessLevel='Admin'

Show for users who are Admin

Code: Select all

loggedInRegularUser.AccessLevel<>'Admin'

Show for everyone who is not Admin

Code: Select all

loggedInRegularUser.AccessLevel IN ''Admin', 'Some Other level

Show for a list

The more buttons you have with accessibility conditions the heavier the load. If you have lots of conditions then it would be better to have to multiple forms for access levels and have the condition checking run when selecting the record and present the most appropriate form. If it is two buttons the impact will be relatively low, if you have 15 operations with three level conditions and a lot of logic then the overhead will be high.

If you had a form with 10 buttons and you are testing each of these for accessibility against three access levels then it would be faster for the end user to have three different forms one for each access level with no accessibility conditions.

The RegularUser.AccessLevel field and the AccesLevel BO are directly related but requires two acts, you need to create a Access Level Object AND add the line to the RegularUser.AccessLevel attribute (they should probably be automatically related)

If you set Access Level objects to alter access to Business Objects then it limits that access to ALL instances of that BO. This has flow on impacts, if for example you have Object1 which has a peer single relationship to ObectReference and restrict access to ObjectReference for AcessLevel restricted then you will get errors should a user with AccessLevel Restricted try to view Object1, due to the reference not being available.