git rebase master

Makes sense thaanks, 0s seems also the documented default

Don't change URI path /people/tasks/{$id}/ of assigned tasks not to break potential external linking

git rebase master

• Rebase

Nice

(and well done Herald²)

(And well done Herald)

Go back to previous khtml only change

Great, Phorge. So much for stacked patches... Looks like git checkout -b mozPrefixedCss cssKhtmlOpacity did not do what I had expected it to do.

Remove pre-2013 vendor-prefixed -moz- CSS properties

@valerio.bozzolan could you please add to either H28 or H29 Affected files contains none of map.php?

Marking as "probably my previous block is now nonsense - but still not reviewed sorry" asd

Uhm yes thanks

In D25912#24622, @aklapper wrote:

In D25912#24618, @valerio.bozzolan wrote:

P.S. maybe if the task number is very small (e.g. 2) maybe we can still allow that.

I'd prefer not to introduce non-obvious confusing behavior (sometimes it does, sometimes it doesn't?) to increase code (and testing) complexity for no good reason...

It works on my computer and it makes me feel like a happy Phorgi unicorn running in a Phorgi golden forest, whoa

Another good simple candidate GDPR-friendly:

This is one great Wikimedia patch being upstreamed. Should I make this a sub-task of T15081?

Took the opportunity to fix a typo in the summary.

In D25912#24618, @valerio.bozzolan wrote:

P.S. maybe if the task number is very small (e.g. 2) maybe we can still allow that.

(Feel free to copy-paste the downstream task in Phorge - so the lack of task is not used as blocking reason - maybe title "Allow to mitigate spammers from workboard bulk move" or something similar)

I think this makes sense - Mark All Read is about marking all search results read. (I assume; I never used it. But that's what the UI implies, it being grouped with e.g. Use Results which is definitely about doing things with the search results.) So no search results -> nothing to mark as read. The bug is in not getting any results.

I believe that this is not the correct approach, thus abandoning.

@aklapper we are talking specifically about documents that are under another document, that is, about the hierarchy of pages in the wiki.
The screenshot F3250825 just shows that the visualization of the document hierarchy is not very convenient in my opinion, and I ask if it can be moved to the side.

On Outbound Email rules, does the Do Nothing action neither send an email nor a notification?

Uh interesting - good to know for the future. So at least the button Mark All Read here in F3271029 should be visible for your case - as very minimal mitigation sub-task

The mark all read link in the notifications dropdown panel is always available. (It did clear the phantom notification.)

The current workaround is to wait for a real notification, to then finally be able to click the Mark All Read.

It happened to me but only in Wikimedia Phabricator, there I had a notification counter in the top-bar, but with no unread messages in the related list

I don't understand the problem described...

Search brings up rP70d67a3908b8: Fix the most significant "phantom notification" badness

Thaanks - please wait 7 days + 1 hour + 1 second + 42 milliseconds before landing to attract more Pòkèmòn reviewers

In T15203#21226, @valerio.bozzolan wrote:

(M is short for Mockup probably)