I was thinking more from a "data integrity" standpoint. Deletes can destroy data just as thoroughly as a series of renames that do or do not work.
On 9/12/07, Craig Andera <[EMAIL PROTECTED]> wrote: > > Just to toss some gas on the fire, I'd say that "delete" falls in this > > category as well. > > How is delete fundamentally different from editing a page to contain > nothing? I realize that there's some difference (unlinking) but I'm leery of > making any change that requires modifications to the security model: it took > forever to get it to the point it is now, which I believe to be fairly > elegant and reasonably easy to understand. > > Rename is fundamentally different because it's a *batch operation*. That's > actually why it's a problem: because it makes something easier to do than to > undo. If we were to have real changesets ala some of the more sophisticated > SCC systems (FlexWiki is a version control system), then undo would be > trivial, and the problem would be much less severe. > > So there are two solutions to the problem: > > 1) Make it easier to undo batch changes. Perhaps a "roll back wiki to point > in time" administrative function. Or "undo all changes for user X". Or some > combination. Or go completely insane and implement changesets or atomic > operations (unlikely). > 2) Restrict who can use rename. > > IIRC, we've already got a simple version of #2, in that I believe you can > turn off rename altogether via configuration. After thinking about it for a > few minutes, I think it would be reasonable to add permissions for rename > based on namespace permissions. You'd add a property, let's call it > "AllowRename" and set it to one of three values: "all", "NamespaceEditors", > "NamespaceManagers". If set to "all", anyone could rename. If set to > "Editors", then only people with edit permission at the namespace level > could use rename. If set to "NamespaceManagers", then only people with > ManageNamespace could use rename. > > In truth, we could probably get by with just "all" and "NamespaceManagers" > because it's unlikely that rename would work for anyone without Edit anyway > - rename is implemented by the web app, not by the engine, and as such the > engine just sees it as a series of edits against topics, so you need edit on > every page you're trying to modify [1]. This is another reason I think it's > a bad idea to add a special permission for rename: because it would cut > across layers. > > Anyway, if you did that, you'd have the ability to restrict rename to be > either a) essentially an administrative function or b) a convenience for > users with edit permission. On an authenticated wiki (b) is probably good > enough. On a public wiki (a) is probably good enough. Adding in some sort of > namespace-level rollback functionality would cover 80% of the remaining 20% > after that. > > [1] In fact, there's a minor bug in rename right now such that if you do a > rename with update and you only have permission to edit some of the topics, > the rename will barf partway through, having updated only some topics. > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Flexwiki-users mailing list > Flexwiki-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flexwiki-users > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Flexwiki-users mailing list Flexwiki-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flexwiki-users
