Thu, Feb 25
At the risk of oversimplifying, it sounds like the tradeoff is that we can make MW faster by default, at the cost of being more difficult to install for some people. Further, it sounds like the people that would experience difficulties installing are exactly the people who are not well equipped to overcome those difficulties. In other words, the suggested change sounds like a showstopper for certain people.
Thu, Feb 18
I find it confusing to mix the two interpretations of "source" in one parameter.
The estimate I assigned (1) assumes that the base implementation of the endpoint without filtering is complete. Adding filtering should be straightforward.
Tue, Feb 9
Thu, Feb 4
Mon, Feb 1
Jan 31 2021
Jan 27 2021
Jan 25 2021
Behavior confirmed locally. Created an owner-only client via the special page in my local wiki gives a JWT. Creating one via the endpoint gives the shorter token.
Jan 14 2021
Thanks for looking, sounds like a win. Patch merged.
Patch looks good, +1'd. Giving a bit more time for @Marostegui or others to common on the solution then will +2 if there have been no objections.
No more of these in the log for the past 90 days. Maybe this was transient or already fixed under another task? Closing task, please reopen if this is seen again.
Jan 12 2021
Not seeing any occurrences of this in Dec 2020 or Jan 2021. Resolving task, please reopen if necessary.
Jan 11 2021
The job of the Task API in this context is to know how to talk to whatever different backends are involved and make those differences transparent to clients.
In the case of the Image Recommendation specifically, we can say for certain this will be an ElasticSearch index right, whether it is the existing Commons ElasticSearch instance or a separate, slimmer index?
Jan 8 2021
Is this task complete?
Jan 6 2021
From the "stuff we have to decide" perspective, there's a little confusion in our current discussion regarding REST URLs. The task description currently contains a url like this, for POSTing a user's decision regarding a task:
To make sure I understand, when you entered these scopes: "openid profile email", you received the error message "The requested scope is invalid, unknown, or malformed".
Dec 17 2020
I'd hoped to reply today with some spec details, but as I continued reading various docs, I kept seeing additional things to consider. So instead, I'll post a random-ish collection of my current thoughts.
Dec 14 2020
To confirm, the issue is that the "user_email" value is missing, not that user_email_authenticated is NULL, right?
Dec 9 2020
However, I don't have strong feelings on that point and will be happy with whichever wording you choose.
I’d like to remove the “confidential” checkbox and add an option to the app type selector for “Mobile and desktop apps”.
Nov 30 2020
I'm curious about the details of this:
Nov 21 2020
Oh, awesome. Guess I should have read that. :-)
Nov 20 2020
To clarify, we could use $wgOAuth2GrantExpirationInterval to change the expiry for all access tokens, but that'd also change owner-only ones. I have not tested this, so maybe I'm wrong. But if that's correct, then we need to:
Nov 19 2020
As usual, one of the challenges is that whatever we do should also downscale/work seamlessly for local development and for third party installations without all the fanciness of our production environment.
The attached patch for a unit test on ApiUnblock looked good, but did require a fair amount of mocking in the test. Is there a way we could simplify this for future tests? Or given that not all API modules require specific services (per ApiMain::$Modules) maybe other unit tests would require less mocking?
I see several patches merged. Is this completed?
Nov 16 2020
The issue that @Pchelolo mentioned applied not only to the client, but also to internal code. If DAOAccessControl::get() always returns a string, internal callers don't have a good way to tell whether the call succeeded.
Nov 5 2020
Closing this as declined because it seems we need to take a step back and consider our approach, and to not split discussion between this task and T267270: Determine multi-dc strategy for CentralAuth.
Notes from a verbal discussion regarding how to approach this task:
Nov 4 2020
Oct 27 2020
Quote from Slack attributed to @Krinkle:
Oct 26 2020
Oct 16 2020
The patch I just uploaded is very basic - it simply adds HttpRequestFactory::createGuzzleClient(), and an associated test. I suspect it could be expanded a bit to make things more convenient. But as I'm not sure exactly how you'll be using it, I decided to start small and expand rather than trying to guess what would be helpful.
Oct 14 2020
Oct 13 2020
I also recall that we planned to use multiple kask instances, each with their own TTL. Is there a compelling reason to go a different direction? I think I recall @Eevans saying that standing up additional kask instances would not be difficult, but I personally have no knowledge of whether that remains true, or how to go about it. Who can speak to this, and would that same person or persons be available to create the new kask instance(s) if we go that route?
Oct 8 2020
Oct 7 2020
Apologies, typo'd the task number in an unrelated gerrit patch.
Still seeing on wikiquote and wikibooks as of Oct 7, 2020.
Oct 6 2020
Moving out of Platform Team inbox. We can retag this if it turns into a coding task.
Please retag Platform Engineering if it turns out we are needed.