Page Comparison

...

The tickets we are working on are the following:

Jira Legacy
server FOLIO Issue TrackerSystem 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 6ccf3fe401505d01-3301b853-368a3c2e-983e90f1-20c466b11a49ee9b165564fc key UXPROD-2728

Jira Legacy
server FOLIO Issue TrackerSystem 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 6ccf3fe401505d01-3301b853-368a3c2e-983e90f1-20c466b11a49ee9b165564fc key UXPROD-2388

Jira Legacy
server FOLIO Issue TrackerSystem 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 6ccf3fe401505d01-3301b853-368a3c2e-983e90f1-20c466b11a49ee9b165564fc 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 FOLIO 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 6ccf3fe4-3301-368a-983e-20c466b11a49 key MODUIMP-33

), references-checks from different systems, 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 different systems may 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 FOLIO Issue TrackerSystem 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 6ccf3fe401505d01-3301b853-368a3c2e-983e90f1-20c466b11a49ee9b165564fc 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

...