(In reply to comment #0)

I'm not sure why the "allowed on wiki" all or one setup exists (i.e., I don't
know the rationale for the original design decision), so opening a bug for
further consideration.

The architecture decision was made to allow the grants to apply to a single wiki, or all wikis in the cluster, since we anticipate that some applications will want to interact with all wikis, while some users will want to limit the scope of the authorization to a single wiki (I wouldn't want a random website that purports to upload images to commons to also have upload rights to enwiki).

So we want both the OAuth developer (on Special:MWOAuthConsumerRegistration/propose) and the end user (on Special:MWOAuthManageMyGrants/manage/) to specify a single wiki or all wikis. The "*" is just the database representation, so we carried it over.

(In reply to comment #1)

The architecture decision was made to allow the grants to apply to a single
wiki, or all wikis in the cluster, since we anticipate that some applications
will want to interact with all wikis, while some users will want to limit the
scope of the authorization to a single wiki (I wouldn't want a random website
that purports to upload images to commons to also have upload rights to
enwiki).

Okay, if we're moving forward with an all or one model, perhaps a drop-down menu would be best here. The issue is that there are a lot of Wikimedia wikis (over 700, I believe), so a drop-down menu quickly becomes painful to scroll through. If we already know who the user is, though, I wonder if we can't sort a menu by number of edits that the user has. For example, for my account, this would be:

Allowed on wiki:

• [all]
• en.wikipedia.org
• meta.wikimedia.org
• commons.wikimedia.org
• [other]

And selecting [other] might then present a text input as a last resort.

I'm still of the belief that using a text input here is a bad idea and should be avoided. There are other (JavaScript-based) solutions we can explore as well.

Created attachment 13513
ManageMyGrants (User-facing)

Attached:

Created attachment 13514
ConsumerRegistration (developers)

Attached:

Here's what I think could work, we could surface the most selected Wiki when user tries to search for "Wiki" and then mention "There are 790 others results of "Wiki", add more search term to filter the results." And we keep doing that if there are more than 10 search suggestions. If they insist to look at the list of 790 Ids, we'll think of listing them alphabetically or by subject content, etc.

What I'm unsure is how experienced this type of user can be. Do they need help in searching Wikis? If that's the case we will have a different execution for that type of user. But if user is experienced enough to navigate to that page and want to add Wiki project IDs and have a rough idea what to search for, my suggestion could be sufficient.

What do you guys think?

(In reply to comment #5)

Here's what I think could work, we could surface the most selected Wiki when
user tries to search for "Wiki" and then mention "There are 790 others
results of "Wiki", add more search term to filter the results." And we keep
doing that if there are more than 10 search suggestions. If they insist to
look at the list of 790 Ids, we'll think of listing them alphabetically or by
subject content, etc.

I think adding search functionality is a lot to do for this.

What about a drop-down menu that's similar to:

Allow on:

• Current wiki (<name of wiki>)
• All Wikimedia wikis
• Specific Wikimedia wiki... ---

Where selecting the third option ("Specific Wikimedia wiki...") exposes either a full drop-down menu listing every wiki or the text input.

If we go with the text input, we can add some helper auto-complete JavaScript to make it easier to find the specific wiki. Thought at a minimum we need to either eliminate the use of database names or add domain names as secondary lookup keys.

Thoughts?

That sounds like a great idea. Like I said, I'm unfamiliar with the types of users who make these changes or the kind of different use cases for it. We can even add

• All Wikimedia wikis except for ..."

if that's helpful. I'd agree we pull out the large list only when we must.

I'd strongly like to use domains as an alternate form of input. I originally planned to do that but was derailed by some of the complexity annoyances (wgConf,wmf specific stuff). It can do some host->dbname conversions like getDBName() in MassMessage does under the hood.

(In reply to comment #6)

Where selecting the third option ("Specific Wikimedia wiki...") exposes
either
a full drop-down menu listing every wiki or the text input.

Displaying a list with checkboxes would probably be better than a drop-down box, although some might say its uglier.

(In reply to comment #8)

I'd strongly like to use domains as an alternate form of input.

This is bug 55703. :-)

Re comments 7 & 9, we only allow one value (a single wiki, or "*" representing all wikis).

I agree with Aaron, domain names are probably best.

Doing the dropdown with a second list (dropdown or text) in javascript would be an easy start to mock up. I'll try and get that done this week, unless someone else beats me to it.

Created attachment 13537
Add dropdowns for wiki selction

If you run the javascript from this file on the preferences page, it will update the wiki select to a drop down with "All wikis", "Current Wiki", and "Another wiki". The last option will add a text box that lets you type in the dbname or domain name of the wiki you want to grant access to.

Code is ugly and would be integrated into the extension in a nice way. So,

• This is just a mock-up to make sure the UX is ok **

Attached:

[[testwiki:Special:MWOAuthManageMyGrants/manage/72]] smartly disables per-user JavaScript, but I put the code at [[testwiki:User:MZMcBride/bug55714.js]] so that I could run "importScript('User:MZMcBride/bug55714.js');" from the Chrome developer console and not get "mixing insecure content" warnings.

I think the drop-down menu is a substantial improvement. The drop-down menu, combined with some kind of auto-complete for the database or domain name text input, should make wiki selection vastly easier. :-)

Actually this input won't even exist with https://gerrit.wikimedia.org/r/#/c/91488/

Aaron, it will on the consumer proposal screen still. But since only developers are looking at that, it's definitely lower priority.

I've got a javascript and minimal backend support patch almost done, so I should be able to get that in today.

(In reply to comment #15)

Aaron, it will on the consumer proposal screen still.

Right, but that is not "allowed on wiki" it's "applicable wiki". With that patch merged I don't see a reason to keep this bug open, since bug 55703 already exists.

(In reply to comment #16)

(In reply to comment #15)

Aaron, it will on the consumer proposal screen still.

Right, but that is not "allowed on wiki" it's "applicable wiki". With that
patch merged I don't see a reason to keep this bug open, since bug 55703
already exists.

Ah, good point. Yeah, we'll track the /propose issue there.