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.
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
