In T239680#5717468, @AronManning wrote:

My concern is whether one check (pressing the "Submit" button, switching to "Compare" tab) for multiple users should create one or multiple cu_log entries.

In T239680#5717435, @AronManning wrote:

CU log entries and CU investigations have a 1-1 relation. Calling it a "log" is arbitrary, reflecting the original use-case. Maybe calling it "CU investigations" in the DB would be more appropriate while calling it "CU log" on the UI.
I see only one limiting factor with the current cu_log table: cul_user is an N-1 relation, that cannot accommodate for multiple users checked in one investigation. That will require a new table (schema change).

During TechConf, I've discussed the implication of a periodic purge of the Watchlist table with several people, and there seems to be consensus that the general approach is sound with regards to the new table and the periodic purge of the Watchlist based on indexed timestamps of the watchlist_expiry table (ticket upcoming for the creation of that table+consultation with DBAs)

Repeating what we discussed (briefly) in an RL meeting -- We need to come up with a way to make sure the pagination works with the same state, but I am not convinced that sessions are the best way to go.

@Rxy The AHT team has taken on rewriting and redesigning CheckUser as part of the general strategy around this area. This means that we are *heavily* editing the code, and the plan is to replace the current CheckUser special page with the new one that we're building.

Note: We might already have a message about invalid characters in Usernames within the registration page? Worth checking if it's valid to reuse here.

Ahha! I think there might be an issue of re-processing the contents if it's re-requested.

Basic Functionality: Investigate how users can watch a page temporarily (highest priority)

• Via the "watch" star: Can we add a drop-down menu (when user clicks the "watch" star) that enables them to select a timerange (for example, one day, one month, three months, six months, or permanently)? See the mockup link for examples.
  • What are the possible risks or issues associated with implementing this?

Pull request ready for review: https://github.com/wikimedia/WhoWroteThat/pull/102

Should have been fixed by https://github.com/wikimedia/WhoWroteThat/commit/0e9e72022751c7f9d003d3a672ed6ab1eeb5768e

@Halfak Do you know who can fix this test? This is blocking two patches that we need to merge to PageTriage; it comes up as an unrelated test failure, and we can't figure out why or what to do about it.

@Jdlrobson hm, this seems to have been worked on in the 2016 wishlist and seemed to have worked since; is this a new / recent failure? I remember there was conversation about problems with UTF characters when we migrated to PHP7.2, could that be the problem as well?

Pull request awaiting review: https://github.com/wikimedia/WhoWroteThat/pull/92

Should be fixed with https://github.com/wikimedia/WhoWroteThat/pull/91

Oops, the link should be hidden when the system is disabled. I think it's a problem of how I instantiate the system with the wrong starting value.

The second behavior should be fixed when https://github.com/wikimedia/WhoWroteThat/pull/80 is merged

In T234483#5615929, @dom_walden wrote:

@Mooeypoo After this change (which I think is this) the revision summary animation does not appear for tokens you have already clicked. Instead, you see the revision summary blinking in and out.
I also feel like, even for tokens I am clicking the first time, the animation does not always appear (or not for long enough to notice). Although I appreciate that is a bit subjective.

In T231508#5605714, @dom_walden wrote:

