GDPR Reviewer Workflow: vocabs/interests endpoint to autocomplete reviewer interests

[jardakotesovec]

Description:
Current user profile page has input field for reviewing interests (in Role tab), which is using /en/user/getInterests endpoint for autocomplete.

With new GDPR Reviewer workflow coming from #11836, user will be able to update these reviewing interests while accepting invitation. Accepting invitation process is happening without having any user role, therefore to replicate this functionality it needs to rely on publicly available endpoint. Confirmed with @asmecher that for this use case its safe enough to go ahead with that.

/end/user/getInterests has its own specific format. Which would require another form field instead of using existing FieldControlledVocab to be able correctly map it.

Proposed solution
Introducing new endpoint under /api/v1/vocabs/interests?term=test path. Its separate endpoint to the /vocabs endpoint as there are couple of differences:

• authorisation is different as its publicly available
• its not multilingual
• its not context bounded

PRs:
pkp-lib: #12014
ojs: pkp/ojs#5173
omp: pkp/omp#2175
ops: pkp/ops#1143

[jardakotesovec]

@asmecher @ewhanson Could you please confirm whether the approach make sense and do the code review. After that I would create PRs for omp. Ops probably does not use that.

[asmecher]

@jardakotesovec, I think it makes sense to add this entirely to pkp-lib rather than having an odd work-around for OJS.

• The index.php wrappers don't typically do anything more than inspect the incoming $op parameter and delegate to the right class accordingly. Eventually we'll probably get rid of these in favour of Laravel-style routing, so I'd like to keep these as close to dead simple as possible. Moving the implementation into pkp-lib's PKPInterestController.php entirely would achieve this. I don't mind if we expose the endpoint in OPS in the process -- as long as the implementation in pkp-lib is secure/performant for OJS and OMP, then OPS won't introduce any additional risk.
• If it's possible to easily replace the old faux-REST endpoint (I think lib/pkp/pages/user/PKPUserHandler.php?), then that would be a bonus!

[jardakotesovec]

@asmecher Sorry, not sure if I follow.

PKPInterestController.php is already in lib/pkp and ojs is just referencing it. Current system does not support nested routes - so using strpos to get around it - same as api/v1/stats/index.php.

Maybe you intended to suggest to move this new endpoint into existing PkpVocabController? I did consider it, but since interests is public endpoint - it looked cleaner / more obvious as separate controller. But its possibility.

I will see if I can adjust the legacy part to use this new endpoint as well and remove the previous one, just need more clarification what change you had in mind.

Update: Added second commit which removes the legacy endpoint and makes the legacy forms to use the new one.