I would suggest that adding and removing such a basic capability (even when it is so broken) is worth at least a ping to the URG/TRG.
Am I correct in interpreting that the brokenness really manifests itself only when a new world is created that has the same id as a deleted world? Is there a proposal or explanation about what would happen with worlds deleted before the capability was removed? = nate On Fri, 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
