feat: add oauth-consumers command

[davlgd]

This pull request introduces a new oauth-consumers command group to the Clever Cloud CLI, allowing users to manage OAuth consumers directly from the command line. It adds full CRUD support (create, read, update, delete), listing, and browser opening functionalities for OAuth consumers, along with comprehensive documentation and argument parsing utilities.

The most important changes are:

New OAuth Consumers Command Group:

• Added the oauth-consumers command group with subcommands for creating, deleting, retrieving, listing, opening, and updating OAuth consumers, including support for specifying organisation, output format, and rights. [1] [2] [3] [4] [5] [6]

Argument and Rights Handling:

• Implemented argument resolution utilities for handling consumer key/name ambiguity and rights parsing/mapping, ensuring robust user input validation and error messaging. create and ``update` subcommands are managed interactively, user can also pass values through options.

Documentation Updates:

• Added detailed documentation for the new oauth-consumers command group and its subcommands, including usage examples, options, and arguments in both the main documentation and dedicated command reference files. [1] [2] [3]

[github-actions]

🔎 A preview has been automatically published!

If you created the alias to the preview script, you can run this command to download and install this preview:

clever-preview update davlgd-consumer

You can also run it from your local repository:

./scripts/preview.js update davlgd-consumer

OS	SHA256 checksum
🐧 linux	e20b1ec0fec7fcc8e211f881a21f448602f4a2641e3e0b0cb488c5e5502943ff
🍏 macos	62588b88f61e84fe34a988f89d7881698181f6fb3eec7e6b46c9729e024e7339

This preview will be deleted once this PR is closed.

[hsablonniere]

Thanks @davlgd, I did a UX review, I'll do a code review after, once we agree (or not 😛) on the following points.

list

In commands for operators or specific add-ons like config-provider, the list displays all items across all organisations. I think we should do the same. It can be done with the summary. This would also fix the weird indentation for the items with dots.

create (and update)

I wonder if the name should be an option instead of an arg (like for update) and it could even be part of the interactif stuffs. WDYT?

At first, I was like "why are all these options optional?" but now I get it, not specified means interactive mode. It will be nice to have something more declarative for this in our future CLI framework 😉

• The --with-secret is nice
• I like the update with interactive mode

I was wondering if we could have access and manage as jokers but all is clearly enough for such a low usage feature.

get/delete/update

I think the org should be removed, we can rely on the key (and use the summary, like I suggested for the list).

other

I noticed the config-provider has some display differences with how operators are listed. I created an issue. Maybe this PR can address this in a dedicated commit and then reuse the helper to format the list for OAuth consumers.

[davlgd]

Thanks for the thorough UX review! I've pushed new commits to fix issues, some related to your comment.

Here are my thoughts on each point:

In commands for operators or specific add-ons like config-provider, the list displays all items across all organisations. I think we should do the same. It can be done with the summary. This would also fix the weird indentation for the items with dots.

Agreed, I've aligned with the config-provider/operators pattern: list across all orgs, grouped by owner with the summary format.

I wonder if the name should be an option instead of an arg (like for update) and it could even be part of the interactif stuffs. WDYT?

I'd prefer keeping name as a positional arg. Every create command in clever-tools (addon, drain, ng, k8s, tokens…) uses the primary identifier as a positional arg — I'd rather stay consistent with that established pattern.

The difference with update is intentional: in create you name, in update you optionally rename, hence arg vs option.

I think the org should be removed, we can rely on the key (and use the summary, like I suggested for the list).

Makes sense, the consumer key is unique so --org is redundant for get/delete/update. I've resolved the owner internally from the summary instead.

I noticed the config-provider has some display differences with how operators are listed. I created an issue. Maybe this PR can address this in a dedicated commit and then reuse the helper to format the list for OAuth consumers.

Good idea, I've added a dedicated commit to extract a shared list formatting helper and reuse it for oauth-consumers. That way we address #1079 and keep the list display consistent.

[hsablonniere]

Thanks for your feedbacks @davlgd

I'd prefer keeping name as a positional arg...

Agreed, I'll do the code review soon.