In this discussion, I think there are two capabilities that are not being clearly distinguished.
First, there's the ability to rename a single page. Second, there's the ability when you rename a single page to have the system go find all the references to that page and change them to refer to the newly named page. I have seen how this second feature has created problems. There are two problems I've seen. The first is that sometimes people rename pages in an ugly or confusing way (e.g., PlayPage becomes IOIQUHIQUHEOIUHEIQUHEOIQH). The second is that the renamed page could have its new name include characters that made it difficult or impossible to get to that page -- a problem compounded if all the referencing pages also get updated (since that sure makes it hard to simply rename it back). I'd like to challenge the folks on the list to be very clear about what the problem is before we go off into solutions. Are there other problems beyond the two that I've mentioned? > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:flexwiki- > [EMAIL PROTECTED] On Behalf Of Craig Andera > Sent: Wednesday, September 12, 2007 5:26 AM > To: 'FlexWiki Users Mailing List' > Subject: Re: [Flexwiki-users] Access to Rename Functionality > > > 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/flexwiki-users
