Panel Operation - Add New Record (Inline Editing)

PointsWell

It appears that when you use Add New Record (inline editing) as a Panel Operation in a Query the new record that is created in the Grid does not have the owned by attribute set until the record has been saved.

This creates an issue if you have a Shortcut to lookup records based on a value of the parent record.

nhofkes

Hi PointsWell, I am wondering how you resolved this. My guess would be that instead of creating the standard "Add New Record" Panel Operation, it's possible to define a Panel Operation that calls a process - this process would then Create the child record and set the owned by attribute to the parent BO. The user can then proceed to edit that child record inline, and because it already exists and has the reference to the parent BO, the shortcut that references lookup records based on a value in the parent BO should work.

PointsWell

Generally I have stopped using built in Add Reference methods.

Everytime I need a child I first CREATE the record setting all of the required reference values and then edit it. Typically I use a flag on the BO to capture whether the BO has been modified beyond the first settings and either as part of the process of creation use the flag to delete unmodified orphans.

The deletion process is triggered by changing the object ID tracked in a session variable or by an scheduled process to sweep up any orphans - setting a period of time after which the object is stale and then deleting if the flag is unchanged.

The flag is generally set on some mandatory field, eg

IF Contact.Name WAS CHANGED AND Contact.Name IS DEFINED THEN Contact.qDeletable='No'

aware_support

Seems to work fine for us. Could you please send a small BSV for testing?

PointsWell

** NOTE - this post is prefaced with the acknowledgement that the original post is over three years old, I cannot remember the exact scenario that I was having trouble with so the example below is a recreation as best as I can remember **

See attached.

There are 2 BOs

ParentObject which has Name and omChild and
ChildObject which has scParentName and obParent

Run and press the button on the VP.

This will create a ParentObject in the panel below. Place a name in the Name field, then press the Add Child button this will create a popup window for ChildObject using Add Reference.

Because the ParentObject has not been saved the Child Object has no knowledge of the shortcut path.This has impacts for the flow of creating a parent child BO relationship. It also has implications if you have used inline editing where you might have a selection of options from the parent.

If the user can create a Parent and then add Children objects and then validly cancel the process then the parent and the child needs to be destroyed (which an Owns/Owned By relationship would enforce).

The issue arises where there are Parent level attributes that you might need to display at the Child level. Consider the creation of an order. An order may be in one of two currencies in this example. Orderline needs to show the price in the determined currency, but currency cannot be capture as a shortcut until Order has been saved. If order is saved but then cancelled then there is an overhead above and beyond the user just pressing the cancel button.

I am not sure how you would fix or work around this, but I have moved to a process where a temporary BO (tempOrder) is created and saved and then converted to a real BO (Order) once the user confirms the save. If you create Order at the outset and then save it before adding in OrderLines then you have an issue with other users queries picking up the Order before the user completes (or abandons the Order).

This is an example of a work-around there are multiple alternative routes to achieve the same before anyone jumps in with their own solutions.

AddReference.bsv.zip

45.17kB

ACDC

If you create Order at the outset and then save it before adding in OrderLines then you have an issue with other users queries picking up the Order before the user completes (or abandons the Order).

I have a similar app, but the Order has a Status attribute that gets set to "Completed' once all is done.
Other users cannot see the Order and its contents until such time the order is set to "Completed"

Not sure if that would fit into your workflow, but all my accounting related transactions work this way i.e. Create parent object first, then child object - a transaction needs to be in a completed state before becoming available to the rest of the users and system