git rebase master

git rebase master

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.