497419 - API: Handle duplicate name collections

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Collections, defect)

Description

[Brian King [:kinger]]

This is a breakout from bug 496625. 

Seems like the API does not handle the creation of duplicate collection names very well.

<error reason="invalid_parameters" details="nickname"/>

Some solutions:

1) improve error message to inform user that the name might already be taken.

2) Add a nickname field. The nickname is taken from the collection name. The
nickname has to be unique, not the collection name.

3) If the API call fails with this message, we could try auto-generating a
nickname, e.g. "superman3452"

Comment 1

[Les Orchard [:lorchard]]

I'm not sure what the fix is here - are you saying the API should auto-generate random nicknames?  The other points sound like extension features.

Comment 2

[Brian King [:kinger]]

Yes, #2 is about allowing dupe names, and having a unique nick generated by the API.

#1 is the quick fix. However, that error message looks generic. Can you guarantee the same error won't be returned for something else?

#3 is a lot of work and would require more UI and strings.

Comment 3

[Les Orchard [:lorchard]]

Hmm, that error will be the response if the nickname has invalid characters or is taken already, same as the form on the website.  The form there does offer a "check availability" button, but it's not automatic.

Comment 4

[Les Orchard [:lorchard]]

You could also not set a nickname, in which case the UUID is used in the URL. The web UI does this, also, when initially creating a collection

Comment 5

[Justin Scott [:fligtar]]

Let's have the API only set a nickname if it is free. If the nickname is not free, it won't have one and the user will have to manually set it later.

Comment 6

[Les Orchard [:lorchard]]

So... if a nickname is supplied to the API, and the nickname is taken, it shouldn't raise an error and just ignore the nickname parameter?

Comment 7

[Justin Scott [:fligtar]]

Yeah, nickname will be optional for the API. You can raise a warning or notice of some sort, but it shouldn't be fatal.

Comment 8

[krupa raj[:krupa]]

I am unable to create an auto-publisher with the name-0
I see the error message-"The collection could not be created(an internal error occurred)".Is this due to the same reason? If not..I can file a new bug.Thanks.

Comment 9

[Les Orchard [:lorchard]]

Well, the nickname parameter is already optional.  This sounds like the API should check if a nickname is taken, and if so, ignore the parameter.  That seems kind of weird for an API to presume to do.

I can think about adding warnings/notices in general to API responses - but I'd rather add a resource to check availability on nicknames, in case the extension lets users supply nicknames at some point and wants to provide availability feedback like the web UI does.

Comment 10

[Justin Scott [:fligtar]]

The way the UI is presented in the extension, the user doesn't even know they are creating a nickname. They just enter a name for the collection, and the extension converts that to a nickname by removing spaces and some other things.

So if the collection isn't given a nickname, they won't notice because they didn't request it.

Comment 11

[Les Orchard [:lorchard]]

Okay... so that sounds like the extension needs a field for nickname or to not auto-generate one, since that's all happening without the user's knowledge or request.

Comment 12

[Justin Scott [:fligtar]]

Yeah, I'm fine with not making nicknames by default for auto-publishers. Can we remove that from the extension?

Comment 13

[David McNamara [:mackers]]

(In reply to comment #12)
> Yeah, I'm fine with not making nicknames by default for auto-publishers. Can we
> remove that from the extension?

Ok. Now the extension will not autogenerate a nickname. It omits it from the API request altogether.

This should resolve the issues with duplicate nicknames.

r27647