You should be able to manage post visibility through the “pre_get_posts” action. All post requests go through this action AFAIK. Custom code should be added through either a child theme or site specific plugin.
The basic logic would be if the query is the main query and post type is ‘report’ and the user is not an admin (or other role who should have full access), alter the query vars to include requiring the current user to be on the post’s custom field for allowed users. It’s probably easiest to store the allowed user ID as post meta. Other identifiers are possible, it only slightly complicates things to not use ID. I’m assuming your custom fields plugin stores data as post meta. So in the pre_get_posts callback, if the general criteria is met, set the ‘meta_query’ argument to be the appropriate array which requires the current user ID as a meta value. Refer to the custom field segment of the WP_Query docs. Scroll down to Single Custom Field Handling for a basic example.
What could get complicated is if the query already has other meta data criteria as part of the query. You’d need to merge your criteria with the current criteria. Hopefully this is not an issue for this post type. A solution still would be possible, but merging arrays does complicate things.
Depending on your theme and what your site actually does with these posts, some pagination might not work correctly. By using pre_get_posts, most pagination should be OK, but do check your site for issues just in case.
I imagine this all sounds hopelessly complicated. It’s not so bad. I’ve noted many contingencies because I don’t know your specific situation. If these contingencies are not an issue, and if you can tell me exactly how the user is stored, I can give you an example that is fairly straight forward.
