When Postorius GETs a collection of lists from the REST API, it will in most situations only use a subset (the ones that are set to "advertise in list index"). This is a minor issue as long as the request isn't paginated, but can lead to incorrect item counts when it is.
Example:
GET /<email address hidden>?page=1&count=10
will return all lists within the range [:10] from the database. If there are x unadvertised list in the result, the page will only show 10 - x results.
I guess the most common way to solve this is for the REST API to accept a number of common filter params which are used for the WHERE clause of the database query. In this case:
GET /<email address hidden>?page=1&count=10&advertised=(0|1|2)
0 - only non-advertised
1 - only advertised
2 - both
When Postorius GETs a collection of lists from the REST API, it will in most situations only use a subset (the ones that are set to "advertise in list index"). This is a minor issue as long as the request isn't paginated, but can lead to incorrect item counts when it is.
Example:
GET /<email address hidden> ?page=1& count=10
will return all lists within the range [:10] from the database. If there are x unadvertised list in the result, the page will only show 10 - x results.
I guess the most common way to solve this is for the REST API to accept a number of common filter params which are used for the WHERE clause of the database query. In this case:
GET /<email address hidden> ?page=1& count=10& advertised= (0|1|2)
0 - only non-advertised
1 - only advertised
2 - both