User Details
- User Since
- Nov 18 2014, 11:57 PM (305 w, 2 d)
- Availability
- Available
- IRC Nick
- mooeypoo
- LDAP User
- Mooeypoo
- MediaWiki User
- Mooeypoo [ Global Accounts ]
Thu, Sep 10
I'm jumping in (by request! ;) to give my recommendation: I would 100% go with VueJS on this, even only for the reason that recently this was the framework adopted by the foundation for our frontend modernization.
Jul 21 2020
Also, this shouldn't act as a gadget; we did not officially release it as such and it is not optimized to be that. We're supporting it as a browser extension, and we're (ab)using the ResourceLoader queue "feature" to insert ourselves as if we're a gadget,but still working from the browser.
IIRC, we need to ask for the translated message for the button/link, and while we're at it we're asking for the rest of the messages. I don't think we can get away with not calling it at all and still have the link appear? (though admittedly I need to delve into the code again to see if it's a timing issue)
Jul 8 2020
Jul 7 2020
Jun 30 2020
@Marostegui (feel free to tag anyone else that may need to participate here?), we've discussed this extensively in the team after running into some challenges, and ran some analysis on the usage of the watchlist table. We want to see if we can reframe the problem and make sure we can find a viable way forward.
Jun 29 2020
Another idea, followup from conversations in the team:
May 29 2020
There's an issue here we should account for, or at least be aware of, that may make this block action less impactful than we'd think. If we go with @DannyS712 idea, we could probably block the actual action of moving a page (when you hit the menu action item for "move") but there are other ways to move pages manually.
May 22 2020
May 21 2020
It looks like the output should be added to the table entry for the page rather than just the rows outputted for a single change, in "EnhancedRecentChanges". Good catch, @Scardenasmolinar
May 20 2020
On StructuredDiscussion talk pages, I am seeing inconsistent popup behaviour when clicking the watch star.
Watching talk page
- Visit a talk page which is unwatched and has StructuredDiscussions enabled (go to Special:Preferences#mw-prefsection-betafeatures, check "Structured Discussions on user talk" and Save).
- Click the watch star. You will see the usual watch message:
- Click the watch star again. You will see the usual unwatch message:
- Click the watch star again. You will see the special StructuredDiscussion message:
With watchlist expiry disabled, you see the special StructuredDiscussion message when you first click watch (step 2).
Unwatching talk page
- Visit a talk page which is watched and has SD enabled.
- Click the watch star. You will see the SD message telling you you have subscribed to the page (even though you have not):
I can reproduce both of the above on beta, which has watchlist expiry enabled ($wgWatchlistExpiry = true).
I have not been able to reproduce either of the above with watchlist expiry disabled (on my local version).
@Scardenasmolinar I know @Mooeypoo worked on StructuredDiscussion, so she might know more about this.
May 19 2020
May 15 2020
We definitely rely on user rights when we show (and not show) the information when a revision is suppressed or deleted, by feature (not bug) so it sounds reasonable that if the revision was deleted, you'd get a popup with hidden details.
Can you check if this happened at a specific revision? I just tried it now, and I see the entire text highlighted, given credit to your username as have written 100% of the page.
May 14 2020
May 8 2020
May 7 2020
May 5 2020
May 1 2020
Sure, but there are exceptions to this rule, and when those exist, we do need a way to do it.
I think that the question of which "upstream" is a good one; ideally, this actually could be generic enough to be in OOUI tiself, but I agree that it probably just increases complexity and size for probably very low usage.
That's weird; we do have inline forms with text fields, I'd have expected this to be found as a bug before.... :\
If FieldLayout allows for an inline config, then it should respect inline settings.
Apr 21 2020
After a bit of back and forth with @Catrope and examining the challenges here with an OOUI popup, Roan made a good point about at least testing whether the alternative is viable.
Apr 17 2020
Thank you everyone for all the feedback and back and forth, and I apologize for any misunderstandings here.
Apr 9 2020
Apr 7 2020
@Nuria I'm a little confused, and I'd like to clarify something.
Mar 31 2020
Split to two tickets:
(egh, my screenshot didn't work, but--) w00t, it works now!
Sweet, I think this should fix it. I +2'ed, so it should be available on beta soon to test.
Mar 27 2020
Following up since @Etonkovidova has asked me to look into why it's not working:
Mar 24 2020
Mar 22 2020
I would avoid doing things that have no (or huge) limit. Honestly, I think it's a product problem more than a performance one, but since we are checking more than one target (unlike the original) I'd be slightly more careful, and go with pagination.
Mar 13 2020
Mar 12 2020
This looks great. Let's just make sure we don't literally copy over what RecentChanges is doing, because the way it is constructing its lines is pretty horrific, and uses monospace-font single-spaces to align tags per each line, etc.
Mar 7 2020
Oh, I'm sorry if I misrepresented. I got confused with the table showing different messaging exists=true and exists=false... which is different than the suggestion. Sorry, it's really confusing -- I'm just glad we are on the same page!
My main concern was about changing the behaviour of a long-standing and widely-used widget - if that's ok then let's go ahead with this.
Mar 6 2020
Thank you for the thorough analysis, @Tchanders !
Feb 26 2020
Clarification: The cap should be configurable per wiki (per the conversations with DBAs), with a default (for now) of 20,000 items.
Thank you for the excellent detailed reply, @EvanYou. This is a great summary of the points, and gives a good perspective to this RFC and the entire modernization endeavor in general.
Looks good to me. Thank you for figuring it out, @matmarex !
Thanks @Dzahn ; I signed the document, and my public ED25519 key is:
Feb 25 2020
The general idea of this specific task is to provide the full coverage for the Services, not so much for the special page, which seemed to be more focused and doable. We've added the use cases to guide/inform the approach to the testing.
Feb 21 2020
A couple of small clarifications from the meeting. The third option is the one that's laid out in the description of this ticket, including the product implications.
Confirmed; on Firefox v73, even on not too large of a screen.
Feb 20 2020
We don't have that in production so far, so I'm not sure, especially due to security concerns. We might need to have a gadget where each user must whitelist the toolforge URL individually for security and privacy.
PRU is now available on all test wikis:
Feb 19 2020
The table has been created. Thank you for all the advice and guidance and help @Marostegui! And thanks, @Anomie, for the input and guidance on the best ways to approach the purging.
Investigation resolved. Next steps on followup tickets. Thank you for everyone's input!
Investigation is done; we will await next steps to create followup tickets.
Feb 18 2020
Feb 17 2020
Will do, @Marostegui ; FYI, I'm also tracking the creation of the table through this ticket: T244631: Create `watchlist_expiry` table in production after wmf.19 is available.
Feb 15 2020
Feb 14 2020
Just to clarify for engineering related thing, am I right to say that, basically, the message ("Both username and email address are required to receive a temporary password via email.") should never appear anywhere, @ifried ?
The product we're discussing (an expansion to CheckUser) deals with potentially large chunks of data from the database, which triggers a number of problems with regard to performance. Regardless of what method we use, we have to come up with a good way to deal with that. After discussing with the team and talking things with @Catrope for some advice around how CheckUser has historically extracted potentially large chunks of information to process, I think we have a slightly changed strategy, and have a plan.
Feb 13 2020
Feb 12 2020
Feb 11 2020
Thank you for the analysis, @HMonroy, this is super helpful!
That's a good point also for the no-JS version.
Feb 10 2020
Note: This process is already implemented for the RecentChanges table, which is being purged every few edits. see: https://gerrit.wikimedia.org/g/mediawiki/core/+/799eeb583a6747ad96888ec0fef8f76e45079129/includes/Storage/DerivedPageDataUpdater.php#1493
Feb 8 2020
These look great, @Prtksxna !
Feb 5 2020
To clarify -- the wl_id was already added to the table. When we checked into this feature, we believed this RFC to be done because the details (wl_id in the watchlist table) were done, even though the original proposers then deprioritized the work on the feature. When we consulted, we were told no RFC is needed for the actual feature.
We're working on this as part of the wishlist items. We're going with the strategy of adding a new table that references the watchlist item and has an expiration.
Feb 4 2020
Thank you for the quick response, @Marostegui.
Jan 26 2020
Thank you for the kind words, I'm really glad you like this, and very happy to see the positive reactions overall.
Jan 23 2020
The patch as written by @dbarratt looks good to me, but I'd like to make sure this complies with your recommendations, @sbassett, especially in regards to the given packages and the versioning. Since this is going to be what we base the rest of the product on, can you be so kind to do a quick pass, @sbassett https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/554229
Jan 22 2020
Now that we have things organized and settled, I'm tagging DBA for assistance. Please let us know if there's anything we need to further expand on, explain, or help with. Your help is super appreciated, thank you!
After some thinking, I unfortunately think that the extension route might actually not be feasible because of the external API request (I don't think we allow for any of that in extensions in production) but either way, a question -- @MusikAnimal
Jan 21 2020
This is a weird bug, but I don't think it's a problem of the character, I think there might be an issue in WhoColor with this specific article?
There is another option we should add to the investigation, @MusikAnimal -- let's also check into making WWT into a MediaWiki extension.
Added as part of https://github.com/wikimedia/WhoWroteThat/pull/138
OK I fixed the comments, and also fixed up the request from T242954: WWT Popup: Padding changes [x-small] so this is ready for re-review.
Jan 16 2020
Perfect. This can be fixed / added to the ongoing PR https://github.com/wikimedia/WhoWroteThat/pull/138