View/Edit Object from a Grid - issues

Jaymer

Picture any grid of a transaction/order/inventory item/etc.
sometimes the object is editable, sometimes because of its STATUS, it should be “locked” and no changes allowed.
sometimes it might depend on the rights of a user wanting to see the object.

But an easy scenario for now…
1) I could have 2 buttons in the grid, and take up 2 columns (which is annoying), and EITHER the Edit or View button will be visible. This could use the built-in View Object & Edit Object buttons and for many things, this is fine in most simple cases.

2) But I’d rather call a Process and let it determine if it does a EDIT Invoice, VIEW Invoice, or VIEW Invoice NOEDIT based on confitions.

3) # 2 works well, and in NOEDIT mode all seems fine (same as in VIEW Object from the Grid), except for Form Sections that show child reference tables. Because now all the Panel Operations are “live”. The NOEDIT mode only controls fields and hiding the SAVE button. But you could still add a new item to the order long after the Order is SHIPPED.

The only way I’ve found to solve this is extra applicability conditions on each Panel operation and on any Buttons you’ve added inside a form. Kinda of a pain.
(ex. Applicable when NOT(Invoice.Status IN ‘Shipped’, ‘Cancelled’, ‘Hold’, etc etc) )

Is there another solution ?

PS _ I’ve added conditions on Section TABs (in a Form) and Panel Operations to be invisible/not applicable when in ADD Mode, rather than make an entirely other “Main” Form Section exclusively for Adds. If so, I check for ID UNDEFINED, or ID < 1, and then I know its in create mode because ID doesn’t have a value yet.

kklosson

I may not fully understand, but it seems you could use PROTECT rules:

Example:
Provide this rule in the Update Rules of the InvoiceChild object:

IF InvoiceChild.Invoice.Status=‘Shipped’ OR InvoiceChild.Invoice.Status=‘Cancelled’ OR InvoiceChild.Invoice.Status=‘Hold’ THEN
PROTECT InvoiceChild FROM ALL Except ‘Administrator’ /* or just ALL */

This won’t hide the ADD button or in-line EDIT buttons, but if you click either, I believe it would ERROR stating a permissions issue. This Rule would be global and that should be a benefit because I would think you want to globally prohibit changes to the InvoiceChild objects when the Invoice is in those states and you don’t have to think about any other situations i.e., other forms. You could still use applicability setting to hide those buttons just to keep things nice.

Jaymer

kklosson

well since you don’t know exactly, I can think that if I clicked a panel operation on a child grid that has been shown inside a parent header, the button is gonna execute something… It depends on if the button was add new, add reference, edit object, etc. Or start process in my case usually.
And if I get a error, well that’s bad for the end user.

And if I had to add applicability conditions on the buttons, well, then I’m back to my original post. Yeah I have to manage all those buttons, even if the object is in view mode.

nhofkes

I work with Transactions, which can have status like Draft, Pending, Completed. Depending on the status, some details may or may not be editable. To control that, I generally do not use the standard View/Edit functions, but call a process that invokes the required operation. Furthermore, I use different forms, so there is one form to edit a Draft Transaction, and another form to edit a Pending Transaction. It’s a bit inconvenient because you need to duplicate forms, but I found that not everything can be solved with applicability rules.

As regards the PROTECT rules: that may work if the entire object should be non-editable, but (as far as I know) it can only operate on the object as a whole, so you can’t PROTECT only certain attributes while leaving the other attributes editable. This can be solved with presentation rules.

Jaymer

nhofkes yes. Agree and agree.
I use diff forms like this as well.

I don’t like using protect rules either.
Vlad‘s example from 6 to 8 years ago is on demo data.
And his simple examples hide rows, but I can’t remember exactly the issue. I wrote a paper on it long ago.
I think the filtering is done at the aware engine level, not at the back end.
So lots of rows are returned to aware and then it has to process the rules to determine which rows to send out to the browser.
That’s a trade-off between a simplistic rule, and lots of overhead, which is not visible in a demo data situation.

I wonder if any serious apps use a lot of protect rules.
Oh yeah, the protect rule example I’m thinking of was in the video on how to do multi tenant apps.

kklosson

I use them as an imperative in my multi-tenant app. Without them, several easy and well-known hacks can get to unauthorized data.