I will move the link to Wiki Admin over to the left column and will also put a button in the same column for those that have HasManageNamespacePermission as well as a link to the TopicLocks page.
John Davidson On 10/21/07, Craig Andera <[EMAIL PROTECTED]> wrote: > > 3) What about a "Lock Topic"/"Unlock Topic" button right there in the > > right border if the user has the proper rights. Is that easy to do? It > > seems it would be nice to bubble that functionality up rather than > > forcing the user to go into the lock management page and hunt down the > > topic. > > > > Thoughts? > > I tend to agree. When I first thought of this feature, I always saw it as an > additional button in the *left* border, but one that would only appear when > the user had appropriate rights. It would read "Lock Topic" if the user was > a NamespaceManager and the topic was unlocked, and it would read "Unlock > Topic" if the user was a NamespaceManager and the topic was locked. Of > course, there's nothing wrong with having the button in the Recent Changes > page, too. > > Other comments: > > * I'm really glad to see the locking feature! Nice work. :) > > * It's a bit odd that the link to the wiki administration pages turns on > whether a user has ManageNamespace: wiki administrators and namespace > managers are potentially disjoint. I'd rather see the link to "administer > wiki" be available full-time in the left border, even for users who don't > have access. My thinking there is that it would encourage admins to secure > the /admin app, an action I imagine many wiki admins do not currently take. > > * I'm don't agree that it would be hard to add this to the SqlProvider. The > schema already supports it, and I *think* the AuthorizationProvider will > already help us with the other part, which is blowing up on write if the > topic is unreadable. The only thing we'd need to add would be > implementations of LockTopic and UnlockTopic, which would require writing > two stored procedures, or just doing direct table access if we don't want to > require a database upgrade. > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Flexwiki-users mailing list > Flexwiki-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flexwiki-users > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Flexwiki-users mailing list Flexwiki-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flexwiki-users
