When the feature flag feature_flag_new_tracker_permissions_check is set to 1
and an artifact A1 exists in a tracker T and the current user does NOT have access to the tracker T (and therefore should NOT have access to artifact A1)
and anything else has the same numeric ID as tracker T and a permission is set on said thing that allows the current user to see it (for example, another artifact A2 has the same numeric ID as tracker T and has permissions on artifact that includes the current user)
Then the DB query that retrieves artifacts will return artifact A1 when it should not. The REST API is using this query, but it double-checks the tracker permissions, and does not return artifact A1 in this situation. Confidentiality is safeguarded.

It requires a permission to be defined on an object with the same numeric ID AND said permission must be on a user group including the current user (for example on Project Members).

The quickest way to reproduce is to run the DB integration tests on current master:

make tests-db SEED=1716305341

The first test should fail with an additional unexpected artifact ID found.