Closed Bug 636548 Opened 13 years ago Closed 12 years ago

Add "Deleted" state

Categories

(Mozilla QA :: Case Conductor-Platform, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Future

People

(Reporter: carljm, Unassigned)

References

Details

Deletions should be undoable, which requires all significant objects
(test cases, test runs, test cycles, test suites, products?) to have a
DELETED state which is the result of a DELETE call. Ideally objects in
DELETED state would, by default, not show up in the search API or any
list calls, but could still be accessed by their individual URL in order
to undo the delete if necessary.

It would also be ok, if preferred, to have a DELETE call still actually delete the object, but have another PUT call available to put the object into Deleted state.
Component: TCM → TCM-Platform
QA Contact: tcm → tcm-platform
Severity: normal → enhancement
Priority: -- → P2
I don't want to change every single GET call to filter out DELETED objects... I have to think if it's possible to globally do it...Also, I think, it should be in system configuration settings whether to make DELETEs permanent or not, not have 2 separate DELETE calls one for permanent and one for undoable....
Assignee: nobody → vadimk
(In reply to comment #1)
> I don't want to change every single GET call to filter out DELETED objects... I
> have to think if it's possible to globally do it...Also, I think, it should be
> in system configuration settings whether to make DELETEs permanent or not, not
> have 2 separate DELETE calls one for permanent and one for undoable....

Having a system setting is ok. And it wouldn't be a problem for my code to always append a search filter to filter out deleted items. My concern is about cases where the search API is not used (calls that return e.g. related items, that return an ArrayOfX rather than a SearchResult). In those cases I don't think I can use a search filter, and I'm concerned that over time deleted items could build up and cause lots of extra unnecessary bandwidth to be used. If it would be possible for all GET calls to accept a query parameter to exclude deleted items, that might even be better than automatic exclusion...
I don't want to pass any parameters like that. I'd prefer to handle it at much lower - hibernate handler - level...

In any case, I don't even remember seeing the requirements stating the need to UNDO deletes...
(In reply to comment #3)
> In any case, I don't even remember seeing the requirements stating the need to
> UNDO deletes...

Undoable delete is a hard requirement for a humane, usable UI. See e.g. http://www.alistapart.com/articles/neveruseawarning/
(In reply to comment #4)
> (In reply to comment #3)
> > In any case, I don't even remember seeing the requirements stating the need to
> > UNDO deletes...
> 
> Undoable delete is a hard requirement for a humane, usable UI. See e.g.
> http://www.alistapart.com/articles/neveruseawarning/

This very well may be, but there are plenty of apps commercial and not out there deleting objects left and right without the undo capability. So, unless it's defined in the business requirements, I don't see the need to implement it now. It could be put on the future wish list if needed.
(In reply to comment #5)
> This very well may be, but there are plenty of apps commercial and not out
> there deleting objects left and right without the undo capability. So, unless
> it's defined in the business requirements, I don't see the need to implement it
> now. It could be put on the future wish list if needed.

I don't know what "defined in the business requirements" means. We can put it in a document if that would help. Roy affirmed the need for it in an email a few weeks ago...
(In reply to comment #6)
> (In reply to comment #5)
> > This very well may be, but there are plenty of apps commercial and not out
> > there deleting objects left and right without the undo capability. So, unless
> > it's defined in the business requirements, I don't see the need to implement it
> > now. It could be put on the future wish list if needed.
> 
> I don't know what "defined in the business requirements" means. We can put it
> in a document if that would help. Roy affirmed the need for it in an email a
> few weeks ago...

"defined in the business requirements" means it's specifically asked for before development starts. Like they specifically asked to version test cases and didn't want to version anything else. Any comments made via email at this point in time have nothing to do with planned deliverables. 

Like I said earlier, it could be added to the future wish list, but it's definitely not a valid requirement for the current version.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
We have no other place to track future wishlist items, so this should remain open. Marking it target milestone "future" for now.
Status: RESOLVED → REOPENED
Priority: P2 → --
Resolution: INVALID → ---
Target Milestone: 0.2 → Future
OK
Assignee: vadimk → nobody
A Pivotal Tracker story has been created for this Bug: http://www.pivotaltracker.com/story/show/17765573
Roy Solomon added a comment in Pivotal Tracker:   
   
Estimated in about 3 days but we need to spend more time on evaluate a simple solution.
Cameron Dawson added a comment in Pivotal Tracker:   
   
sounds good.  Is that evaluation on uTest side only?  Or do you want to work that out with the rest of the team?
Vadim Kisen changed story state to started in Pivotal Tracker
Cameron Dawson added a comment in Pivotal Tracker:   
   
Vadim, if this is something that ends up being pretty hard, and you aren't too deep in it yet, we could prioritize this lower.
Vadim Kisen added a comment in Pivotal Tracker:   
   
I'm almost done with this and will be delivering it shortly. Accessing deleted object by its URL will not return the object and will throw 404 Not Found error. Otherwise, it would lead to mistakes where people keep using deleted entities without any errors thrown.  

I'll need to add special URLs to Search for deleted entities and Undo Deletes.
Vadim Kisen changed story state to finished in Pivotal Tracker
Vadim Kisen changed story state to delivered in Pivotal Tracker
Vadim Kisen added a comment in Pivotal Tracker:   
   
OK, I've pushed all the changes related to this story. I added  
ability to undo deletes and search for majority of deleted entities.

To search for deleted entities new URLs append /deleted/ to the main search URL, i.e. ..../products/deleted/

To undo a delete new URL is similar to @DELETE URL with appended /undo_delete/, i.e. .../products/{id}/undo_delete/

I also added a section to README explaining how to turn on/off undoable deletes for the application.

I recommend to limit the use of this feature to a minimum, preferably to a user with special admin rights. So, it won't become a normal case to delete things all the time to only recover them later...
Carl Meyer changed story state to accepted in Pivotal Tracker
Status: REOPENED → RESOLVED
Closed: 13 years ago12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.