> 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
