On 22. Apr, 2013, at 17:12, Olemis Lang wrote: > 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/
Yes. > >> 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 ? Sorry, that was a typo. It's the handling of duplicate attachments described below. cons-=1 then =) > >> - most likely the attachments have to be duplicated as well - duplicate >> wikis, may confuse wiki editors >> > > do default wikis contain attachments ? It depends on what we consider "default wikis". If the wiki/Ui pages count, then yes they can contain attachments (e.g. https://issues.apache.org/bloodhound/wiki/Ui/Dashboard). This is also true if any of the Trac's default pages have been modified by the users to include 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 ? Not completely - in the above case all the wikis are moved to default product scope, and none are left in the global scope. The global dashboard would thus become empty, as opposed to (3). In the case below (3), only the custom wiki pages are moved to default product scope, the system ones (Ui & co.) are left in the global scope. > >> - 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 . True, I'm not too keen on redirects either. It would probably be better to break the links, informing the user somehow (e.g. disambiguation as proposed by Gary). > > -- > Regards, > > Olemis. -- matevz
