[Bugs] #3368 UNSP: delete in Journal detail view should prompt to confirm delete

Sugar Labs Bugs bugtracker-noreply at sugarlabs.org
Tue Mar 20 09:33:23 EDT 2012


#3368: delete in Journal detail view should prompt to confirm delete
------------------------------------------+---------------------------------
    Reporter:  walter                     |          Owner:  garycmartin                
        Type:  enhancement                |         Status:  new                        
    Priority:  Unspecified by Maintainer  |      Milestone:  Unspecified by Release Team
   Component:  design                     |        Version:  Git as of bugdate          
    Severity:  Critical                   |       Keywords:                             
Distribution:                             |   Status_field:  New                        
------------------------------------------+---------------------------------
Changes (by sascha_silbe):

  * severity:  Unspecified => Critical
  * component:  sugar => design
  * version:  Unspecified => Git as of bugdate
  * owner:  => garycmartin
  * distribution:  Unspecified =>
  * status_field:  Unconfirmed => New


Comment:

 A different option would be to support some kind of undo for the erase
 operation, making it a two-stage process. An existing metaphor for this is
 the [http://en.wikipedia.org/wiki/Recycle_bin_(computing) recycle bin],
 storing the to-be-deleted entries until they get irrecoverably removed by
 emptying the bin.

 In general, pervasive undo is a better solution than asking security
 questions: It only takes a _single_ mistake, one Yes instead of a No (or
 vice-versa) in order to do (usually irreparable) harm if you can't undo an
 action.

 Erasing may be considered an exception because general-purpose computers
 require free space on permanent memory in order to operate correctly. On
 XOs it's easy to run out of space even during normal operation; erasing
 large entries is the only way to reclaim space and make the computer
 usable again. This means we should carefully consider what a good design
 would be: Because it happens regularly, there's a high chance of mistakes
 happening (even with a two-stage approach). OTOH it must be efficient to
 use and reasonably immediate.

-- 
Ticket URL: <http://bugs.sugarlabs.org/ticket/3368#comment:2>
Sugar Labs <http://sugarlabs.org/>
Sugar Labs bug tracking system


More information about the Bugs mailing list