@MusikAnimal If you go directly to the VisualEditor (e.g. https://tr.wikipedia.org/w/index.php?title=%C4%B0Pad_Mini_4&veaction=edit), the "Who Wrote That?" link appears briefly and the guided tour popup appears and remains (unless you have previously dismissed it).
In the brief period in which the "Who Wrote That?" link appears, if you are quick enough you can click it and have the infobar appear. Leaves it in a weird state where model.enabled == false but model.active == true. This does not appear to interfere with VisualEditor.
I don't see these problems when I go first to the article and then click "Edit".

We should still fix the security issues, (perceived or real, regardless)

I'll facilitate this. I'll talk to the group about whether there are specifics we want to make sure are delivered within the given topic.

We've discussed offline but just for posterity here -- the biggest issue we have is that these percentages are calculated based on tokens and on wikitext. Essentially, the second author may have edited things like citations and thumbnails and templates that we do not "see" visually in the visual WWT tool, but make his edits correctly account for 2.1% of the page.

This was fixed (incidentally!) as part of the MVC refactor.

Submitted a PR to handle load/unload of VisualEditor: https://github.com/wikimedia/WhoWroteThat/pull/64

This is more about good practice rather than strictly security.

A pre-requisite is to be able to shut off the system (and disable it) from an event handler. Created T234874: Enable WWT to be turned on and off remotely for that task (PR attached) and will follow up with a VE-specific event handler after that one's merged.

PR available: https://github.com/wikimedia/WhoWroteThat/pull/63

In T231508#5544348, @Prtksxna wrote:

In T231508#5542462, @Mooeypoo wrote:

[edit] There's also mw.hook( 've.deactivationComplete' ) for deactivation of VE (thanks @Esanders ) that can be used to reactivate the activation link.

If we re-add the WWT link after someone has made changes using VE, will WWT be able to show the newly added content? Or would that require a refresh of some sort?

So after an investigation, here are findings on how we can potentially do this.

You're right, we missed that part when discussing the ticket; it was fixing a code review comment by adding extra functionality.

This is merged to master. I will update the self-hosted gadget in the next few days before it moves to product (if all is well :) .

This was merged, and will be available on beta in a few minutes.

Bringing back to review for this patch.

Thanks to the amazing debug (and git blame) skills of @Catrope we found the problem.

In T230455#5515631, @dom_walden wrote:

@MusikAnimal @Mooeypoo There is an odd behaviour I cannot understand. After opening the "Page info" flyout the articleinfo hook fires, which is fine. But afterwards, each time I mark the page reviewed/unreviewed (without refreshing), the articleinfo hook also fires. First time once, second time twice, third time 4 times, then 8, etc.

@dom_walden I just re-tested this in an effort to figure out what's going on, and I can no longer reproduce it...

In T232460#5505012, @ifried wrote:

@dom_walden Ah, thanks for the clarification!
@Mooeypoo This bug may only be reproducible with the extension rather than the gadget. Do you know why that may be?

In T231943#5508157, @Tchanders wrote:

@Tchanders you're making a good point about this; however, this will only fix the underlying ask tangentially. It would mean that the checkbox being selected won't matter, but it won't actually unselect that checkbox.

Just to help us understand this correctly - are there cases where a logged-in user on office wiki should be blocked if the IP they are editing from is blocked? If not, then we could use the 'ipblock-exempt' option.

In T231943#5505503, @Tchanders wrote:

Forms that pre-populate fields by default will just get it wrong in some cases... Could we get round the problem another way, as suggested above? E.g. setting $wgAutoblockExpiry to 0 or granting the permission 'ipblock-exempt' to all users?

In T231943#5505503, @Tchanders wrote:

I agree that it feels a bit problematic to make assumptions about autoblocks based on the $wgBlockDisablesLogin config. I'm not sure I agree the checking of $wgBlockDisablesLogin and isEveryoneAllowed('read') is much better - it's less impactful, but the principle is the same. (If a wiki with these settings wanted the checkbox checked by default, what would we do?)
Forms that pre-populate fields by default will just get it wrong in some cases... Could we get round the problem another way, as suggested above? E.g. setting $wgAutoblockExpiry to 0 or granting the permission 'ipblock-exempt' to all users?

In T231943#5505070, @DannyS712 wrote:

This is why, originally, I had introduced a separate config variable to control this. However, @Krinkle objected on the patch (https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/534936/) to the addition of a new global setting, instead suggesting that $wgBlockDisablesLogin be used. I have no strong preference either way, but given that just checking BlockDisablesLogin wouldn't be enough, I again suggest that a new config value be added.

First off, thank you @DannyS712 for picking this up :)

Hm I wonder if this has anything to do with the upgrade to jQuery 3.4.1, and that ULS perhaps needs to be adjusted for it.

In T233115#5501893, @Barkeep49 wrote:

It would help if we had any kind of data about the number of triggers this would pull. Would it be comparable to the edit filters?

I'm sorry to hear that. If you ever change your mind, we'll be happy to try and help guide you through the process.
In any case, this page might be able to help as well, if you need it: https://www.mediawiki.org/wiki/Help:TemplateData

In T232168#5472969, @AlgorithmGG wrote:

@Mooeypoo thanks. the manage template button is already active. Is there anyway to have it working as described in the TemplateWizard instructions?

TemplateWizard allows you to insert templates into a page if they have TemplateData definition.
TemplateData extension can help you set definitions in your templates.

If you have TemplateData installed, you can add $wgTemplateDataUseGUI = true; to your LocalSettings.php and you'll see a "Manage TemplateData" button when you edit a template.

@AlgorithmGG TemplateWizard requires having TemplateData definition in each template.

One of the biggest issues here is that we call the hook just before we refresh the page, and that the use cases that this hook is for are working asynchronously, which means refreshing immediately after call is not going to help anything

Sweet! I'm so glad that this is working properly and thank you for the feedback.

Fair enough.

I will remind everyone that we're talking about a WMF employee here.

@sbassett in that case, I just want to make sure we add to the list the fact that Anti Harassment's Tool team's work touches on blocking tools, which inherently tend to be Security tickets if any bug happens there.
Our upcoming work will involve CheckUser, which, again, almost exclusively has bugs in the security realm. For us, this is not just a matter of this being useful, but a pretty crucial part of the work, in case bugs happen in the part of the code we actively work on.

CSSJanus Webpack plugin: https://github.com/mooeypoo/cssjanus-webpack

While doing some experimentation, I unfortunately discovered it's not as easy to get GuidedTour to activate from the injected script; the naming conventions and the fact that it supposed to run on all pages seem to be a bit more difficult for the extension to load itself with the gains of the cookie and toggling.

In T207485#5419052, @ifried wrote:

5. "apihelp-pagetriageaction-param-pageid": "The article for which to perform action on."
   • Potentially change to: “Select this article”
6. "apihelp-pagetriageaction-param-reviewed": "If set, specifies whether the article is reviewed."
   • Potentially change to: “Specify whether the article is reviewed”
7. "apihelp-pagetriageaction-param-enqueue": "If set, the page will be added to PageTriage queue."
   • Potentially change to: “Page will be added to the PageTriage queue”