Get Embedded List Row Count with Client Script

[aaron_damyen]

Does anyone have functioning code (Eureka or Fuji or later) for retrieving the current number of rows in an Embedded list with a Client Script?

We would like to perform an onSubmit check to ensure there are an appropriate number of entries in an Embedded list.   Querying the related table does not work because the newly entered rows in the Embedded list are not save until the form is saved.   This also prevents us from performing the change during [Before] Business Rules.   An [After] Business Rule is not appropriate as modifying the record which was just saved is not appropriate use of an [After] Business Rule (according to support), and it has inconsistent behavior.

I know that there is a totalRows and grandTotalRows property on the embedded list object (GlideList2, I think), but it always has the value of when the embedded list was loaded, not the current count.

Another possibility might be to force the saving of the Embedded List before saving the form, but I don't know how to do that either.   The Embedded List documentation doesn't show a save()-type functionality.

Thanks in advance,

Aaron

[aaron_damyen]

Leave it to my testers to find some flaws.   Didn't take into account the ability for users to delete rows.   There's still a table row, but the row will not be saved.   (More exceptions).

This does work for related lists, not just embedded lists.   However, two related lists to the same table will cause issues.   As well, this script does not take into account the number of rows you cannot see, thus making this limited to 0 to List Page Size.   The total number of rows is not calculated.

Pretty good for not having access to the data model.   Works is Eureka, but not tested yet in Fuji.

function getCount(embeddedListTableName) {

   var elements = $$('[record_class='+ embeddedListTableName + ']:not(.list_add):not(.list_delete)');

   return elements.length;

}

[aaron_damyen · Accepted solution]

Addendum.   We've recently upgraded to Fuji patch 3 and found a bug with this particular implementation.

There is what appears to be a bug in that the first row entered into an embedded list will still have a class of 'list_add'.   The second entry, however, will not.   Our users needed to enter one additional entry in order for the check to finally pass.

I suspect this is not appropriate behavior, but since this is outside of supportable functionality, it probably won't get fixed.

My amended version of the script follows.   This version counts up the number of 'list_add' rows and subtracts this value minus 1 from the overall total.   Basically, allowing for only one 'list_add' to be removed from the count.   This intent for this rather cryptic implementation was to handle a situation where additional 'list_add' rows are improperly updated.   (If the bug happens once, why not twice?)   This implementation will also work properly when the previous functionality is restored.

function getCount(embeddedListTableName) {

   // bug in platform.   list_add remains on first row entered

   var listadds = $$('[record_class='+ embeddedListTableName + ']:not(.list_delete)');

   var additional = 0;

   if(listadds.length > 1) {

   // subtract off the one empty listadd row

   additional = listadds.length - 1;

   }

   var elements = $$('[record_class='+ embeddedListTableName + ']:not(.list_add):not(.list_delete)');

   return elements.length + additional;

}