Feature/UI retrieve reserve identifiers

[dxL1nus]

Closes: #47, closes: #48, closes: #64;

IMPORTANT:

This needs to be merged after #58, as it utilized the Vue refactor form the branch that #58 is based on. So any changes made through #58 should also be in this PR afterwards.

---

Added The features to retrieve and reserve identifiers via the UI. At this point in time, this is only in the submission form, but once the other PRs are merged, I will also implement this in our editorial workflow pages.

---

Click Reserve Identifier:

Get Alert once Identifier has been reserved and new issue was created inside: https://github.com/codecheckers/testing-dev-register/issues

When Identifier is reserved, the UI now looks like this:

When the identifier gets deleted, it now looks like this:

It it correctly displayed in the created YAML file:

[dxL1nus]

I now merged main into the UI branch @nuest

[nuest]

Re file structure and naming: the folder "classes/RetrieveReserveIdentifiers/" is not consistent with the code in it, there is also code about venue types and names; suggest to rename, maybe to "classes/Register" ?

See this file for examples on how to use localised strings in a .vue file: https://github.com/codecheckers/ojs-codecheck/blob/main/resources/js/Components/CodecheckMetadataForm.vue

[nuest]

For my understanding: where do we assign the required roles? Or is this handled by OJS core?

[dxL1nus]

So far the roles are in this array:

$this->roles = [
    Role::ROLE_ID_MANAGER,
    Role::ROLE_ID_SUB_EDITOR,
    Role::ROLE_ID_ASSISTANT,
    Role::ROLE_ID_AUTHOR
];

and they are assigned to each route. I think it would also be possible to assign different Roles to different routes, if that is desirable and if we need it.

The roles are then checked on validity when a endpoint is calles in the authorize method:

// Check if the user that accesses this resource has at least one valid Role and if user exists
$user = $this->request->getUser() ?? null;
$contextId = $this->request->getContext()->getId();

if(!($user && $user->hasRole($this->roles, $contextId))) {
    $this->response->response([
        'success'   => false,
        'error'     => "User has no assigned Role or doesn't have the right roles assigned to access this resource"
    ], 400);
    return;
}

[nuest]

Need to distinguish between write and read access > @dxL1nus creates an issue.

[dxL1nus]

Re file structure and naming: the folder "classes/RetrieveReserveIdentifiers/" is not consistent with the code in it, there is also code about venue types and names; suggest to rename, maybe to "classes/Register" ?

Then I would call it classes/CodecheckRegister, because register in of itsself is a bit confusing, as it could e.g. also mean that there are special scripts inside that help the plugin get registered in OJS or something else

[dxL1nus]

See this file for examples on how to use localised strings in a .vue file: https://github.com/codecheckers/ojs-codecheck/blob/main/resources/js/Components/CodecheckMetadataForm.vue

I am aware on how to use localised strings, have I forgotten to do that soemwhere in the code? If so, then I am sorry and I will fix it

[dxL1nus]

i fixed the final requests for this PR in 3932030, so maybe it can now be merged @nuest. It would be nice, if you could review it again and take a look at my answers and solutions :)

[nuest]

There are very open open change requests.

Also, the question about uploading and downloading files for the manifest remains - should we discuss that in our meeting?

[nuest]

To avoid challenges with PRs that are based on each other, and still give me an opportunity to give feedback or review, you can also create a PR within your own fork:

https://github.com/dxL1nus/ojs-codecheck/compare/dxL1nus:feature/ui-retrieve-reserve-identifiers...dxL1nus:feature/unit-tests?expand=1

This makes the edits "on top of the other PR" readily accessible. I think I should be able to comment/review when you make me a collaborator on your repo.