REST: creating a user from an existing address

[Aurélien Bompard]

I'm trying to create a User in Mailman 3 from an existing Address. The existing address is currently unlinked and unverified, and I'd like to create a user and link it to it

Here's what Barry suggests :

You might want to create the user and link to it from the existing address resource, i.e. the AnAddress class.

Right now, you cannot get directly from the address to its linked user, if it has one. Look at _AddressBase._resource_as_dict() in addresses.py.

Sketching out an approach:

 - The address resource would gain a `user` key if there is a linked user. This would be a url to the user resource. If the address is unlinked, then there would be no such key.

 - AnAddress would gain a /user sub-resource which would either 404 if the address is unlinked or return the linked user's JSON data.

 - POSTing to /addresses/<email>/user would create a new user and link the address to it, but only if the address is not yet linked. If it's already linked, you'd get a 409 Conflict error. If the new user is created, you'd get 201 Created response.

Additional use cases to consider:

Q. What if the address is already linked and you want to unlink it?
A. DELETE on the /addresses/<email>/user resource

Q. What if you want to change the user the address is linked to?
A. Currently, it's two operations: DELETE the existing link as above, then see below. The other option is to allow a PUT on the /addresses/<email>/user resource.

Q. What if you want to link the unlinked address to an existing user?
A. Maybe allow this in the POST to /addresses/<email>/user, i.e. the user would only be created if it doesn't yet exist. If it gets created, you'd get a 201 Created, but if it's just a link operation to an existing user, you'd get a 200 Success response.

It's possibly you'd want to include POST boolean that specifies whether creating a new user is okay or not, with the appropriate response codes in the false case.

[nicolask (nkarageuzian)]

I faced this problem and worked on it, i share...

Implementation lacks but we could keep and complete tests, as they seems to fit the use case.

Barry's approach is elegant and i beleive it should be available for the next release as it's a gripping point which comes very early in user experience (the reason of my hack, from the feedbacks of a demo I organized)

[Aurélien Bompard (abompard)]

Hey Nicolas ,
Now that the REST API has been ported to Falcon, your branch does not merge. Are you OK if I port it to Falcon and finish Barry's suggestions, or would you rather do it yourself?

[nicolask (nkarageuzian)]

On 05/12/2014 11:20, Aurélien Bompard wrote:
> Hey Nicolas ,
> Now that the REST API has been ported to Falcon, your branch does not merge. Are you OK if I port it to Falcon and finish Barry's suggestions, or would you rather do it yourself?
>
Hi Aurelien,

Thank you for asking, if you can get some time for implementing this,
that would be great.
Feel free to port, or throw my code if it's unrevelant.

Best regards

Nicolas