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. > > -- Brane > > -- > Branko Čibej > Director of Subversion | WANdisco | www.wandisco.com >
Hi, I'm continuing with this topic since there doesn't seem to be a general agreement on how the (system) wikis should function in multiproduct environments. 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? 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 - attachment handling - most likely the attachments have to be duplicated as well - duplicate wikis, may confuse wiki editors 2. Global wikis moved from global scope into default product + no wiki/attachment duplication + no broken wiki links - 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 (There are likely other possibilities, feel free to add them to the list) -- matevz
