Don't add edit links in API response if user can't edit posts

[leonidasmi]

Context

Summary

This PR can be summarized in the following changelog entry:

• Fixes an unreleased bug where edit links would be shown to users that can't edit posts.

Relevant technical choices:

Test instructions

Test instructions for the acceptance test before the PR gets merged

This PR can be acceptance tested by following these steps:

• Create an SEO manager and authenticate your POSTMAN requests based on that user.
• Add the following filter so that you remove the capability to edit other people's posts:

function remove_edit_others_posts_capability() {
    $role = get_role('wpseo_manager'); // Change 'editor' to any role you want to modify

    if ($role) {
        $role->remove_cap('edit_others_posts');
        // $role->remove_cap('edit_terms');
        // $role->remove_cap('manage_categories');
    }
}
add_action('init', 'remove_edit_others_posts_capability');

• Deactivate/reactivate Yoast SEO
• Do a request to the top 5 pages endpoint
• Confirm that for every post you get as a result, you see an empty array in the links array element: "links": []
  • If you dont get any posts in the results, in the transform_dashboard_url_for_testing() function of the helper doc, make it return early with a post URL, with return 'http://example.com/post-permalink';. That way, we simulate site kit returning that URL as a top 5 page (it will actually return all 5 pages as that URL).
• Now create a post with that SEO manager and in the transform_dashboard_url_for_testing() function, make it return early with the URL of that post.
• Do the request again and since you're getting 5 results of that URL, confirm that you get an edit link this time in all of them, like "links": { "edit": "http://example.com/wp-admin/post.php?post=5&action=edit" } and confirm that it points you to the edit page of that post you just created and that you can actually edit that post
• In the transform_dashboard_url_for_testing() function, make it return early with the URL of a term
• Do the request again and since you're getting 5 results of that term URL, confirm that you get an edit link this time in all of them, like "links": { "edit": "http://example.com/wp-admin/term.php?taxonomy=category&tag_ID=3&post_type=post" } and confirm that it points you to the edit page of that term and that you can actually edit that term.
• Now, uncomment the // $role->remove_cap('edit_terms'); and // $role->remove_cap('manage_categories'); lines in your filter above and deactivate/reactivate Yoast SEO. That way you remove the capability of editing terms for SEO managers
• Do the request again and confirm that you dont get an edit link for those term results.
• Repeat the above tests as an admin and without the remove_edit_others_posts_capability filter you have added above and confirm that you get an edit button in all cases where that's possible (that is, for posts and terms). Also confirm that you can actually go to that edit pages.

Relevant test scenarios

• Changes should be tested with the browser console open
• Changes should be tested on different posts/pages/taxonomies/custom post types/custom taxonomies
• Changes should be tested on different editors (Default Block/Gutenberg/Classic/Elementor/other)
• Changes should be tested on different browsers
• Changes should be tested on multisite

Test instructions for QA when the code is in the RC

• QA should use the same steps as above.

Impact check

This PR affects the following parts of the plugin, which may require extra testing:

UI changes

• This PR changes the UI in the plugin. I have added the 'UI change' label to this PR.

Other environments

• This PR also affects Shopify. I have added a changelog entry starting with [shopify-seo], added test instructions for Shopify and attached the Shopify label to this PR.

Documentation

• I have written documentation for this change. For example, comments in the Relevant technical choices, comments in the code, documentation on Confluence / shared Google Drive / Yoast developer portal, or other.

Quality assurance

• I have tested this code to the best of my abilities.
• During testing, I had activated all plugins that Yoast SEO provides integrations for.
• I have added unit tests to verify the code works as intended.
• If any part of the code is behind a feature flag, my test instructions also cover cases where the feature flag is switched off.
• I have written this PR in accordance with my team's definition of done.
• I have checked that the base branch is correctly set.

Innovation

• No innovation project is applicable for this PR.
• This PR falls under an innovation project. I have attached the innovation label.
• I have added my hours to the WBSO document.

Fixes https://github.com/Yoast/reserved-tasks/issues/436

[coveralls]

Pull Request Test Coverage Report for Build 645fa265d11c4cd91b8710da220e9cb379d5ca32

Details

• 0 of 2 (0.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 54.494%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/dashboard/infrastructure/indexables/top-page-indexable-collector.php	0	2	0.0%

Totals
Change from base Build 375624d0624ab89a45cf4bee4d633b406d03650a:	0.0%
Covered Lines:	30193
Relevant Lines:	55835

---

💛 - Coveralls