Public bug reported: 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 /lists/test@example.com?page=1&count=10 will return all lists within the range [:10] from the database. If there are x unadvertised lists 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 in the WHERE clause of the database query. In this case: GET /lists/test@example.com?page=1&count=10&advertised=(0|1|2) 0 - only non-advertised 1 - only advertised 2 - both ** Affects: mailman Importance: Undecided Status: New ** Tags: mailman3 rest ** Description changed: 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 /lists/test@example.com?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 + a number of common filter params which are used in the WHERE clause of the database query. In this case: GET /lists/test@example.com?page=1&count=10&advertised=(0|1|2) 0 - only non-advertised 1 - only advertised 2 - both ** Description changed: 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 /lists/test@example.com?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 + are x unadvertised lists 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 in the WHERE clause of the database query. In this case: GET /lists/test@example.com?page=1&count=10&advertised=(0|1|2) 0 - only non-advertised 1 - only advertised 2 - both -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1190582 Title: Add some common filters to REST API resources that expose collections To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1190582/+subscriptions