Some extra remarks inline: On Fri, Apr 20, 2012 at 9:28 AM, Branden Visser <[email protected]> wrote: > Thanks for the info Clay. > > On Fri, Apr 20, 2012 at 8:20 AM, Clay Fenlason > <[email protected]> wrote: >> Also IIUC, we really are just talking about Sakai documents and not >> other forms of content, right? > > If we were to make a change that WRITE permission implies deletion of > children, then this applies to all content in our storage, not just > sakai documents. The issue I'm currently dealing with AFAIK is only > currently exposed on Sakai Docs though, as the other forms of content > appear to be "flat" (aside from things like activity records, which > are stored as children of content).
Right, that's what I meant. In principle it applies to all content, but de facto: it's Sakai docs that are the real issue. One thing to watch out for, however, is whether the APIs or curl commands can remove things like preview thumbnails (which I think are also child nodes?) or activity records. In our experience, users do not distinguish between a file's contents and its preview images. While this is generally a good thing, there is also rich potential for pranksterism, malicious or otherwise. >> My understanding is that content >> collections are not implemented with collection items as children of a >> collection node. Also that uploaded files and external links do not >> have children (is this true? And will it still be true when >> annotations are implemented?) >> > > Collections don't nest their content, and uploaded files and external > links only have activity feed information as children. I'm not sure > what annotations are, but a quick Google search leads me to believe > maybe I should subscribe to the oae-urg list. I only meant to suggest that I don't know how it was imagined that annotations and their versions might be stored when those features get implemented, and as with preview images (above) it might be worth thinking about the potential for mischief. Subscribing to the oae-urg list isn't a bad idea. Talking to Nico would be better. I suspect I might be only filling space until Nico replies to this thread with better answers. > Off the top of my head, > threaded discussions operate without nested content, so my assumption > is that annotations could be designed not to nest as well. > > On that note, discussion messages/comments are nested in a page. It > would probably be a good idea to deny delete on the messages parent > content, as AFAIK there is no use case to permanently delete any of > that data any way. Right, but this is not unique to discussions, but applies also to all widgets? It's a fair question whether the user expectation of collaborative editing involves the existence, settings, or content of embedded widgets. Off the cuff, and allowing for future widgets we haven't yet imagined, I'm not sure I know the answer. But given that uncertainty, my instinct would be to say that child widgets should not be deleted, lest their content be lost. ~Clay _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
