Unmark row(s) for deletion fails to unmark context row(s) because Model property is not set

Questions
1

This stems from Rows not being unmarked for deletion after Model Save Fails

With 9.3.1, the “Model” property is still required when using “Unmark row(s) for deletion” even when choosing “Rows in Context.”

Unfortunately, an in-place upgrade of the sample page mentioned in the post above still fails to function properly with Brooklyn. The reason is that there is no model property (because that property didn’t exist in previous versions on unmark row in context). In order to get the page to work properly, you must go in to the XML to add the property or change Rows to use to “all” then back to “rows in context” (assuming you only have a single model on your page).

As discussed in the above post, when using “Context”, a model property should not be required. I see that in Brooklyn, “unmark row(s) for deletion” appears to be combined with “Unmark all row(s)” and they’ve become essentially the same thing under the covers. That said, configuration of a model property should not be needed when using context - context is context and model & rows are already known. Requiring a model property creates unnecessary maintenance for the page developer and increases risk of defects due to having to change this value if/when the model for the table row ever changes.

Proposed fix, as discussed previously, is to only have a “Model” property if “Rows to use” is “All Rows in Model”

Steps to reproduce:

  1. Create page from sample XML below (this is taken directly from previous post with the only change being changing the “Save” button to use “All rows in model” instead of “Rows in Context”)
  2. Preview page
  3. Remove the value for the Account Name in Row #1
  4. Click the square icon on row #2

Expected Behavior
Save should fail, error message displayed at top and Row #2 should be “unmarked for deletion”

Actual Behavior
Save fails, error message displayed but Row #2 is still “marked for deletion”

Sample Page XML

<skuidpage unsavedchangeswarning="yes" personalizationmode="server" showsidebar="true" showheader="true" tabtooverride="Account">    <models>
        <model id="Account" limit="100" query="true" createrowifnonefound="false" sobject="Account">
            <fields>
                <field id="Name"/>
                <field id="CreatedDate"/>
            </fields>
            <conditions/>
            <actions/>
        </model>
    </models>
    <components>
        <pagetitle model="Account" uniqueid="sk-3k7qR-110">
            <maintitle>
                <template>{{Model.labelPlural}}</template>
            </maintitle>
            <subtitle>
                <template>Home</template>
            </subtitle>
            <actions>
                <action type="multi" label="Save" icon="sk-icon-save">
                    <actions>
                        <action type="save" rollbackonanyerror="true">
                            <onerroractions>
                                <action type="unmarkRowsForDeletion" message="There was an error" timeout="3000" model="Account" affectedrows="all"/>
                            </onerroractions>
                            <models>
                                <model>Account</model>
                            </models>
                        </action>
                    </actions>
                </action>
                <action type="multi" label="Cancel" icon="sk-icon-cancel">
                    <actions>
                        <action type="cancel">
                            <models>
                                <model>Account</model>
                            </models>
                        </action>
                    </actions>
                </action>
            </actions>
        </pagetitle>
        <skootable showconditions="true" showsavecancel="false" searchmethod="server" searchbox="false" showexportbuttons="false" pagesize="10" createrecords="true" model="Account" mode="edit" uniqueid="sk-3k7qR-111" emptysearchbehavior="query">
            <fields>
                <field id="Name" allowordering="true"/>
                <field id="CreatedDate" allowordering="true"/>
            </fields>
            <rowactions>
                <action type="delete"/>
                <action type="multi" label="Delete With Save" icon="fa-stop">
                    <actions>
                        <action type="markRowsForDeletion" model="Account"/>
                        <action type="save" rollbackonanyerror="true">
                            <models>
                                <model>Account</model>
                            </models>
                            <onerroractions>
                                <action type="unmarkRowsForDeletion" message="There was an error" timeout="3000"/>
                            </onerroractions>
                        </action>
                    </actions>
                </action>
            </rowactions>
            <massactions usefirstitemasdefault="true"/>
            <views>
                <view type="standard"/>
            </views>
            <searchfields/>
        </skootable>
    </components>
    <resources>
        <labels/>
        <css/>
        <javascript/>
    </resources>
    <styles>
        <styleitem type="background" bgtype="none"/>
    </styles>
</skuidpage>
2

Barry,

I see what you’re talking about with an in-place upgrade of the page not working on the first try. However, when I click on mark rows for deletion and unmark rows for deletion in your row action (without actually changing anything), the pagebuilder fixes itself, so to speak. The pagebuilder save is enabled, and if I save and then preview, the page works as expected. I think behind the scenes the new properties are being added to the XML. Do you see this behavior?

I can see how it can be confusing for the Model property being required when you choose rows in context, so I’ll pass on that suggestion to the devs.

Thanks!
Amy

3

Hi Amy -

Thanks for looking in to this.

If I’m understanding what you did, you opened the page in the builder, selected the “Delete with Save” row action, then toggled the value for “Action Type” to “Mark Row(s) for deletion” and then back to “Unmark row(s) for deletion” and then clicked save, correct?

Assuming yes, then yes, this does ensure that the Model property value gets written to the XML and has the same effect that I described above where I mentioned changing the “Rows to Use” to “All Rows in model” then back to “Rows in context” then clicking save resolves the issue.

With that said, we’re still left with in-place upgrade not working and more importantly, a model property required when context is used.  Going back to the discussions from the previous post on this topic, requiring a model for a context based operation just does not make sense and it was agreed that requiring it was a defect.  

Possibly there is a reason the Model property is required for context based operations that I’m just not thinking of?  Some future use scenario maybe?  If not, then I’d advocate that it be removed when “context” is chosen for “Rows to use”.

Thanks!

4

Ah, sorry Barry, I wasn’t clear enough. I didn’t actually change/toggle the action types, but just clicked on the mark and unmark action to view their details. That’s probably splitting hairs, but I think it’s a little better than having to change the value back and forth. I’m not sure if there is a specific reason why we require the model when we’re doing context, so I’ll bring that up to the team to find out.

Thanks!
Amy

5

Sounds great Amy, appreciate you checking with the team.  Look forward to an update, thank you!

6

Hello Amy - Any updates on this?  Thank you!

7

Barry,

I finally talked to the team about this. They agree that it would be good to hide a model selection when you choose context, but it will probably be a bit before that gets implemented because there are bigger fish to fry, so to speak :) 

8

Thanks for the follow-up Amy, greatly appreciated.  Glad to hear we’re all in agreement, understood regarding priority :slight_smile: