Eventually I may. If there's anybody who wants to give it a try, do not hesitate to claim.

Some investigation:

SELECT DISTINCT afl_action FROM abuse_filter_log;

+-------------------+
|        afl_action |
+-------------------+
|              edit |
|              move |
|     createaccount |
|            delete |
|            upload |
|           moodbar |
|          feedback |
| autocreateaccount |
|        gatheredit |
|       stashupload |
+-------------------+

SELECT DISTINCT afl_actions FROM abuse_filter_log;

+----------------------+
|          afl_actions |
+----------------------+
|             disallow |
|                 warn |
|                  tag |
|     blockautopromote |
| blockautopromote,tag |
|         disallow,tag |
|       aftv5flagabuse |
+----------------------+

So "By action (edit, createaccount, etc.)" can be trivial by adding an appropriate WHERE condition if you can find a way to gather all actions and localize them.

However, "By action taken (prevent, block, etc.)" can be more difficult because of those mixed actions (we need to gather all of those mixed ones and map them from/to actions and also we may want to prevent filters doing them).

Change 414102 had a related patch set uploaded (by Matěj Suchánek; owner: Matěj Suchánek):
[mediawiki/extensions/AbuseFilter@master] Filter Special:AbuseLog by action taken by filters

https://gerrit.wikimedia.org/r/414102

Change 414102 merged by jenkins-bot:
[mediawiki/extensions/AbuseFilter@master] Filter Special:AbuseLog by action taken by filters

https://gerrit.wikimedia.org/r/414102

Change 416352 had a related patch set uploaded (by Matěj Suchánek; owner: Matěj Suchánek):
[mediawiki/extensions/AbuseFilter@master] Filter AbuseLog by triggering action

https://gerrit.wikimedia.org/r/416352

@matej_suchanek please see my comment at T189857#4056408

Seems like https://gerrit.wikimedia.org/r/#/c/414102/ is not doing its job correctly when multiple actions are taken.

Specifically, the issue is that your patch assumes that the order in which those actions appear is "block,tag" but as I demonstrated, the order in which they actually appeared in the database was "tag,block".

I don't have access to WMF production databases, so the best way for me to check (in a large scale setting) how often entries like "tag,block" occur was to run a query via Clouds.

First I tried enwiki: https://quarry.wmflabs.org/query/25596 surprisingly did not return any rows with block in it. Is it because all blocking filters on enwiki are private?

On fawiki, I did get a more diverse set of results: https://quarry.wmflabs.org/query/25597 shows "block,tag" but not "tag,block".

I am not sure how the order of these is determined, but at least in one use case on my private wiki, I have gotten the order flipped to "tag,block" and that causes issues with the search feature introduced in 414102.

But even if the flipped order thing is an error on my wiki only, 414102 still suffers from many other issues. Looking at the query from fawiki you see entries like "block,blockautopromote" or "block,rangeblock" and 414102 will not capture them because it tries to do an exact string match on the afl_actions which is not a great idea. I will work on a patch shortly.

Actually, it seems like LogPaer.php does not allow using LIKE in the conditions. If so, we should retract 414102 because it can never be fixed. @matej_suchanek I will await your assessment.

In T187971#4056479, @Huji wrote:

On fawiki, I did get a more diverse set of results: https://quarry.wmflabs.org/query/25597 shows "block,tag" but not "tag,block".

I am not sure how the order of these is determined, but at least in one use case on my private wiki, I have gotten the order flipped to "tag,block" and that causes issues with the search feature introduced in 414102.

But even if the flipped order thing is an error on my wiki only, 414102 still suffers from many other issues. Looking at the query from fawiki you see entries like "block,blockautopromote" or "block,rangeblock" and 414102 will not capture them because it tries to do an exact string match on the afl_actions which is not a great idea. I will work on a patch shortly.

Ok, we can try using LIKE. Originally, I wanted to avoid it but there are more issues than I was aware of.

In T187971#4056484, @Huji wrote:

Actually, it seems like LogPager.php does not allow using LIKE in the conditions.

LogPager.php has nothing to do with AbuseLogPager. Could you also elaborate why it does not allow that?

In T187971#4056484, @Huji wrote:

Actually, it seems like LogPager.php does not allow using LIKE in the conditions.

LogPager.php has nothing to do with AbuseLogPager. Could you also elaborate why it does not allow that?

You are right. AbuseLogPager uses ReverseChronologicalPager. Would you mind making a patch for supporting LIKE? It seems unavoidable.

While you are working on it, please remember that some of the action names have overlap (e.g. "block" and "blockrange") so the search should be for four patterns as shown in this pseudocode:
"= {$action}" | "LIKE %,{$action}" | "LIKE %,{$action},%" | "LIKE {$action},%"

Change 420039 had a related patch set uploaded (by Matěj Suchánek; owner: Matěj Suchánek):
[mediawiki/extensions/AbuseFilter@master] Use LIKE to filter AbuseLog by action taken

https://gerrit.wikimedia.org/r/420039

Change 420045 had a related patch set uploaded (by Huji; owner: Matěj Suchánek):
[mediawiki/extensions/AbuseFilter@wmf/1.31.0-wmf.25] Use LIKE to filter AbuseLog by action taken

https://gerrit.wikimedia.org/r/420045

Change 420039 merged by jenkins-bot:
[mediawiki/extensions/AbuseFilter@master] Use LIKE to filter AbuseLog by action taken

https://gerrit.wikimedia.org/r/420039

Change 420045 merged by jenkins-bot:
[mediawiki/extensions/AbuseFilter@wmf/1.31.0-wmf.25] Use LIKE to filter AbuseLog by action taken

https://gerrit.wikimedia.org/r/420045

Change 416352 merged by jenkins-bot:
[mediawiki/extensions/AbuseFilter@master] Filter AbuseLog by triggering action

https://gerrit.wikimedia.org/r/416352