[FOLIO-1965] API design for deletion prevention Created: 12/Apr/19  Updated: 25/Jan/23  Resolved: 25/Jan/23

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P2
Reporter: Marc Johnson Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: potential-decision, tech-debt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Blocks
blocks MODTEMPENG-15 [SPIKE] Investigate how to prohibit d... Closed
Relates
relates to FOLIO-1716 Uniquely identify backend API validat... Closed
relates to UICIRC-184 Not allow user to delete patron notic... Closed
relates to UICIRC-185 Not allow user to delete patron notic... Closed
relates to CIRC-179 in-use loan policies may be deleted Closed
relates to CIRCSTORE-121 [SPIKE] Investigate how to prohibit d... Closed
relates to FOLIO-671 Respond with descriptive information ... Closed
Sprint:
Development Team: Core: Platform

 Description   

In order to support the following user experience during deletion, with usage checks implemented in the backend

  1. click delete
  2. present modal to disallow if in use
  3. otherwise present confirmation modal
  4. attempt to delete if confirmed

At the moment, the checks for usage tend to be performed by the UI.

We need to decide:

  • What is the API for checking that a record is in-use or not (e.g. endpoint structure, responses etc)?
  • How do we provide a client meaningful response to explain why a delete fails?
  • How do we check for usage (especially when usage could be in other modules / contexts)?

Assumptions

  • Usage checks for in use will be performed during DELETE endpoint execution, as well as the mechanism we decide upon to check before issuing the delete.

Context

Some conversation around this topic has already happened on CIRC-179 Closed , CIRCSTORE-121 Closed and UICIRC-185 Closed



 Comments   
Comment by Marc Johnson [ 12/Apr/19 ]

It seems the most urgent aspect of this is to decide on an API design for how a client can determine if a record can be deleted.

I did some quick searching and it appears that this isn't a common pattern in API design, so there appears to be limited guidance available (or I'm not searching for it well).

I imagine most systems either do client based checks or refuse deletion after confirmation.

Julian Ladisch has proposed adding a nested endpoint to records named /deletable for example /loan-policy-storage/loan-policies/[loanPolicyId]/deletable

What are people's thoughts about this idea?

Are there any viable alternatives (e.g. a property or properties within the record)?

Comment by Aliaksei Chumakou [ 16/Apr/19 ]

Marc Johnson From my experience API usually checks delete availability for the item at the time of DELETE api request, and in case of deny sends error response with some additional data that could be helpful on UI to show a valuable message for end user.
In case you call a separate endpoint to check delete availability - it doesn't guarantee that item will be still available to delete on the time of actual DELETE response.
So it might be a good idea to define error codes and structure for bad responses, FOLIO-671 Closed , FOLIO-1716 Closed , so all API clients can consume them with proper UX.

Comment by Marc Johnson [ 16/Apr/19 ]

Aliaksei Chumakou Thanks for your comments

From my experience API usually checks delete availability for the item at the time of DELETE api request, and in case of deny sends error response with some additional data that could be helpful on UI to show a valuable message for end user.

That fits with my experience. There is an assumption in the above, that any checks performed prior to deletion are also performed during deletion. I will try to make that more explicit.

At the moment, the standard resource types allow DELETE to respond with 400 with a plain text body.

Reviewing whether that is sufficient is likely part of this decision. And I agree, those two issues are related to this topic.

In case you call a separate endpoint to check delete availability - it doesn't guarantee that item will be still available to delete on the time of actual DELETE response.

Indeed, it does not, the deletion itself could still fail as the circumstances have changed since the pre-check.

Generated at Thu Feb 08 23:17:12 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.