Page Comparison

...

The functionality shall be usable via the ui.

In addition, there exists the requirement to have an API endpoint do the checks for batch deletes only without deletion. It needs to be checked (e.g. adding delete functionality to mod-user-import).via the campus management system) if there is an open fee/fine that needs to be paid before leaving. The user may be deleted only one year later (to create reports for example). 

Related Jira Issues

The tickets we are working on are the following:

Jira Legacy
server System JiraFOLIO Issue Tracker columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 01505d016ccf3fe4-b8533301-3c2e368a-90f1983e-ee9b165564fc20c466b11a49 key UXPROD-2728

Jira Legacy
server System JiraFOLIO Issue Tracker columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 01505d016ccf3fe4-b8533301-3c2e368a-90f1-ee9b165564fc key MODUIMP-33
Jira Legacy
server System Jira columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 01505d01-b853-3c2e-90f1-ee9b165564fc983e-20c466b11a49 key UXPROD-2388

Jira Legacy
server System JiraFOLIO Issue Tracker columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 01505d016ccf3fe4-b8533301-3c2e368a-90f1983e-ee9b165564fc20c466b11a49 key UIU-1971

Proposed approach

As the requirements are not only to trigger the checks from the frontend, but also to perform user-deletions with references-check via mod-users-import (see

Jira Legacy
server System JiraFOLIO Issue Tracker columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 01505d016ccf3fe4-b8533301-3c2e368a-90f1983e-ee9b165564fc20c466b11a49 key MODUIMP-33

), the checks cannot be performed in the frontend only. In addition, the checks are same whether they are triggered by the front end or mod-users-import. Hence, implementing the checks into the front end or mod-users-import is considered not as a viable approach. Instead, the checks will be implemented in mod-users-bl so that both the front end and mod-users-import can use them.

...

• First of all we need to implement functionality to check if the user can be deleted:
  • As this checks span multiple modules (e.g. checking open requests via /request-storage endpoint of mod-circulation-storage) the checks need to be done in a bl-module, namely mod-users-bl.
  • In order to check if a user can be deleted, add the endpoint /bl-users/by-id/{id}/deletable to mod-bl-users. (There is no convention or standard way to do this. However, the _deletable_ endpoint was discussed in

    Jira Legacy
    server System JiraFOLIO Issue Tracker columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 01505d016ccf3fe4-b8533301-3c2e368a-90f1983e-ee9b165564fc20c466b11a49 key CIRC-179

    )
  • The proposed endpoint performs defined checks for a given user by querying the corresponding modules:

    1. Fetch open loans from mod-circulation-storage via user's id: /loan-storage/loans?query=(userId==c926be9c-a8ce-4399-a9b3-11ec0fc8d6c9 AND status.name=="Open")

    2. Fetch open requests from mod-circulation-storage via user's id: /request-storage/requests?query=(requesterId=="c926be9c-a8ce-4399-a9b3-11ec0fc8d6c9" and status=Open)   

    3. Fetch open fees/fines from mod-feesfines via user's id: /accounts?query=(userId==54f65a75-f35b-4f56-86a6-fa4a3d957e57 AND status.name="Open")        

    4. Fetch proxy info from mod-users via user's id: /proxiesfor?query=(userId=="54f65a75-f35b-4f56-86a6-fa4a3d957e57" OR proxyUserId=="54f65a75-f35b-4f56-86a6-fa4a3d957e57")        

    5. Fetch manual blocks from mod-feesfines via user's id: /manualblocks?query=(userId==54f65a75-f35b-4f56-86a6-fa4a3d957e57)
       Hence, we need to query three modules: `mod-circulation-storage`, `mod-feesfines` and `mod-users`.

  • The endpoint /bl-users/by-id/{id}/deletable returns if the user can be deleted or not. It can be deleted if totalRecords==0 for all responses of above queries.

  • The response may look like:
            {
            "userID": "uuid-1234",
            "message": "not deletable",
                          "deletable": false,
            "loans": 1,
            "requests": 0,
            "fees/fines": 2,
            "proxies": 0,
            "blocks": 0
        }
        Based on this we can conclude that the user has one open loan and 2 open fees/fines.

• In order to delete a user, add a DELETE endpoint to /bl-users/by-id/{id}
  • This endpoint first calls /bl-users/by-id/{id}/deletable (or its implementation) to check if the user can be deleted. If this is the case, it calls DELETE on /users/{id}. If the user cannot be deleted, as some above mentioned resources are pointing to this user, the response shall clarify this.
• When deleting a user from the ui, the frontend must call /bl-users/by-id/{id}.
• Another approach might be that DELETE /users/{id} calls /bl-users/by-id/{id}/deletable however this would assume mod-users needs mod-users-bl which would end in a circular dependency

...