Skip to content
Snippets Groups Projects

WS-85: Delete capability request REST endpoint

Merged Nathan Hertz requested to merge WS-85-delete-capability-request-rest-endpoint into main
1 unresolved thread

Added new REST endpoint for deleting capability requests; requests with existing executions cannot be deleted (they must be disabled instead--like with capabilities, which will have to be implemented)

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
177 177 def save_execution(self, execution: CapabilityExecutionIF):
178 178 self.session.add(execution)
179 179 transaction.commit()
180
181 def delete_request_versions(self, request_id: int) -> int:
  • this is good, but I'm not seeing where any executions are also deleted? Did I miss something?

  • Nathan and I talked about that one-on-one, but basically, you don't want to actually delete a request if it has executions. For the time being it's OK to just error in that case. We should probably add another disable/enable pair on this for requests that have executions, because someone just doesn't want to see it anymore.

  • Yeah, that makes sense. If it's done work we don't want to disappear it. As long as enable/disable and delete don't become VLASS remain two completely separate functionalities I'm good with this.

  • When we add versions, we need to make sure that the states all make sense and only permit things in the way we want them to. But until we have versions I see no particular reason to fuss too much about it—do it the easy wrong way rather than a harder wrong way.

  • yeah, we can flush out the functionality for this better when we actually have the entire structure to work with

  • Please register or sign in to reply
  • Charlotte Hausman approved this merge request

    approved this merge request

  • merged

  • Please register or sign in to reply
    Loading