On 22. Apr, 2013, at 17:17, Gary Martin wrote:
> On 22/04/13 13:29, Matevž Bradač 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.
>>>
>>> -- 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?
>
> As I said before, this is the approach that I would advocate. If users
> disagree then it shouldn't stop them from migrating pages to a product.
Ok, moving into that direction then.
>
>> 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.
>
> I think that it would help us to distinguish upgrade and import. For
> upgrading we could (should?) choose to leave the entire global wiki in place
> and let our users decide what they want to move into a product. For
> importing, we should probably import any global wiki into it's own project,
> and we could even ask for a name for this product in the process. Any
> products that we are importing can retain their names as long as there is no
> clash. If we don't want this to fail on those rare occasions, we can just
> append a uuid to the namespace names or something similar.
>
> Trying to think through clever solutions is probably not worth it if we can
> instead just provide appropriate tools for the users to sort themselves out.
> Cheers,
> Gary
I'm not sure what you mean by import, would this perhaps be importing an
existing Bloodhound or Trac environment into a specific product? If so
I think we should postpone resolving this for now, IIRC it should be out
of scope for upcoming releases?
For upgrade I think your proposal doesn't fit into 1-3, so we can treat
it as a separate one:
4. Leave all wikis in global scope
+ consistent with (current) clean installation behaviour
- broken ticket links (wiki -> ticket, because tickets are moved into
product scope)
- empty product dashboard (but this is minor)
I'll think about it a bit more, but this one seems to be the cleanest
solution so far.
--
matevz
