As described, the serious flaw has a simple fix. But that was not my point. Unless the feature was included at the whim of the dev team (in which case it can be removed at the whim of the dev team), a decision to remove it should involve the URG. What if an institution depended on it for some reason and was capable of dealing with the problem arising from re-use of the ID? My concern is not about the detail of this issue, it is about the prospect of user-facing features disappearing without consultation with URG.
John On 14 Jul 2012, at 22:27, Jon Hays wrote: > I don't think that anyone is disputing that we need it, but rather that we > figure out what to do until we have a delete feature that actually works. In > my opinion, no delete option is better than a seriously flawed one assuming > that the project circles around to fixing this feature for the next release. > > Jon > > Sent from my iPhone > > On Jul 14, 2012, at 3:03 AM, John Norman <j...@caret.cam.ac.uk> wrote: > >> 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 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
