On 4/22/13, Matevž Bradač <[email protected]> wrote: > > On 1. Apr, 2013, at 17:54, Branko Čibej wrote: > >> On 01.04.2013 17:43, Gary Martin wrote: >>> On 01/04/13 13:18, Andrej Golcov wrote: >>>> Just want to mention a couple of problems that I see with transparent >>>> redirecting of wiki pages from a product scope to the global scope: >>>> - user potentially may not have WIKI_VIEW permission for global scope >>>> - one more thing to care about >>>> - user loses product context - no tickets links, different wiki >>>> index etc. >>>> >>>> What are major drawbacks if system wiki pages are located inside >>>> products scope, at least from UI prospective? >>>> >>>> Cheers, Andrej >>> >>> In a sense there is no specific extra drawback to having system wiki >>> pages within each product that we did not already have. I don't think >>> that the extra size of the database is a huge issue for example. >>> >>> If we ignore all aspects of the problem associated with potential >>> modifications and deletes of system wiki pages then there is a clear >>> advantage that we don't have to worry about the permissions of the >>> global product being restricted. Each wiki upgrade would of course >>> mean that all products would have to update their wiki to get new >>> versions of pages. >>> >>> This is certainly a legitimate approach (even if I was advocating the >>> opposite) and should also work as a good temporary solution if we feel >>> we need to tackle other related issues later. The only thing that >>> think I would insist on in this is making sure that upgrade or import >>> of products would respect old versions of the pages - this should be >>> updating the pages rather than replacing so that the historic versions >>> are available. >>> >>> I don't think I can recommend redirection at the moment, transparent >>> or otherwise. It is not clear to me that it solves a problem that >>> users will find that they care about. I am assuming that other >>> solutions should be less work though. >> >> I think everyone is focusing a bit too much on implementation details >> and failing to ask the important question, which is: what role do system >> wiki pages play in a multiproduct setup? >> >> Answer that question, and most of the debate falls by the wayside. >> >> 1. If system wiki pages are meant to support the whole BH installation, >> then I see no good reason for anyone but system admins to be able to >> modify them. There's potentially room for a new role here (system >> wiki admin), that could only modify the system wiki, but not other >> aspects of the system-wide setup; however, that's not an immediate >> concern, IMO. >> 2. On the other hand, if these "system wiki" pages are modifiable by >> /product/ admins, or even ordinary users who have access to a >> product, then it follows that each product can have its own version >> of those pages, which implies these are no longer "system" pages at >> all and you're back to square one -- deciding what to do with the >> "real" system wiki pages, and whether or not they even exist. >> >> >> IMO, pick one; but I suspect that #1 is the saner alternative. >> [...] > > As Brane pointed out, it's firstly a decision on what role system wikis > should assume. I'm leaning more towards #1, as having an > installation-wide wiki may make sense, even if products are not directly > connected with each other. Should we move in that direction? >
FWIW , when you say «installation-wide wiki» I assume you mean something like /sourceforge Trac instance , isn't it ? http://sourceforge.net/apps/trac/sourceforge/ > The second issue would be how to handle wikis form the installation and > upgrade point of view. Before multiproduct (MP) support, there was only > one set of wiki pages to handle. With MP however, each product now gets > its set of wiki pages, plus there is also a global scope which may (or > may not) be used for system-wide wikis. Below are a few possibilities, > along with their pros and cons: > > 1. Global wikis left in place, but also copied into default product > + upon installation or upgrade, both global and product dashboard > function as before > + no broken wiki links + fits well in (sub)domain deployments . > - attachment handling what the problem with this ? > - most likely the attachments have to be duplicated as well - duplicate > wikis, may confuse wiki editors > do default wikis contain attachments ? > 2. Global wikis moved from global scope into default product > + no wiki/attachment duplication > + no broken wiki links I guess this is compared to (3) below , isn't it ? > - empty global dashboard (but this may be populated with links to > product wikis, depending on how we decide to handle system wikis) > > 3. "System" wikis from global scope are left in place, custom wikis > moved to default product > + global dashboard works as before (except for the links, see below) > - product dashboard is empty (but this isn't a major issue IMO) > - links between product and system wikis are broken. This can be resolved > with either Jure's proposal (always redirect 'system' wikis to global > scope), or Gary's (break the links to custom product wikis, so reserving > system page names would not be needed). > - system wikis may have been changed by existing Bloodhound/Trac users, > how should the upgrade of those be handled > Looks complicated , especially in (sub)domain deployments as such redirections will take users out of sub-domain to browse a different domain . -- Regards, Olemis.
