User modify API requires a redesign about synadm

[JacksonChen666]

(re)implementation ideas:

• accept dict/json instead?
• accept value on if something is set (that's not so nice to work with)
• define a value is considered undefined and check for that (None can't be used, nor False or True or maybe even arbitrary strings, probably should be a special type)

(i previously put it into #90, the wrong place. sorry!)

[JOJ0]

You could change the initial report here: user-type works now :-) (not the most beautiful solution, but works now at least ;-)

[JOJ0]

Ok so before we continuie with refactoring ideas here I'd like to state one design idea that I think kind of was with 'synadm' from when I started coding it. I wanted api methods to be able to work as closely as the api docs describe them as possible. I wanted api methods to support everything that the api supports or at least stay close to that.

For example: When the docs say that it's possible to "omit" a json text from the post data, the api method should be able to do that as well.

If we take the api in question, let's have a look, we see that a lot of the parts of the json are marked as "optional". In that case leaving them out entirely from the post dasta would mean "leave that setting untouched": https://matrix-org.github.io/synapse/latest/admin_api/user_admin_api.html#create-or-modify-account

With that in mind, let's start to collect ideas.

The first thing that comes up is a simple one and would improve the "falsy" problem: Change all the exclusion conditions to use if not None. eg:

        if avatar_url is not None:
            data.update({"avatar_url": avatar_url})

[JOJ0]

I think with that we would finally fix what I was aiming for in the first place:

• define a value is considered undefined and check for that (None can't be used, nor False or True or maybe even arbitrary strings, probably should be a special type)

Only I'm wondering what kind of value that could be? Simply a string? Named 'undefined'? Sounds ugly, but actually is the functionality we want :-)

[JOJ0]

Reopening. Was closed because the two bugs that were introduced due to this clumsy design were actually (quick) fixed. Please @JacksonChen666 go ahead with a more robust reimplementation of the user_modify method. Appreciated! My personal opinion is that a "good enough" solution would be to just use is not None for the optionality checks, which would fix the "falsy" problem at least. For further "specialities" like we have with user_type='null' a way simply by working around with strings can be used. Not too bad I think but yeah if you would find something cleaner, sure, go ahead, cleaner is always better :-)

[JacksonChen666]

User modify API redesign

This is not a pull request.

Anyways, implementation ideas welcome (try not repeating what I've already thought about).