zChenX

I know, but just disabling the enchantment shouldn't have an effect, is it because the loot table is also implicated?

I have the same issue

Maybe there's something wrong with the translator description
What I'm trying to say is that any_block_use my personal testing has found that only the quasi-test is only useful for blocks that can be right-clicked, not any form of player interaction with the block described in the changelog 24w03a

I don't know if it's a problem with my understanding, but I think any right-click trigger should trigger this criterion, including blocks that don't react when right-clicked, such as right-clicking bedrock with any pickaxe

However, this is not the case: right-clicking on a non-functional block will not trigger this criterion
For example, try to detect when the player right-clicks on bedrock
Here's the progress JSON in the datapack/advancements

{
    "criteria": {
        "requirement": {
            "trigger": "minecraft:any_block_use",
            "conditions": {
                "player": [
                    {
                        "condition": "minecraft:entity_properties",
                        "entity": "this",
                        "predicate": {}
                    }
                ],
                "location": [
                    {
                        "condition": "minecraft:location_check",
                        "predicate": {
                            "block": {
                                "blocks": "minecraft:bedrock"
                            }
                        }
                    }
                ]
            }
        }
    }
}

But replace bedrock with crafting_table

{
    "criteria": {
        "requirement": {
            "trigger": "minecraft:any_block_use",
            "conditions": {
                "player": [
                    {
                        "condition": "minecraft:entity_properties",
                        "entity": "this",
                        "predicate": {}
                    }
                ],
                "location": [
                    {
                        "condition": "minecraft:location_check",
                        "predicate": {
                            "block": {
                                "blocks": "minecraft:crafting_table"
                            }
                        }
                    }
                ]
            }
        }
    }
}

Right-click to open the Crating Table GUI and determine that the progress is triggered

The way to detect that progress is triggered is to use

/advancement revoke <player> <namespace>:<advancement_id>

If the trigger doesn't work, the player doesn't own the progress

Succeed on the contrary

So I think the any_block_use criterion should be to interact with any block in any form (including the normal right-click).

Found a solution for the time being Thank you

trigger add 0 is an unfixed vulnerability when a chat trigger command needs to be clicked

Maybe you don't understand me, and I don't know English, and I use translation software to communicate, maybe it's not what I meant
I mean if someone's trigger scoreboard instruction is set to
execute as @a[scores={trigger=1..}] run say 1
execute as @a[scores={trigger=1..}] run scoreboard players reset @s trigger
(This command means to say 1 once when the trigger score is greater than or equal to 1 and reset the scoreboard, I only want each player to run it only once, and no subsequent scoreboard players to enable @a trigger)
execute as @a[scores={trigger=-2147483647..-1}] run say 1
execute as @a[scores={trigger=-2147483647..-1}] run scoreboard players reset @s trigger
(This command says 1 when the trigger score is between -1 and 2147483647, the conditions are the same as above, I only want each player to run only once, and no subsequent scoreboard players are provided to enable @a trigger)

But if the player/trigger adds trigger 0, it is equivalent to disabling trigger for myself, and that is not my goal

Even if you try to correct the error, it will affect others, because when the scoreboard players enable @a trigger, the player's trigger score becomes 0

trigger add 0 is still not the only way to disable triggers without changing the value, and /trigger set can completely replace its function

So isn't a design flaw a bug?

Changing scoreboard players to add a non-zero value triggers disabling the trigger scoreboard Isn't this a bug?

It is also mentioned in the text
/scoreboard objectives remove trigger
Also a way
/trigger add 0 is not the only solution

trigger add 0 isn't the only way to disable triggers without changing their value; scoreboard players add 0 can also have that feature