+++ This bug was initially created as a clone of Bug #1558114 +++ Description of problem: We need a way to retrieve the total # of pools for an owner to support paging of upstream/portal subscriptions in the UI. Retrieving the total # by way of minimizing includes is not sufficient (too slow). Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: No such API exists Expected results: There exists an API: GET /owners/{owner_key}/pools/count which returns the total number of pools which respects the current filtering Additional info: GET /owners/:owner_id/consumers/count is a similar API that already exists IT will need the version containing this API to support our work --- Additional comment from Barnaby Court on 2018-03-19 13:43:41 EDT --- After discussions with Brad, it would be acceptable to provide the maximum number of records as metadata when the first page of data is returned. --- Additional comment from Barnaby Court on 2018-03-22 10:55:17 EDT --- Currently we provide a link header that does have some useful information and could be used as a workaround. However, it would be better to include the total # of items as a value. Link: <https://localhost:8443/candlepin/owners/foo/pools?include=id&page=1&per_page=5&include=id&per_page=5&page=2>; rel="next", <https://localhost:8443/candlepin/owners/foo/pools?include=id&page=1&per_page=5&include=id&per_page=5&page=1>; rel="first", <https://localhost:8443/candlepin/owners/foo/pools?include=id&page=1&per_page=5&include=id&per_page=5&page=200>; rel="last" --- Additional comment from Barnaby Court on 2018-03-22 10:59:59 EDT --- A http header of "X-total-count" with the total number of records would be very helpful if paging is used. --- Additional comment from Jonathon Turel on 2018-03-23 10:27:24 EDT --- I looked into using the link header. My approach was using ?page=1&per_page=1 in my query. In theory the last page should be the total number. It was still slow enough to make paging an unpleasant experience when there are many pools. I had about 3k pool and the response was over 3 seconds, so we won't be going that route as a workaround. In addition to the "x-total-count" header, it will be nice to have an "x-subtotal-count" header which reflects the number of results according to any filtering applied. --- Additional comment from Jonathon Turel on 2018-03-23 13:51:24 EDT --- Barnaby, Per our in-person chat I spoke with Walden regarding handling subtotals. He told me that the x-total-count header reflecting the total after filtering applied is fine - so we can forget about adding the subtotal header I proposed.
Back port to 2.2 created.