GetSelectionMembersArchiveRows return wrong members-count

We experience the same thing using the API in addition to CRM Script.

To add on a little, if we update the members through the selection UI (the refresh button in the bottom right) our CRMScript actually updates (Not until we update the selection though), but the API is still returning the wrong members. This could be caused by the user running the CRMScript being the same user that refreshed the list, while we use a system user to communicate with the API.

Hi Kasper,

The SelectionAgent doesn't use the same search logic as the New Selection/Find function in the UI. The new stuff uses the Find Selection API, which could explain the difference you are observing.

It looks like there has been some changes to 10.1.6 which breaks the SelectionAgent class. 

I don't have a overview of how many solutions use this class, but it can be critical if it just stops working without any warnings. 

There has not been any logic changes in the SelectionAgent in many months. The last changes were to for the v9.2 release to adapt to GetSeletionMembersArchiveRows  to use the new Find/Selection APIs, and therefore should give you the same results you see inside the SuperOffice Selection page.

Hi Tony. 

It is still weird, because this has worked flawlessly until 28/09/2022 for the customer. If not the selectionAgent, then something else must have changed.

Using the ArchiveAgent I'm still not sure how to get either a member count, or a list of members from a selection with a given selectionId.  I have read the article you have linked to. Maybe I don't understand it, but it only gives an example of how to create a selection without any criterias.

Sample code to retrieve selection archive rows based on the new find system (so by using the specific archive provider):

#setLanguageLevel 3;
NSSelectionAgent selectionAgent;
NSArchiveAgent archiveAgent;

Integer selectionId = 144;

// retrieve selection entity to retrieve the corrent provider name and entity name
NSSelectionEntity selectionEntity = selectionAgent.GetSelectionEntity(selectionId);

NSArchiveRestrictionInfo[] restrictions;

// restrict on the selection id of the selection we want to get the members of
NSArchiveRestrictionInfo selectionRestriction;
selectionRestriction.SetName("selectionId");
selectionRestriction.SetOperator("Equals");
selectionRestriction.SetValues(String(selectionId.toString()).split(",")); 
restrictions.pushBack(selectionRestriction);

// no specific order specified
NSArchiveOrderByInfo[] order;

// specifiy the main selection entity
String[] entities = String(selectionEntity.GetTargetTableName().toLower()).split(",");

if (selectionEntity.GetTargetTableName().equalsIgnoreCase("contact"))
{
  	entities.pushBack("person");
}

NSArchiveListItem[] rows = archiveAgent.GetArchiveListByColumns(selectionEntity.GetMainProviderName(), String("appointmentId").split(","), order, restrictions, entities, 0, 2147483647);

print(rows.length().toString());

Would it not be better for backwards compativility to change the implementation of the GetSelectionMembersArchiveRows to use the correct archive provider in the background?

If it is indeed for persons, then the logic that GetSelectionMembersArchiveRows is nearly identical to the code David has shared. So, if you have any more details you would like to share in attempt to recreate this behavior, by all means share it.