Flag `--no-max` doesn't work as expected
When listing members of an organization, the flag --no-max has the opposite effect of what was expected: it shows fewer records instead of showing all of them. Just 10 records, specifically. The organization currently has 24 members (which is what is shown without the --no-max flag).
Example below (details redacted):
$ tw members list -o=NGI
Members for NGI organization:
ID | Username | Email | Role
-----------------+-------------------+---------------------------------+--------
xxxxxxxxxxxxxxx | xxxxx | [email protected] | OWNER
xxxxxxxxxxxxxxx | xxxxxx-xxxxxxxxx | [email protected] | MEMBER
xxxxxxxxxxxxxxx | xxxxxxxxxxx | [email protected] | MEMBER
xxxxxxxxxxxxxxx | xxxxx-xxxx | [email protected] | MEMBER
xxxxxxxxxxxxxxx | xxxxx-xxxxxxxx | [email protected] | MEMBER
xxxxxxxxxxxxxxx | xxxx-xxxxxxxxx | [email protected] | MEMBER
xxxxxxxxxxxxxx | xxxxyxxxx-xxxx | [email protected] | MEMBER
xxxxxxxxxxxxxxx | xxxxx | [email protected] | OWNER
xxxxxxxxxxxxxxx | xxxxy-xxxxxxxx | [email protected] | MEMBER
xxxxxxxxxxxxxxx | xxxxzxxxx-xxxxxx | [email protected] | MEMBER
xxxxxxxxxxxxxxx | xxxxxx | [email protected] | MEMBER
xxxxxxxxxxxxxxx | xxxxx-xxxxxxx | [email protected] | OWNER
xxxxxxxxxxxxxx | xxxxxxxx-xxxxxxxx | [email protected] | OWNER
xxxxxxxxxxxxxxx | xxx-xxxx | [email protected] | MEMBER
xxxxxxxxxxxxxxx | xxxxxx-xxxxxxx | [email protected] | MEMBER
xxxxxxxxxxxxxxx | xxxxxxx-xxxxx | [email protected] | OWNER
xxxxxxxxxxxxxx | xxxxxxx-xxxxxxxx | [email protected] | MEMBER
xxxxxxxxxxxxxxx | xxxxxx-xxxxxx | [email protected] | MEMBER
xxxxxxxxxxxxx | xxxxxxx-xxxxxxxxx | [email protected] | MEMBER
xxxxxxxxxxxxxx | xxx-xxxxxx | [email protected] | OWNER
xxxxxxxxxxxxxx | xxxxxx-xxxxxxx | [email protected] | OWNER
xxxxxxxxxxxxxxx | xxxx-xxxxx-xxxxx | [email protected] | OWNER
xxxxxxxxxxxxxx | xxxx-xxxxxxxx | [email protected] | MEMBER
xxxxxxxxxxxxxxx | xxxxxxx-xxxxx | [email protected] | OWNER
$ tw members list -o=NGI --no-max
Members for NGI organization:
ID | Username | Email | Role
-----------------+------------------+--------------------------------+--------
xxxxxxxxxxxxxxx | xxxxx | [email protected] | OWNER
xxxxxxxxxxxxxxx | xxxxxx-xxxxxxxxx | [email protected] | MEMBER
xxxxxxxxxxxxxxx | xxxxxxxxxxx | [email protected] | MEMBER
xxxxxxxxxxxxxxx | xxxxx-xxxx | [email protected] | MEMBER
xxxxxxxxxxxxxxx | xxxxx-xxxxxxxx | [email protected] | MEMBER
xxxxxxxxxxxxxxx | xxxx-xxxxxxxxx | [email protected] | MEMBER
xxxxxxxxxxxxxx | xxxxyxxxx-xxxx | [email protected] | MEMBER
xxxxxxxxxxxxxxx | xxxxx | [email protected] | OWNER
xxxxxxxxxxxxxxx | xxxxy-xxxxxxxx | [email protected] | MEMBER
xxxxxxxxxxxxxxx | xxxxzxxxx-xxxxxx | [email protected] | MEMBER
Environment details:
$ tw info
Details
-------------------------+-------------------------------------
Tower API endpoint | https://ngi-tower.scilifelab.se/api
Tower API version | 1.9.0
Tower version | 22.1.0-beta.0
CLI version | 0.5.1 (d91474a)
CLI minimum API version | 1.7
Authenticated user | ewels
System health status
---------------------------------------+----
Remote API server connection check | OK
Tower API version check | OK
Authentication API credential's token | OK
This is somehow a bug or a missing feature problem. Let me explain.
After a change at Tower API it is not possible to return all the records in a single API request, you need to do several requests with different offsets. Current implementation to use --no-max means to do not set the max at the API request, but now if you don't set the max the API will always set it to 10. The maximum allowed value for max by default is 100 (this is configurable using the tower.member.list.max-allowed property at Tower backend side).
So now if we want to allow a --no-max flag we need to implement the pagination at CLI side doing the multiple requests. This will take some time, so for the next release 0.6 I'm just going to remove the --no-max option because it is not working as expected. And I'm going to leave this issue open to support pagination at CLI side in a near future.