API: Handle duplicate name collections



10 years ago
3 years ago


(Reporter: kinger, Assigned: mackers)






10 years ago
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"
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

10 years ago
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.
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.
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
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.
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?
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

10 years ago
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.
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.
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.
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.
Yeah, I'm fine with not making nicknames by default for auto-publishers. Can we remove that from the extension?
Assignee: lorchard → brian


10 years ago
Assignee: brian → dave

Comment 13

10 years ago
(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.

Last Resolved: 10 years ago
Resolution: --- → FIXED


10 years ago
Target Milestone: BW-M6 → BW-1.0.3
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.