User Details
- User Since
- Jun 11 2020, 1:21 PM (37 w, 3 d)
- Availability
- Available
- LDAP User
- ProcrastinatingReader
- MediaWiki User
- ProcrastinatingReader [ Global Accounts ]
Thu, Feb 18
Also see T275118
Also see: T263943 (preceding task)
Jan 22 2021
Dec 22 2020
Dec 20 2020
Note @ToBeFree's link is regarding the iOS app (not Android as in this ticket). But this is a problematic issue both ways - communicating with editors is very difficult without notifications.
Oct 24 2020
@matmarex @ppelberg the patch I released was somewhat tangential to what I intended this issue to be (it's an improvement, but not a 'fix' in my eyes). I'd still like to focus on hiding these details (at least the semi-protection ones) in that message entirely, if it's something I can swing by whoever needs to sign off on this. It's really irritating for me to see that regular long log dump on every other page, most of which I just can't see a use for. On pages without an actual notice, it pops up anyway (when in its absence nothing would pop-up) and slightly throws one off. Just doesn't feel like it belongs.
Oct 17 2020
@matmarex got around to the ordering, at least, in above patch. Could you see if it's all good, when you have time?
Oct 11 2020
May be of interest for enwiki: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Move_good/featured_article_topicons_next_to_article_name
Oct 6 2020
Saw this posted today and it makes me think, it could just be at the end of the text without alignment without much trouble?
Sep 30 2020
Although if you're not interested in this, I'll probably submit a patch myself.
Sep 27 2020
@JTannerWMF would editing be okay with / approve a volunteer patch for this? Either an option to disable this (from all editors), or disabling them entirely, one or the other?
Sep 26 2020
@TheDJ curious why the patch was abandoned? Seems like it'd technically work?
That said, I think that adding in remaining space on the right side of the title (or adding a newline) is the best solution and it can be managed in the same way.
There are cases when bot reverts should be notified. The most obvious one to me is ClueBot, https://en.wikipedia.org/wiki/Special:Contributions/ClueBot_NG. Edits are marked as minor, not sure if they're marked with bot too. Second, sometimes bots edit articles and the contributors don't want that bot edit. Many bots will edit again if the bot is reverted (they're not that smart), so notifying editors that a bot manually reverted them would seem a good idea. Such bots (at least on the English Wikipedia) will be flagged as bots, and typically mark their edits with bot: true as well, so using the fact of whether or not the particular edit by a flagged bot was also marked as a bot edit won't work.
Sep 24 2020
@matmarex imo it's pretty useless, but maybe removing it from all editors may prove a bit more work (in terms of process)?
Sep 21 2020
@matmarex whoops, I didn't mean mobile. I'm getting my tasks mixed up (as I've something similar to the opposite for mobile). Sorry, will update to clear it up.
Sep 18 2020
Sep 13 2020
Aug 29 2020
@Tacsipacsi to be completely frank, and just my opinion, but wikis don't exactly have the best idea of "what's important" from a UI perspective. Move protection indicators, for example, are utterly useless. Even 99% of editors don't wish to move the page, never mind readers. They're in place to stop the odd users moving articles, yet an icon is shown to everyone. On a smaller scale, especially for mobile, this applies for page protection too -- most people just read not write on mobile, and showing colourful locks is not particularly helpful, especially on a mobile view where they'd stand out a lot more. When you start looking at talk notices and editnotices the point becomes more obvious imo. One 'unintended' advantage of the software limitations of the mobile style is that it saves the mobile UI from becoming a cluttered mess. Quality assessment indicators are neat, and give a useful indication for readers also, though.
@TheDJ regarding "were repeatedly pointed at how useless many of these banners were", do you have links to a few past discussions by any chance?
Aug 27 2020
I do think that stuff like pp-protected should be hidden on mobiles. We only want to show indicators like good-article / featured-article. The rest is kinda bloat.
Aug 3 2020
on wiki edit notices can be extremely verbose
Jul 31 2020
@Huji Yeah, I can submit the patches (one to add it into AF before the call, then another to revert the wmf-config patch). It'll probably be a week till I can get around to it, though. If you can get around to them sooner, it's fine with me for you to submit the patches :)
Jul 22 2020
Sure, but there's a bit of a difference in having to write your DB credentials (something the software could never possibly auto determine), and having to add in a config variable for the software to work as we intended it to.
Jul 21 2020
Shouldn't those hypotheticals also be hardcoded in? My reasoning is that the point of configuration is for users to change how the software behaves. This is making adding a configuration variable a requirement for functionality to work as intended. There's no developer intention, or valid purpose, for this data to be purged from CU logs. So we're kinda just adding an extra hoop, and most non-Wikipedia users who run into this probably shouldn't have to jump into some obscure part of the doc to realise that they have to add a compulsory param. We can keep the config param too, I suppose, for future additions, I just think this particular param should also be hardcoded in.
Jul 17 2020
I believe this added param still needs to be documented at https://www.mediawiki.org/wiki/Extension:CheckUser. I wonder if a note should be added to https://www.mediawiki.org/wiki/Extension:AbuseFilter as well, since it appears to be the sole (?) culprit requiring this.
Jul 6 2020
Jul 4 2020
@Huji do you still plan to schedule the deploy for the 6th?
Jul 3 2020
@Majavah thanks for the heads up. I was under the impression that it had to be +1'd first (aware the +2 is during deploy), but if that isn't required I'll go again and schedule.
Jul 2 2020
Jul 1 2020
Having taken a quick look at this, seems to be due to the $item->canView() checks failing (eg at SpecialRevisionDelete::showForm, line 420). That function is in RevDelRevisionItem, line 81:
@Jdforrester-WMF @Aklapper if the functionality is indeed undesirable I'm not sure if it matters whether Apple fix this on their end (which, ultimately, I'd think any 'fix' would require removal of the feature, since it's hard to determine whether 900-1200 is a phone number or a year) or if MediaWiki does just for its software using the meta tag. (I believe this tag is only recognised by Safari for these purposes, but I could be wrong). Of course, links can still be formatted as tel if they're explicitly formatted as such, and via the use of a template it'd be neater than the a tag everywhere.
Jun 30 2020
Jun 29 2020
Jun 28 2020
@Tgr Doesn't seem like addTemporaryUserRights works, perhaps due to the different scope?
Jun 27 2020
A very cheap way to do it, which I think is kinda like the last option @Tgr suggested, is to chuck in
$user = User::newFromName("ObscureUsernameCheckUserLog"); if ( $user->getId() !== 0 ) { $context->setUser($user); }
Jun 20 2020
I've picked this up where @Cenarium left off, rebased into current master and updated some small things to make it work: https://gerrit.wikimedia.org/r/316410/
This is also broken. rev_timestamp is a blob, not an integer, so this query also fails to return results. Tested in SQL console with and without encapsulating it in quotations, and the former returned results, the latter (as in code) did not, so I believe that is also related to this.
Jun 16 2020
Jun 15 2020
@DannyS712 No - I get "No results". The filter is public and I've enabled all the permissions for my role.