On 28/03/13 08:51, Jure Zitnik wrote:
Hi,
I would like to clarify how we want to handle wikis during install and
upgrade. This is related to ticket #406, database upgrade to
multiproduct.
Currently this is how things are implemented ('system' wikis are wikis
that we bundle/pre-install):
1. clean install:
- 'system' wikis are being imported into global context
- default product does not have any of the 'system' wikis, wiki list
is empty
2. upgrade (when upgrading to multiproduct):
- existing wiki pages (all of them, including 'system' ones) are
migrated into the default product
- as a consequence of that, global context is (after upgrade) left w/o
any wikis
This is a problem as the results of the above are not consistent.
In my opinion we should have consistent setup of 'system' wikis,
regardless of whether user has just done a clean install or upgraded
an existing environment. They should always reside in global context.
Therefor I would suggest the following:
- keep the clean install as it is
- during upgrade, migrate only 'non-system' (custom) wikis to default
product
- redirect all URLs targeting 'system' wikis in any product scope to
global scope wikis - this won't break links to 'system' wikis from
custom ones
Open questions are:
- how to get a list of 'system' wikis? Setup enumerates wikis that are
being imported (trac+bloodhound) using 'os.listdir()'. We could IMO do
the same during upgrade, the problem is that 'trac-admin wiki
bh-upgrade' renames the wikis later on, so we'd need to do the same.
- redirecting URLs from product scope to global one actually reserves
'system' wiki namespace within all product scopes
- what happens to wiki index (TitleIndexMacro) in the default product
and global context?
Any comments/opinions?
Cheers,
Jure
Sorry if this response is a little late.
I am not all that keen on redirecting straight to a global system wiki
page and I don't like the idea of customised system pages being
completely dropped from products.
There are quite a number of approaches that we could take but I think that:
* explicitly use global system wiki pages for UI links
* on import/migration, move conflicting product system pages so that
they are still available but under a different path
* let existing links to the moved pages break and show the missing
page/disambiguation page view instead
would probably work well enough and should not be a huge amount of work.
Under these conditions, no automatic redirection is required for missing
pages as the normal missing page system can be used. The missing page
view would probably require enhancement to show similarly named pages
across all products to which a user has access.
This approach also saves us having to worry about reserving the system
page names: if a user adds a product wiki page with a global system page
name, that could just be considered their own fault for causing
additional confusion!
We would probably still need to get the list of system pages so that
they can be moved and we will probably want to update the
TitleIndexMacro to include at least the global system pages, and
possibly even all global pages that the user has appropriate permissions
to view.
Later on I would quite like to extend the disambiguation concept,
possibly by adding disambiguation pages to show those wiki pages that
are accessible to the user that might have been intended. This can
almost certainly wait for a bit when the least we appear to need to do
is enhance the missing page view.
Finally, if anyone wants the possibility of per product custom system
pages, perhaps we could look to see if we can add this ability later. I
am not entirely sure how useful that will actually turn out to be and
there may be better solutions for situations like alternative language
versions of pages.
Does any of that make sense?
Cheers,
Gary
