feat: adds create support for users

[tdstein]

I'm torn between a few different approaches to solve this problem.

My primary goal is to eliminate the consumer's need to understand which authentication implementation their Connect server is using.

Option 1

A simple way to do this (the current implementation) is to key off the provided parameters. If the consumer provides a "prefix", we assume the "remote" flow. Otherwise, do the normal POST flow.

Option 2

However, I think the better option is to abstract this further and define an interface that provides a better user experience. One that does not require the consumer to know all of our implementation's quirks.

e.g.,

@overload
def create(self, email: str = ..., username: str = ..., password: str = ...) -> User:
    ...

We can utilize the @overload capabilities to guide users towards the correct set of parameters. For example, if the password isn't supplied, then we should set user_must_set_password=True during POST /v1/users.

e.g.,

@overload
def create(self, email: str = ..., username: str = ...) -> User:
    ...

Option 3

Another option is to force the user to know their Connect instances auth implementation and have them specify the type. Then, we can key the auth flow and client side assertions based on the provided auth type.

e.g.,

def create(self, provider: str, *args, **kwargs) -> User:
      match provider:
            case "ldap":
                # remote flow
                pass
            case "pam":
                # normal flow
                pass
            case _:
                raise ValueError()

[github-actions]

☂️ Python Coverage

current status: ✅

Overall Coverage

Lines	Covered	Coverage	Threshold	Status
547	473	86%	80%	🟢

New Files

No new covered files...

Modified Files

File	Coverage	Status
src/posit/connect/users.py	100%	🟢
TOTAL	100%	🟢

updated for commit: 966f04c by action🐍

[tdstein]

@mmarchetti / @nealrichardson / @jonkeane - see the description and let me know your thoughts on how to proceed. Additional ideas are also appreciated 😄

[mmarchetti]

I like the idea of two separate create methods (say, create and create_from_remote to address the two cases. The other caveats in the doc (you need to be an admin to do X, sometimes you don't need an API key, etc) can be delegated to Connect and you'll get a 401/403 if you get it wrong.

[nealrichardson]

I like the idea of two separate create methods (say, create and create_from_remote to address the two cases. The other caveats in the doc (you need to be an admin to do X, sometimes you don't need an API key, etc) can be delegated to Connect and you'll get a 401/403 if you get it wrong.

That sounds like a reasonable position, at least to start. We can always revisit once people actually are using this.