Skip to content
This repository has been archived by the owner on Jul 31, 2021. It is now read-only.

Library support for leaving enabled_clients on connections unchanged #125

Open
emsearcy opened this issue Feb 18, 2021 · 2 comments
Open

Comments

@emsearcy
Copy link

Opening to increase visibility of auth0/auth0-deploy-cli#207, after I spent a few hours trying to solve this before I stumbled on that.

Expected behavior (as somebody who's been using auth0-deploy-cli for years): deploying connection attributes (such as from a json file in auth-deploy-cli), without an enabled_clients attribute would act the same as the PATCH behavior (no change to enabled clients)

Actual behavior: all clients are disabled

#86 was closed/rejected as changing the default behavior, which still leaves users with no solution...

  • Handling enabled_clients differently between databases and connections is confusing
  • By implicitly assuming "enabled_clients: []" in the passed attributes for connections, the library acts differently than corresponding raw PATCH behavior for just this resource ... which is confusing
  • There is no possible way to deploy connections through this library and leave the enabled_clients parameter unchanged
  • Why somebody would have a connection with no clients in the first place I don't really understand, but at the very least, there are ways to address rolling out a change like this, such as outputting warnings that the behavior will change in an upcoming major version release, supporting a flag to opt in to that behavior early, etc. And it's not like changing from an implicit [] to "no change" would actually change anything, as though it would enable connections immediately (maybe some people are relying on it to disable connections enabled when using the tenant setting "Enable Application Connections" ... but again, this assumes that they had it set up as a connection with no clients—if it had clients, it would be an explicit attribute already...
@stale
Copy link

stale bot commented Jun 11, 2021

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

@stale stale bot added the wontfix label Jun 11, 2021
@emsearcy
Copy link
Author

Yeah, this is still a significant problem. The fix was already contributed in #86, so let me juts petition that the maintainers reverse their decision and accept that PR and deal with the (minor!) breaking change it introduces through documentation and release notes.

@stale stale bot removed the wontfix label Jun 22, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant