Table row action changes not detected as a change in builder and not persisted when forced to save page

  • 2
  • Problem
  • Updated 2 years ago
  • Solved
In the Brooklyn release, the issue Table row action order not respected was indicated as resolved.  Unfortunately, while improvements were made, there are still issues with table row actions.

Pieces Resolved
1) You can now drag "Edit" and "Delete" from the row action area and order them without the entire table moving
2) The order of the actions in the XML will be respected when the page is displayed

Remaining Issues
1) Changes to the order of the action from within the builder are not detected as "changes" and "Save" button is not enabled
2) After changing the order and then changing something else on the page to force "Save" to become enabled, the new order is not persisted to the XML
3) Adding a new row action and changing existing order and then clicking "Save" only persists the new row, it does not persist the change in order to the other actions.

Steps to reproduce
1) Create page using XML below
2) Move "Edit Row Action" to the top of the list

Expected Behavior
"Save" is enabled

Actual Behavior
"Save" is not enabled

3) Add "Account Id" to a field on the table

Expected Behavior
"Save" enabled and "Edit Row Action" still at top

Actual Behavior
"Edit Row Action" is back to 4th item in list (it's original position)

4) Move "Edit Row Action" to top of list
5) Click "Save" button
6) View/Edit XML of page

Expected Behavior
"Edit Row Action" is at the top of action list

Actual Behavior
"Edit Row Action" is the 4th item in the list (it's original position)

7) Go back to builder
8) Add new row action
9) Move "Edit Row action" to top
10) Click "Save" button
11) View/Edit XML of page

Expected Behavior
"Edit Row Action" is at the top

Actual Behavior
"Edit Row Action" is the 4th item in the list (it's original position)

Sample Page XML
<skuidpage unsavedchangeswarning="yes" personalizationmode="server" showsidebar="true" showheader="true">    <models>
        <model id="Account" limit="20" query="true" createrowifnonefound="false" adapter="salesforce" type="" sobject="Account">
                <field id="Id"/>
                <field id="Name"/>
        <skootable showconditions="true" showsavecancel="true" showerrorsinline="true" searchmethod="server" searchbox="true" showexportbuttons="false" pagesize="10" createrecords="true" model="Account" buttonposition="" mode="read" uniqueid="sk-2oQrWg-122">
                <field id="Name" uniqueid="fi-13mZC8-97" valuehalign="" type=""/>
                <action type="multi" label="Number 1" icon="fa-arrow-up"/>
                <action type="multi" label="Number 2" icon="sk-icon-arrow-left"/>
                <action type="multi" label="Number 3" icon="sk-icon-arrow-right"/>
                <action type="edit"/>
                <action type="drawer" label="Drawer" icon="fa-arrow-down"/>
                <action type="delete"/>
            <massactions usefirstitemasdefault="true"/>
                <view type="standard"/>
        <styleitem type="background" bgtype="none"/>
Photo of Barry Schnell

Barry Schnell, Champion

  • 18,376 Points 10k badge 2x thumb

Posted 3 years ago

  • 2
Photo of Stephen Sells

Stephen Sells, Alum

  • 17,326 Points 10k badge 2x thumb
Official Response
Hello Skuid Community ~

This is now fixed in the new Brooklyn (10.0.9) and Brooklyn (9.5.16) release which is now available on the Skuid Releases page.

As a reminder, Salesforce does NOT allow reverting back to prior versions of managed packages. Skuid always recommends installing new versions in a non-business critical sandbox environment to test all mission critical functionality before installing into a production environment. We also recommend that you update out of date themes when you upgrade.