I would put this more strongly than Nate. I assume the delete function was put in as a response to some important user need identified by the URG. As such it should not be removed without consultation with URG.
John On 13 Jul 2012, at 19:17, Lance Speelmon wrote: > +1 turn it off for now. Thanks, L > > On Jul 13, 2012, at 10:54 AM, Zach A. Thomas <zach.tho...@gmail.com> wrote: > >> I like Ray's proposal, and removing the delete button is certainly lower >> risk than adding the new code right at the end of the release cycle. >> >> Is it a deal-breaker for anyone if we turn this off? >> >> Zach >> On Jul 12, 2012, at 3:15 PM, Ray Davis wrote: >> >>> Answering Zach's main question as the original complainant: >>> >>>> Here's is my main question (thank you for your patience!): I think I >>> need more time to build a proper cleanup solution than we have left for >>> the upcoming release (1.4.0). Should I >>>> a) just defer this work until post-1.4.0, leaving everything as >>> broken as it is now >>>> b) Implement the "on hold" list now to prevent names of worlds which >>> have been deleted from being reused >>>> c) Something else I haven't thought of >>> >>> c) Disable the UX for World deletion but continue to make Group >>> Authorizable deletion available through Curl for essential >>> administrative tasks or scripts which can deal with the consequences. >>> Leaving the current UX in front of (a) or (b) seems to promise things >>> that won't be delivered. >>> >>> Best, >>> Ray >>> >>> On 7/12/12 11:29 AM, Zach A. Thomas wrote: >>>> Hi, all. I've been working on >>>> https://jira.sakaiproject.org/browse/KERN-2586 which is about what happens >>>> (or doesn't happen) when we delete a world. >>>> >>>> This turns out to be pretty convoluted, so I'd like some feedback on it. >>>> >>>> Here's the basic problem: in the current OAE release, you can delete a >>>> world using the little gear menu. It produces a command similar this curl >>>> statement: >>>> >>>> curl -u admin:password -F:applyTo=somegroup >>>> http://example.com/system/userManager.delete.json >>>> >>>> But all that happens is we remove the Authorizable for somegroup. >>>> somegroup's home folder and everything within it is intact, all the access >>>> controls that somegroup was ever granted are still in place, and >>>> everywhere that somegroup is mentioned (such as in the membership lists of >>>> content and groups) remains unchanged. >>>> >>>> If someone comes along later and creates a new world and they happen to >>>> use the old name, they'll have the old world's library, home folder, etc. >>>> In short, it's an awful mess. >>>> >>>> We don't have the ability to do a cascading delete, as we would do in a >>>> relational database. For a proper delete, we're going to want to crawl >>>> through every bit of data and remove references to the former world. Since >>>> this is time-consuming, we would want this to happen asynchronously in a >>>> background operation (think of a Roomba, slowing scooching around your >>>> house). >>>> >>>> While we're waiting for a proper cleanup, I think we're going to want to >>>> put a "hold" on that id for any future world creation. We can do this by >>>> just storing a simple list of ids somewhere, and consulting that list when >>>> creating new worlds. >>>> >>>> Here's is my main question (thank you for your patience!): I think I need >>>> more time to build a proper cleanup solution than we have left for the >>>> upcoming release (1.4.0). Should I >>>> a) just defer this work until post-1.4.0, leaving everything as broken as >>>> it is now >>>> b) Implement the "on hold" list now to prevent names of worlds which have >>>> been deleted from being reused >>>> c) Something else I haven't thought of >>>> >>>> I have almost finished the "on hold" functionality. We just need an >>>> endpoint like the "user exists" servlet for usernames. >>>> >>>> thanks, >>>> Zach >>>> _______________________________________________ >>>> oae-dev mailing list >>>> oae-dev@collab.sakaiproject.org >>>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev >>>> >>> >>> >>> _______________________________________________ >>> oae-dev mailing list >>> oae-dev@collab.sakaiproject.org >>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev >> >> _______________________________________________ >> oae-dev mailing list >> oae-dev@collab.sakaiproject.org >> http://collab.sakaiproject.org/mailman/listinfo/oae-dev > > _______________________________________________ > oae-dev mailing list > oae-dev@collab.sakaiproject.org > http://collab.sakaiproject.org/mailman/listinfo/oae-dev John Norman Director - CARET University of Cambridge j...@caret.cam.ac.uk +44-1223-765367
_______________________________________________ oae-dev mailing list oae-dev@collab.sakaiproject.org http://collab.sakaiproject.org/mailman/listinfo/oae-dev
