Skip to main content

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


  1. 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)


  1. Move “Edit Row Action” to top of list

  2. Click “Save” button

  3. 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)


  1. Go back to builder

  2. Add new row action

  3. Move “Edit Row action” to top

  4. Click “Save” button

  5. 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">
<fields>
<field id="Id"/>
<field id="Name"/>
</fields>
<conditions/>
<actions/>
</model>
</models>
<components>
<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">
<fields>
<field id="Name" uniqueid="fi-13mZC8-97" valuehalign="" type=""/>
</fields>
<rowactions>
<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"/>
</rowactions>
<massactions usefirstitemasdefault="true"/>
<views>
<view type="standard"/>
</views>
</skootable>
</components>
<resources>
<labels/>
<javascript/>
<css/>
</resources>
<styles>
<styleitem type="background" bgtype="none"/>
</styles>
</skuidpage>

Barry,

Sorry this wasn’t resolved as we thought, and thanks for giving these helpful details! The developers are now aware of it and we’ll let you know when a future release fixes this issue.

Thanks!
Amy


Thank you Amy!


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.


Tested and confirmed as resolved as of 10.0.9. Thank you!


Reply