On 23. Apr, 2013, at 16:49, Gary Martin wrote:
On 23/04/13 10:45, Matevž Bradač wrote:
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:
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?
That is probably fair for now. I imagine that eventually users may want
to consolidate separate installations into a single database (be that
individual trac environments into a single new product or bloodhound
environments into, potentially, multiple products). Of course, I may be
wrong.
I completely agree, it's one of the use cases we eventually have to cover,
there just wasn't much emphasis or focus on import so far.
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.
While this might be a little off the current topic, I am still not
entirely sure of the reason to move tickets into a different scope unless
the users choose to do this. Providing the means for a user to easily
migrate the global product tickets and optionally a wiki into a new product
makes a bit more sense to me. Until a user explicitly does this, why would
we need the tickets to be in anything other than the null product? Another
nice aspect of this approach is that the wiki -> ticket links should remain
available once users decide to move tickets into a different product as I
believe previous links are meant to remain as synonyms specifically to
maintain old links; the very fact that the tickets were in the null product
should mean that they can still be referred to as if they are still in the
null product. Redirection in this sense should be fine with the caveat that
permissions of the current product in which the ticket resides should be
respected.
Wouldn't this bring us back to square one though? Global environment is
currently considered as a "parent" to all product environments, and as
such
it allows for global configuration which specific products then inherit.
If
we change the role of the global environment to being "just a product",
we'd
have to rethink on how to handle global configuration. It's certainly
doable,
but likely at a substantial cost (design- and implementation wise).
But that's just my opinion, I'll wait for others to chime in. =)
