Skip to Main Content
Feature Request FR-2608
Product Area Page Components
Status CLOSED

39 Voters

Interactive Grid: Execution Scope = "All Submitted Rows" should submit all rows, not just new/modified rows

brian.d.hill Internal · Jun 28 2022

Idea Summary
For an Interactive Grid (IG) - Automatic Row Processing (DML) page process, setting the Execution Scope should process every row from the IG.  Currently, it behaves exactly the same as “For Created and Modified Rows”.

Use Case
On our current Inventory project, we have a requirement on a page to let a user perform a “Save As” feature on a parent-child data set on the page.  This pattern occurs multiple times within their app.

For example, they could be looking at an Order with multiple Line Items.  The Order info is displayed in a header region while the Line Items are displayed in an editable IG.  They would like to be able to edit some of the Line Items and then click a “Save As” button which will copy the Order and save the edits *only to the new copy*.  On Save As, the original Order will remain untouched, and all changes will be written to the new Order and its Line Items.  Without the “All Submitted Rows” functionality, we can only process the modified rows - we will lose the unmodified ones.  There are work-arounds for this (like executing some JS to mark all rows as modified) but they are less preferable than something declarative.

Preferred Solution (Optional)
When Execution Scope = “For Created and Modified Rows”, the behavior should remain the same - process only created/modified rows in the IG.

When Execution Scope = “All Submitted Rows”, process every row from the IG.

I believe this is how it worked with Tabular Forms.

We reviewed this idea carefully, and while it was interesting, we concluded that it is unlikely to make its way into APEX in the foreseeable future.

Comments

Comments

  • jayson hanes Admin OP 3.6 years ago

    this got me irritated back when working on the Pandemic Response apps, CoVPN and VPoP, but has obviously been an issue for longer.

  • joseassumpcao OP 3.6 years ago

    Is this a bug? What “All Submitted Rows” really does with IG? Also please add a option to process “All Selected Rows” and maybe put an option to not let multiple identical lines be submitted (both new lines or a set of new line(s) with existing one(s))

  • bshumway OP 3.5 years ago

    This feels like a bug.

    I have a perfect use case for “All Submitted Rows”. I need a validation that makes sure there is at least one row in the IG.

    On "Page Processing - After Submit" I set P10_HAS_ROWS = ‘Y’ in a process that is set to the editable region and all submitted rows.

    Then my validation checks if P10_HAS_ROWS = ‘Y’. 

    The issue is… if the user made no changed to the IG… then the process doesn't trigger and P10_HAS_ROWS is still its default value ‘N’.

    Please fix :)

  • jayson hanes Admin OP 3.5 years ago

    Well, it's only a bug if it behaves in a way that wasn't intended.. this behaves this way because it is intended to be this way as is – and is really just, “incomplete functionality”.

  • jayson hanes Admin OP 3.5 years ago

    FWIW, internally, Patrick and I have had this discussion but it's no secret:

  • john.snyders APEX Team OP 11 days ago (edited 10 days ago)

    There is confusion of what being on the roadmap means for this idea so the status has changed.

    The Execution Scope = “All Submitted Rows” is ambiguous. For IG it really means the same as "For Created and Modified Rows" since those are the ones that are submitted. Wanting it to mean All Rows is not a workable solution because an IG region result set can contain thousands of rows and it is not reasonable to submit all of them to the server for processing (or even possible unless the client has requested all the rows).

    The solution is to treat this as a bug to remove the confusing option that doesn't apply to IG.

    For the use case of validation I wrote this: https://hardlikesoftware.com/weblog/2022/04/25/interactive-grid-validation/

    For the idea that there should be an option of “All Selected Rows” there is now the API option selectionStateItem (https://docs.oracle.com/en/database/oracle/apex/24.2/aexjs/grid.html#selectionStateItem) that can be used to send the PKs of all the selected rows. This is a little different because it doesn't contain the edited values but does fit a number of use cases and it should be possible to combine the selectionStateItem with the saved data in server side processing (I haven't tried this).

    If IG ever had a declarative Patination Type = "None" meaning that all data is always sent to the client then our opinion on Execution Scope = All Rows might change but it could only apply to this pagination none case.

  • pericles OP 10 days ago

    Well. I think it should be a prerogative of the developer to decide weather he/she need to submit all the records, or only those modified. At the end the application should be a tool to implement what it's needed, no matter the reason that justify it. 

    “Wanting it to mean All Rows is not a workable solution because an IG region result set can contain thousands of rows and it is not reasonable to submit all of them to the server for processing (or even possible unless the client has requested all the rows)” I don't remember to have an IG with more than a few hundreds of records, and in a daily basis, I would say a few dozens of records, because it's absolutely impractical to do so. Simply IG it's not the tool to handle such a bast amount of records.

    That leave us (The developers) without a functionality  that, when it's needed, it's not available.  That's why this FR was created

  • mark.w OP 10 days ago

    @john.snyders I understand that there is a difference between currently displayed rows and all rows in the data source - which seems to stand in the way to implement this FR. And yes, sometimes it might be unwise to process potentially unlimited rows.

    But IG was touted as the canonical way to edit tabular data. In many applications we use it in ways which go beyond editing of records in database tables.

    One current use case is to select “exports” (or data for some further processing) and in the same dialog choose options (LOV) per row. This means selected rows need to be submitted together with their respective option (LOV value). So far so good - but… The caveat here is that of course there are default values as well for the selection as for the respective options. If the user does not change the defaults none of the rows get submitted. As a workaround I ended up with some javascript (more than I liked to). But it all could be much easier - and more in the spirit of APEX - if the developer could choose to process all rows (including unchanged rows). For my above mentioned use case it would be ok to choose pagination = none.