Skip to content

feat(admin): check whether application can be approved

David Flor requested to merge xflord/STR-1510/can_be_approved into main

Description

feat(admin): check whether application can be approved

  • added missing canBeApproved call before approving application on the detail page
  • added a dialog to display info and override (for soft errors) approval in case of CantBeApproved error
  • added an alert to application bulk error dialog which refers user to the detail page in case of CantBeApproved error
  • updated openapi

How to test

Add a module that performs a canBeApproved check to a set up application form (I used CeitecNcbr for example, check the backend classes to see which are available, ideally modify some to truly test all cases), submit an application which should not pass the canBeApproved check and try to approve the application. Observe that on the detail page, the new dialog behaves as desired.

You can also opt to use the Metacentrum module, since developers' PERUNADMIN accounts should pass canBeApproved, but won't pass approveApplication if you do not have the correct group structure in the VO. Applications submitted from a private window won't pass the canBeApproved check. This is useful to check the bulk approve functionality in case of multiple applications.

When bulk approving applications, ensure that the new alert is displayed when a CantBeApprovedException is thrown (and only then) and that the "approve anyway" dialog pops up instead of the default error description upon clicking on the error in the table (and that the dialog works). Also upon "force" approving an application in the bulk dialog, the underlying tables should refresh (the bulk error table immediately, the base application table should refresh upon closing the dialog)

Author's checklist

  • I have followed the contribution guidelines
  • This MR has been tested or does not change functionality
  • I have added relevant merge request dependencies (if this MR has any)
  • I have added the correct labels
  • I have assigned reviewers (if any are relevant)
  • I have edited the documentation (if the changes require it) or I have noted the need for the change if I do not have access to the documentation
  • I have marked all introduced BREAKING CHANGES or necessary DEPLOYMENT NOTES in the commit message(s)

Reviewer's checklist

  • This MR has been tested or does not change functionality
  • This MR has correct commit message format

Other information

The core of this MR is to add the check present in https://gitlab.ics.muni.cz/perun/perun-idm/perun/-/blob/main/perun-web-gui/src/main/java/cz/metacentrum/perun/webgui/json/registrarManager/HandleApplication.java , Use this to compare

Related issues

Re STR-1510

Edited by David Flor

Merge request reports