You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Jure Zitnik <ju...@digiverse.si> on 2013/03/28 09:51:36 UTC
[BEP-0003] Wiki install vs. upgrade
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
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Matevž Bradač <ma...@digiverse.si>.
On 28. Mar, 2013, at 9: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
Agreed, this does make more sense. Landing on a blank page after upgrade IMO doesn't look very promising to the user.
>
> 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.
I suppose the ones in trac/wiki/default-pages are all 'system' ones.
> - redirecting URLs from product scope to global one actually reserves 'system' wiki namespace within all product scopes
I don't see this as much of a drawback.
> - what happens to wiki index (TitleIndexMacro) in the default product and global context?
For the global context it may make sense to also list the links to products' title indexes.
>
> Any comments/opinions?
>
> Cheers,
> Jure
>
>
--
matevz
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Peter Koželj <pe...@digiverse.si>.
Solution sound good to me.
Thoughts on opened questions are among your text.
On 28 March 2013 09:51, Jure Zitnik <ju...@digiverse.si> 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.
>
We should maintain the list manually. It should be done that way from the
start.
> - redirecting URLs from product scope to global one actually reserves
> 'system' wiki namespace within all product scopes
>
I do not see this a mayor drawback as they are "reserved" in current
(nonmultiproductized) environment already.
> - what happens to wiki index (TitleIndexMacro) in the default product and
> global context?
>
> Any comments/opinions?
>
> Cheers,
> Jure
>
>
>
Default access permissions and views (Was: Re: [BEP-0003] Wiki install
vs. upgrade)
Posted by Gary Martin <ga...@wandisco.com>.
On 02/05/13 18:12, Olemis Lang wrote:
> On 5/2/13, Gary Martin <ga...@wandisco.com> wrote:
>> On 02/05/13 15:15, Joachim Dreimann wrote:
>>> Every registered user should be allowed to see the Dashboard.
>>>
>>> The Dashboard may be empty if the user has no permissions to see anything
>>> else. Just as it is on a new installation with no information yet.
>>>
>>> Empty should not mean a blank page, but one helping to get started, learn
>>> more, how to request permissions, whatever the case may be.
>> When you say that every registered user should be allowed access that
>> would suggest that there are situations where anonymous users should not
>> be able to see the page. Unless you are attempting to argue for no
>> constraints on access then using a permission to specify local policy
>> would be consistent with the normal approach elsewhere.
>>
>> It looks like DASHBOARD_VIEW might be the obvious permission to use for
>> this but we could make it so that DASHBOARD_VIEW is automatically
>> granted by TICKET_VIEW. This would deny the ability to distinguish the
>> two permissions without using fine grained permissions though.
>>
> Considering the fact that there is a proposal and working patch for
> customized dashboards (see #140) I'd rather prefer DASHBOARD_VIEW
> since not all dashboards might be about tickets .
That would not be inconsistent with my suggestion. You could remove
TICKET_VIEW and add DASHBOARD_VIEW to a user in order to keep seeing the
dashboard. It could just be handy to additionally use a permission that
is already provided by default.
I am also beginning to wonder how useful PRODUCT_VIEW is going to be. I
will have to read up on the current proposals again.
Cheers,
Gary
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Olemis Lang <ol...@gmail.com>.
On 5/2/13, Gary Martin <ga...@wandisco.com> wrote:
> On 02/05/13 15:15, Joachim Dreimann wrote:
>> Every registered user should be allowed to see the Dashboard.
>>
>> The Dashboard may be empty if the user has no permissions to see anything
>> else. Just as it is on a new installation with no information yet.
>>
>> Empty should not mean a blank page, but one helping to get started, learn
>> more, how to request permissions, whatever the case may be.
>
> When you say that every registered user should be allowed access that
> would suggest that there are situations where anonymous users should not
> be able to see the page. Unless you are attempting to argue for no
> constraints on access then using a permission to specify local policy
> would be consistent with the normal approach elsewhere.
>
> It looks like DASHBOARD_VIEW might be the obvious permission to use for
> this but we could make it so that DASHBOARD_VIEW is automatically
> granted by TICKET_VIEW. This would deny the ability to distinguish the
> two permissions without using fine grained permissions though.
>
Considering the fact that there is a proposal and working patch for
customized dashboards (see #140) I'd rather prefer DASHBOARD_VIEW
since not all dashboards might be about tickets . Indeed , that's what
we use since some time ago (afaics last commit = 2012-12-17 ) .
https://bitbucket.org/jose_angel_franco/bloodhound-dashboard/compare/t140_dynamic_layout_widgets_configuration..#Lbhdashboard/api.pyF108T141
> Your point about the empty page is good but it may be appropriate to
> allow the information there to be fairly customisable so that the empty
> view can be made to show information appropriate to the site.
>
Interesting
--
Regards,
Olemis.
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Gary Martin <ga...@wandisco.com>.
On 02/05/13 15:15, Joachim Dreimann wrote:
> Every registered user should be allowed to see the Dashboard.
>
> The Dashboard may be empty if the user has no permissions to see anything
> else. Just as it is on a new installation with no information yet.
>
> Empty should not mean a blank page, but one helping to get started, learn
> more, how to request permissions, whatever the case may be.
When you say that every registered user should be allowed access that
would suggest that there are situations where anonymous users should not
be able to see the page. Unless you are attempting to argue for no
constraints on access then using a permission to specify local policy
would be consistent with the normal approach elsewhere.
It looks like DASHBOARD_VIEW might be the obvious permission to use for
this but we could make it so that DASHBOARD_VIEW is automatically
granted by TICKET_VIEW. This would deny the ability to distinguish the
two permissions without using fine grained permissions though.
Your point about the empty page is good but it may be appropriate to
allow the information there to be fairly customisable so that the empty
view can be made to show information appropriate to the site.
Cheers,
Gary
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Joachim Dreimann <jo...@wandisco.com>.
Every registered user should be allowed to see the Dashboard.
The Dashboard may be empty if the user has no permissions to see anything
else. Just as it is on a new installation with no information yet.
Empty should not mean a blank page, but one helping to get started, learn
more, how to request permissions, whatever the case may be.
On 1 May 2013 10:28, Gary Martin <ga...@wandisco.com> wrote:
> On 01/05/13 01:42, Olemis Lang wrote:
>
>> On 4/30/13, Anze Staric <an...@gmail.com> wrote:
>>
>>> Both product list and global dashboard currently require PRODUCT_VIEW
>>> permission in global context and are therefore not visible to
>>> anonymous users.
>>>
>>> Are there any unwanted consequences if we grant this permission to all
>>> users (in global env) during the upgrade?
>>>
>>> Please do not do that . It's annoying when upgrades hijack the
>> decisions made by admins + users ... especially when it comes to
>> security & permissions which might compromise the stability ,
>> confidentiality policies , ... of certain environments .
>>
>>
> Olemis is right in principle. We should never be setting user permissions
> on an upgrade.
>
> I am not convinced that PRODUCT_VIEW is the correct permission for showing
> this page as a whole. Although in a sense it is still messing with
> decisions on permissions, we could change it to TICKET_VIEW. If it is not
> already in place we also need to make sure that we are able to determine
> which products a user should have access to along with respecting the
> permissions of anything within each product that might get displayed.
>
> Cheers,
> Gary
>
--
Joe Dreimann | *User Experience Designer* | WANdisco<http://www.wandisco.com/>
@jdreimann <https://twitter.com/jdreimann>
*
*
*Join one of our free daily demo sessions on* *Scaling Subversion for the
Enterprise <http://www.wandisco.com/training/webinars>*
THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE
PRIVILEGED. If this message was misdirected, WANdisco, Inc. and its
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege.
If you are not the intended recipient, please notify us immediately and
destroy the message without disclosing its contents to anyone. Any
distribution, use or copying of this e-mail or the information it contains
by other than an intended recipient is unauthorized. The views and
opinions expressed in this e-mail message are the author's own and may not
reflect the views and opinions of WANdisco, unless the author is authorized
by WANdisco to express such views or opinions on its behalf. All email
sent to or from this address is subject to electronic storage and review by
WANdisco. Although WANdisco operates anti-virus programs, it does not
accept responsibility for any damage whatsoever caused by viruses being
passed.
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Gary Martin <ga...@wandisco.com>.
On 01/05/13 01:42, Olemis Lang wrote:
> On 4/30/13, Anze Staric <an...@gmail.com> wrote:
>> Both product list and global dashboard currently require PRODUCT_VIEW
>> permission in global context and are therefore not visible to
>> anonymous users.
>>
>> Are there any unwanted consequences if we grant this permission to all
>> users (in global env) during the upgrade?
>>
> Please do not do that . It's annoying when upgrades hijack the
> decisions made by admins + users ... especially when it comes to
> security & permissions which might compromise the stability ,
> confidentiality policies , ... of certain environments .
>
Olemis is right in principle. We should never be setting user
permissions on an upgrade.
I am not convinced that PRODUCT_VIEW is the correct permission for
showing this page as a whole. Although in a sense it is still messing
with decisions on permissions, we could change it to TICKET_VIEW. If it
is not already in place we also need to make sure that we are able to
determine which products a user should have access to along with
respecting the permissions of anything within each product that might
get displayed.
Cheers,
Gary
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Olemis Lang <ol...@gmail.com>.
On 4/30/13, Joachim Dreimann <jo...@wandisco.com> wrote:
> On 29 April 2013 18:18, Olemis Lang <ol...@gmail.com> wrote:
>
[...]
>> IMHO one of the following options :
>>
>> 1. user dashboard aggregating and summarizing user
>> activity across products would be ok e.g. similar to Bitbucket's .
>> 2. products list
>>
>
> I'm not familiar with Bitbucket's view,
http://blog.bitbucket.org/2013/03/04/the-new-bitbucket-dashboard-all-your-code-activity-all-in-one-place/
https://bitbucket.org/olemis
https://bitbucket.org/olemis/profile/activity
> but option one is what the
> Dashboard is intended to do. It includes a products list already (visible
> when more than one product exists).
>
;)
--
Regards,
Olemis.
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Olemis Lang <ol...@gmail.com>.
On 4/30/13, Anze Staric <an...@gmail.com> wrote:
> Both product list and global dashboard currently require PRODUCT_VIEW
> permission in global context and are therefore not visible to
> anonymous users.
>
> Are there any unwanted consequences if we grant this permission to all
> users (in global env) during the upgrade?
>
Please do not do that . It's annoying when upgrades hijack the
decisions made by admins + users ... especially when it comes to
security & permissions which might compromise the stability ,
confidentiality policies , ... of certain environments .
--
Regards,
Olemis.
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Anze Staric <an...@gmail.com>.
Both product list and global dashboard currently require PRODUCT_VIEW
permission in global context and are therefore not visible to
anonymous users.
Are there any unwanted consequences if we grant this permission to all
users (in global env) during the upgrade?
Anze
On Tue, Apr 30, 2013 at 10:38 AM, Joachim Dreimann
<jo...@wandisco.com> wrote:
> On 29 April 2013 18:18, Olemis Lang <ol...@gmail.com> wrote:
>
>> Hi !
>>
>> On 4/29/13, Joachim Dreimann <jo...@wandisco.com> wrote:
>> > On 29 April 2013 12:57, Gary Martin <ga...@wandisco.com> wrote:
>> >> On 29/04/13 11:42, Anze Staric wrote:
>> >>
>> >>> Upgrading wikis to multiproduct now moves all wikis (and attachments)
>> >>> to default product. As a result, the main page ('/') is blank, as the
>> >>> page WikiStart does not exist in the global product.
>> >>>
>> >>> If a user plans to create multiple products, this is not a big
>> >>> problem, as he will probably need a new entry page anyway. We could
>> >>> add one of the guides as a WikiStart page in global env to avoid
>> >>> PageNotFound error.
>> >>>
>> >>> But if a user does not need multiple products (he just upgraded to
>> >>> bloodhound because of our other awesome features), how should he
>> >>> proceed? Should we provide a way to enable mapping of wikis in default
>> >>> product to global namespace (the way we do with tickets, reports,
>> >>> ...)? Or should such users just disable the multiproduct module in
>> >>> trac.ini?
>> >>
>> [...]
>> >>
>> >> We could suggest that if an installation is only ever expected to be a
>> >> single product installation then webserver configuration could be used
>> to
>> >> hide the global level. I think that a proper installation should include
>> >> a
>> >> webserver rather than using tracd directly. It might be possible to
>> offer
>> >> the opportunity to have non-multiproduct version if this decision is
>> made
>> >> early in the installation procedure as it may be more difficult to
>> switch
>> >> away later. If we were to support this then we would need more testing
>> to
>> >> be put in place of course to cover that possibility.
>> >>
>> >
>>
>> Notice that the global home page belongs to a given (global)
>> environment . So `[trac]` `default_handler` config option will be
>> handy . We could set that to `products` in global scope .
>>
>> > I don't believe we should provide a 'single product only' installation
>> > option, if that's your suggestion. More complication for little gain.
>>
>> IMO this comment is influenced by a «developer» perspective . IMHO
>> from a user perspective , things should be as backwards compatible as
>> possible . For instance , via trac-users we have received requests for
>> porting Bloodhound Search and Dashboard plugins to work on top of Trac
>> core ... without multi-product
>>
>> > Users
>> > that are so opposed to potentially using multiple products in future that
>> > they want to decide at the point of installation to not use them should
>> use
>> > Trac instead.
>> >
>>
>> ... maybe that's a valid approach .
>>
>> >
>> >> Meanwhile, I think putting in a new WikiStart page for the global
>> >> frontpage would be pretty reasonable. We might consider listing the
>> >> products on that page in some way along with any other default text we
>> >> want
>> >> to provide.
>> >>
>> >
>> > I think we should serve up the dashboard page as a landing page by
>> default.
>>
>> IMHO one of the following options :
>>
>> 1. user dashboard aggregating and summarizing user
>> activity across products would be ok e.g. similar to Bitbucket's .
>> 2. products list
>>
>
> I'm not familiar with Bitbucket's view, but option one is what the
> Dashboard is intended to do. It includes a products list already (visible
> when more than one product exists).
>
>
>>
>> > That page does need to be improved further to help facilitate the setup
>> in
>> > a new installation, but that's another topic and shouldn't stop us from
>> > using it as the default landing page (global frontpage as Gary called
>> it).
>> >
>>
>> in case we choose (2) via `default_handler` it'll work ootb .
>> ;)
>>
>> --
>> Regards,
>>
>> Olemis.
>>
>> Apache™ Bloodhound contributor
>> http://issues.apache.org/bloodhound
>>
>> Blog ES: http://simelo-es.blogspot.com/
>> Blog EN: http://simelo-en.blogspot.com/
>>
>> Featured article:
>>
>
>
>
> --
> Joe Dreimann | *User Experience Designer* | WANdisco<http://www.wandisco.com/>
>
> @jdreimann <https://twitter.com/jdreimann>
> *
> *
> *Join one of our free daily demo sessions on* *Scaling Subversion for the
> Enterprise <http://www.wandisco.com/training/webinars>*
>
> THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE
> PRIVILEGED. If this message was misdirected, WANdisco, Inc. and its
> subsidiaries, ("WANdisco") does not waive any confidentiality or privilege.
> If you are not the intended recipient, please notify us immediately and
> destroy the message without disclosing its contents to anyone. Any
> distribution, use or copying of this e-mail or the information it contains
> by other than an intended recipient is unauthorized. The views and
> opinions expressed in this e-mail message are the author's own and may not
> reflect the views and opinions of WANdisco, unless the author is authorized
> by WANdisco to express such views or opinions on its behalf. All email
> sent to or from this address is subject to electronic storage and review by
> WANdisco. Although WANdisco operates anti-virus programs, it does not
> accept responsibility for any damage whatsoever caused by viruses being
> passed.
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Joachim Dreimann <jo...@wandisco.com>.
On 29 April 2013 18:18, Olemis Lang <ol...@gmail.com> wrote:
> Hi !
>
> On 4/29/13, Joachim Dreimann <jo...@wandisco.com> wrote:
> > On 29 April 2013 12:57, Gary Martin <ga...@wandisco.com> wrote:
> >> On 29/04/13 11:42, Anze Staric wrote:
> >>
> >>> Upgrading wikis to multiproduct now moves all wikis (and attachments)
> >>> to default product. As a result, the main page ('/') is blank, as the
> >>> page WikiStart does not exist in the global product.
> >>>
> >>> If a user plans to create multiple products, this is not a big
> >>> problem, as he will probably need a new entry page anyway. We could
> >>> add one of the guides as a WikiStart page in global env to avoid
> >>> PageNotFound error.
> >>>
> >>> But if a user does not need multiple products (he just upgraded to
> >>> bloodhound because of our other awesome features), how should he
> >>> proceed? Should we provide a way to enable mapping of wikis in default
> >>> product to global namespace (the way we do with tickets, reports,
> >>> ...)? Or should such users just disable the multiproduct module in
> >>> trac.ini?
> >>
> [...]
> >>
> >> We could suggest that if an installation is only ever expected to be a
> >> single product installation then webserver configuration could be used
> to
> >> hide the global level. I think that a proper installation should include
> >> a
> >> webserver rather than using tracd directly. It might be possible to
> offer
> >> the opportunity to have non-multiproduct version if this decision is
> made
> >> early in the installation procedure as it may be more difficult to
> switch
> >> away later. If we were to support this then we would need more testing
> to
> >> be put in place of course to cover that possibility.
> >>
> >
>
> Notice that the global home page belongs to a given (global)
> environment . So `[trac]` `default_handler` config option will be
> handy . We could set that to `products` in global scope .
>
> > I don't believe we should provide a 'single product only' installation
> > option, if that's your suggestion. More complication for little gain.
>
> IMO this comment is influenced by a «developer» perspective . IMHO
> from a user perspective , things should be as backwards compatible as
> possible . For instance , via trac-users we have received requests for
> porting Bloodhound Search and Dashboard plugins to work on top of Trac
> core ... without multi-product
>
> > Users
> > that are so opposed to potentially using multiple products in future that
> > they want to decide at the point of installation to not use them should
> use
> > Trac instead.
> >
>
> ... maybe that's a valid approach .
>
> >
> >> Meanwhile, I think putting in a new WikiStart page for the global
> >> frontpage would be pretty reasonable. We might consider listing the
> >> products on that page in some way along with any other default text we
> >> want
> >> to provide.
> >>
> >
> > I think we should serve up the dashboard page as a landing page by
> default.
>
> IMHO one of the following options :
>
> 1. user dashboard aggregating and summarizing user
> activity across products would be ok e.g. similar to Bitbucket's .
> 2. products list
>
I'm not familiar with Bitbucket's view, but option one is what the
Dashboard is intended to do. It includes a products list already (visible
when more than one product exists).
>
> > That page does need to be improved further to help facilitate the setup
> in
> > a new installation, but that's another topic and shouldn't stop us from
> > using it as the default landing page (global frontpage as Gary called
> it).
> >
>
> in case we choose (2) via `default_handler` it'll work ootb .
> ;)
>
> --
> Regards,
>
> Olemis.
>
> Apache™ Bloodhound contributor
> http://issues.apache.org/bloodhound
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
>
--
Joe Dreimann | *User Experience Designer* | WANdisco<http://www.wandisco.com/>
@jdreimann <https://twitter.com/jdreimann>
*
*
*Join one of our free daily demo sessions on* *Scaling Subversion for the
Enterprise <http://www.wandisco.com/training/webinars>*
THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE
PRIVILEGED. If this message was misdirected, WANdisco, Inc. and its
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege.
If you are not the intended recipient, please notify us immediately and
destroy the message without disclosing its contents to anyone. Any
distribution, use or copying of this e-mail or the information it contains
by other than an intended recipient is unauthorized. The views and
opinions expressed in this e-mail message are the author's own and may not
reflect the views and opinions of WANdisco, unless the author is authorized
by WANdisco to express such views or opinions on its behalf. All email
sent to or from this address is subject to electronic storage and review by
WANdisco. Although WANdisco operates anti-virus programs, it does not
accept responsibility for any damage whatsoever caused by viruses being
passed.
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Olemis Lang <ol...@gmail.com>.
Hi !
On 4/29/13, Joachim Dreimann <jo...@wandisco.com> wrote:
> On 29 April 2013 12:57, Gary Martin <ga...@wandisco.com> wrote:
>> On 29/04/13 11:42, Anze Staric wrote:
>>
>>> Upgrading wikis to multiproduct now moves all wikis (and attachments)
>>> to default product. As a result, the main page ('/') is blank, as the
>>> page WikiStart does not exist in the global product.
>>>
>>> If a user plans to create multiple products, this is not a big
>>> problem, as he will probably need a new entry page anyway. We could
>>> add one of the guides as a WikiStart page in global env to avoid
>>> PageNotFound error.
>>>
>>> But if a user does not need multiple products (he just upgraded to
>>> bloodhound because of our other awesome features), how should he
>>> proceed? Should we provide a way to enable mapping of wikis in default
>>> product to global namespace (the way we do with tickets, reports,
>>> ...)? Or should such users just disable the multiproduct module in
>>> trac.ini?
>>
[...]
>>
>> We could suggest that if an installation is only ever expected to be a
>> single product installation then webserver configuration could be used to
>> hide the global level. I think that a proper installation should include
>> a
>> webserver rather than using tracd directly. It might be possible to offer
>> the opportunity to have non-multiproduct version if this decision is made
>> early in the installation procedure as it may be more difficult to switch
>> away later. If we were to support this then we would need more testing to
>> be put in place of course to cover that possibility.
>>
>
Notice that the global home page belongs to a given (global)
environment . So `[trac]` `default_handler` config option will be
handy . We could set that to `products` in global scope .
> I don't believe we should provide a 'single product only' installation
> option, if that's your suggestion. More complication for little gain.
IMO this comment is influenced by a «developer» perspective . IMHO
from a user perspective , things should be as backwards compatible as
possible . For instance , via trac-users we have received requests for
porting Bloodhound Search and Dashboard plugins to work on top of Trac
core ... without multi-product
> Users
> that are so opposed to potentially using multiple products in future that
> they want to decide at the point of installation to not use them should use
> Trac instead.
>
... maybe that's a valid approach .
>
>> Meanwhile, I think putting in a new WikiStart page for the global
>> frontpage would be pretty reasonable. We might consider listing the
>> products on that page in some way along with any other default text we
>> want
>> to provide.
>>
>
> I think we should serve up the dashboard page as a landing page by default.
IMHO one of the following options :
1. user dashboard aggregating and summarizing user
activity across products would be ok e.g. similar to Bitbucket's .
2. products list
> That page does need to be improved further to help facilitate the setup in
> a new installation, but that's another topic and shouldn't stop us from
> using it as the default landing page (global frontpage as Gary called it).
>
in case we choose (2) via `default_handler` it'll work ootb .
;)
--
Regards,
Olemis.
Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Joachim Dreimann <jo...@wandisco.com>.
On 29 April 2013 12:57, Gary Martin <ga...@wandisco.com> wrote:
> On 29/04/13 11:42, Anze Staric wrote:
>
>> Upgrading wikis to multiproduct now moves all wikis (and attachments)
>> to default product. As a result, the main page ('/') is blank, as the
>> page WikiStart does not exist in the global product.
>>
>> If a user plans to create multiple products, this is not a big
>> problem, as he will probably need a new entry page anyway. We could
>> add one of the guides as a WikiStart page in global env to avoid
>> PageNotFound error.
>>
>> But if a user does not need multiple products (he just upgraded to
>> bloodhound because of our other awesome features), how should he
>> proceed? Should we provide a way to enable mapping of wikis in default
>> product to global namespace (the way we do with tickets, reports,
>> ...)? Or should such users just disable the multiproduct module in
>> trac.ini?
>>
>
> Hi,
>
> We could suggest that if an installation is only ever expected to be a
> single product installation then webserver configuration could be used to
> hide the global level. I think that a proper installation should include a
> webserver rather than using tracd directly. It might be possible to offer
> the opportunity to have non-multiproduct version if this decision is made
> early in the installation procedure as it may be more difficult to switch
> away later. If we were to support this then we would need more testing to
> be put in place of course to cover that possibility.
>
I don't believe we should provide a 'single product only' installation
option, if that's your suggestion. More complication for little gain. Users
that are so opposed to potentially using multiple products in future that
they want to decide at the point of installation to not use them should use
Trac instead.
>
> Meanwhile, I think putting in a new WikiStart page for the global
> frontpage would be pretty reasonable. We might consider listing the
> products on that page in some way along with any other default text we want
> to provide.
>
I think we should serve up the dashboard page as a landing page by default.
That page does need to be improved further to help facilitate the setup in
a new installation, but that's another topic and shouldn't stop us from
using it as the default landing page (global frontpage as Gary called it).
>
> Cheers,
> Gary
>
Cheers,
Joe
--
Joe Dreimann | *User Experience Designer* | WANdisco<http://www.wandisco.com/>
@jdreimann <https://twitter.com/jdreimann>
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Gary Martin <ga...@wandisco.com>.
On 29/04/13 11:42, Anze Staric wrote:
> Upgrading wikis to multiproduct now moves all wikis (and attachments)
> to default product. As a result, the main page ('/') is blank, as the
> page WikiStart does not exist in the global product.
>
> If a user plans to create multiple products, this is not a big
> problem, as he will probably need a new entry page anyway. We could
> add one of the guides as a WikiStart page in global env to avoid
> PageNotFound error.
>
> But if a user does not need multiple products (he just upgraded to
> bloodhound because of our other awesome features), how should he
> proceed? Should we provide a way to enable mapping of wikis in default
> product to global namespace (the way we do with tickets, reports,
> ...)? Or should such users just disable the multiproduct module in
> trac.ini?
Hi,
We could suggest that if an installation is only ever expected to be a
single product installation then webserver configuration could be used
to hide the global level. I think that a proper installation should
include a webserver rather than using tracd directly. It might be
possible to offer the opportunity to have non-multiproduct version if
this decision is made early in the installation procedure as it may be
more difficult to switch away later. If we were to support this then we
would need more testing to be put in place of course to cover that
possibility.
Meanwhile, I think putting in a new WikiStart page for the global
frontpage would be pretty reasonable. We might consider listing the
products on that page in some way along with any other default text we
want to provide.
Cheers,
Gary
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Anze Staric <an...@gmail.com>.
Upgrading wikis to multiproduct now moves all wikis (and attachments)
to default product. As a result, the main page ('/') is blank, as the
page WikiStart does not exist in the global product.
If a user plans to create multiple products, this is not a big
problem, as he will probably need a new entry page anyway. We could
add one of the guides as a WikiStart page in global env to avoid
PageNotFound error.
But if a user does not need multiple products (he just upgraded to
bloodhound because of our other awesome features), how should he
proceed? Should we provide a way to enable mapping of wikis in default
product to global namespace (the way we do with tickets, reports,
...)? Or should such users just disable the multiproduct module in
trac.ini?
Anze
On Thu, Apr 25, 2013 at 4:19 PM, Joachim Dreimann
<jo...@wandisco.com> wrote:
> On 24 April 2013 13:31, Branko Čibej <br...@wandisco.com> wrote:
>
>> On 24.04.2013 13:48, Gary Martin wrote:
>> > On 24/04/13 11:57, Joachim Dreimann wrote:
>> >> On 24 April 2013 11:54, Joachim Dreimann
>> >> <jo...@wandisco.com>wrote:
>> >>
>> >>> On 24 April 2013 10:19, Matevž Bradač <ma...@digiverse.si> wrote:
>> >>>
>> >>>> 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. =)
>> >>>>
>> >>> From the interface perspective I've always said that there should
>> >>> be no
>> >>> product until a user decides to create one. I have changed my mind now
>> >>> after seeing some of the issues that brings and our discussions.
>> >>>
>> >>> We could just prompt the user to name the default product during
>> >>> installation:
>> >>> *Name for initial product:*
>> >>>
>> >>> During upgrade from trac users get prompted for an upgrade trac
>> >>> command,
>> >>> so we can do the same there.
>> >>>
>> >>> Wouldn't that make it much easier to ship a decent implementation of
>> >>> this
>> >>> in 0.6?
>> >>>
>> >> Just to be clear I would then leave system wikis at a global level
>> >> (matched
>> >> by page name) and all other wiki pages and tickets etc moved to the
>> >> default
>> >> product. Permissions to edit the system wiki can remain with the
>> >> admin for
>> >> now.
>> >>
>> >> Incorrect links (#1 should really lead to #PRODA-1) should be dealt
>> >> with by
>> >> providing disambiguation.
>> >
>> > I think I can agree with the idea of requesting a name for the initial
>> > product if we are already treating the global product as a container.
>> >
>> > I suppose that we will eventually have to start meddling with user
>> > edits to the guide pages but I would still tend to go with moving all
>> > the pages to the product wiki, rather than attempting to make any
>> > distinction now. We can install a fresh set of guide pages, either in
>> > the global wiki or in the orthogonal guide wiki I suggested earlier. I
>> > am hoping that disambiguation will also help reduce any confusion this
>> > causes here too.
>> >
>> > Once we find we have to upgrade guide pages we should probably do this
>> > as updates which maintain the history of the pages on the assumption
>> > that there will be a means for users to edit them.
>> >
>> > Meanwhile, are you suggesting that #1 should never actually lead
>> > directly to PRODA-1? That would be consistent with how you suggest
>> > that the search will work but, given that the previous intent was
>> > clear, I was thinking it might be better to go to PRODA-1 and provide
>> > disambiguation links at the top of the page as an encouragement to
>> > make people use properly scoped links.
>>
>> Old-format links should always work, same as pre-multiproduct URLs
>> should work. Remember that the links do not only appear in BH tickets
>> and wikis, but also in mails or IM's and code comments etc. that we do
>> not control.
>>
>> -- Brane
>>
>
>
> Yes Gary, I like that suggestion.
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Joachim Dreimann <jo...@wandisco.com>.
On 24 April 2013 13:31, Branko Čibej <br...@wandisco.com> wrote:
> On 24.04.2013 13:48, Gary Martin wrote:
> > On 24/04/13 11:57, Joachim Dreimann wrote:
> >> On 24 April 2013 11:54, Joachim Dreimann
> >> <jo...@wandisco.com>wrote:
> >>
> >>> On 24 April 2013 10:19, Matevž Bradač <ma...@digiverse.si> wrote:
> >>>
> >>>> 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. =)
> >>>>
> >>> From the interface perspective I've always said that there should
> >>> be no
> >>> product until a user decides to create one. I have changed my mind now
> >>> after seeing some of the issues that brings and our discussions.
> >>>
> >>> We could just prompt the user to name the default product during
> >>> installation:
> >>> *Name for initial product:*
> >>>
> >>> During upgrade from trac users get prompted for an upgrade trac
> >>> command,
> >>> so we can do the same there.
> >>>
> >>> Wouldn't that make it much easier to ship a decent implementation of
> >>> this
> >>> in 0.6?
> >>>
> >> Just to be clear I would then leave system wikis at a global level
> >> (matched
> >> by page name) and all other wiki pages and tickets etc moved to the
> >> default
> >> product. Permissions to edit the system wiki can remain with the
> >> admin for
> >> now.
> >>
> >> Incorrect links (#1 should really lead to #PRODA-1) should be dealt
> >> with by
> >> providing disambiguation.
> >
> > I think I can agree with the idea of requesting a name for the initial
> > product if we are already treating the global product as a container.
> >
> > I suppose that we will eventually have to start meddling with user
> > edits to the guide pages but I would still tend to go with moving all
> > the pages to the product wiki, rather than attempting to make any
> > distinction now. We can install a fresh set of guide pages, either in
> > the global wiki or in the orthogonal guide wiki I suggested earlier. I
> > am hoping that disambiguation will also help reduce any confusion this
> > causes here too.
> >
> > Once we find we have to upgrade guide pages we should probably do this
> > as updates which maintain the history of the pages on the assumption
> > that there will be a means for users to edit them.
> >
> > Meanwhile, are you suggesting that #1 should never actually lead
> > directly to PRODA-1? That would be consistent with how you suggest
> > that the search will work but, given that the previous intent was
> > clear, I was thinking it might be better to go to PRODA-1 and provide
> > disambiguation links at the top of the page as an encouragement to
> > make people use properly scoped links.
>
> Old-format links should always work, same as pre-multiproduct URLs
> should work. Remember that the links do not only appear in BH tickets
> and wikis, but also in mails or IM's and code comments etc. that we do
> not control.
>
> -- Brane
>
Yes Gary, I like that suggestion.
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Branko Čibej <br...@wandisco.com>.
On 24.04.2013 13:48, Gary Martin wrote:
> On 24/04/13 11:57, Joachim Dreimann wrote:
>> On 24 April 2013 11:54, Joachim Dreimann
>> <jo...@wandisco.com>wrote:
>>
>>> On 24 April 2013 10:19, Matevž Bradač <ma...@digiverse.si> wrote:
>>>
>>>> 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. =)
>>>>
>>> From the interface perspective I've always said that there should
>>> be no
>>> product until a user decides to create one. I have changed my mind now
>>> after seeing some of the issues that brings and our discussions.
>>>
>>> We could just prompt the user to name the default product during
>>> installation:
>>> *Name for initial product:*
>>>
>>> During upgrade from trac users get prompted for an upgrade trac
>>> command,
>>> so we can do the same there.
>>>
>>> Wouldn't that make it much easier to ship a decent implementation of
>>> this
>>> in 0.6?
>>>
>> Just to be clear I would then leave system wikis at a global level
>> (matched
>> by page name) and all other wiki pages and tickets etc moved to the
>> default
>> product. Permissions to edit the system wiki can remain with the
>> admin for
>> now.
>>
>> Incorrect links (#1 should really lead to #PRODA-1) should be dealt
>> with by
>> providing disambiguation.
>
> I think I can agree with the idea of requesting a name for the initial
> product if we are already treating the global product as a container.
>
> I suppose that we will eventually have to start meddling with user
> edits to the guide pages but I would still tend to go with moving all
> the pages to the product wiki, rather than attempting to make any
> distinction now. We can install a fresh set of guide pages, either in
> the global wiki or in the orthogonal guide wiki I suggested earlier. I
> am hoping that disambiguation will also help reduce any confusion this
> causes here too.
>
> Once we find we have to upgrade guide pages we should probably do this
> as updates which maintain the history of the pages on the assumption
> that there will be a means for users to edit them.
>
> Meanwhile, are you suggesting that #1 should never actually lead
> directly to PRODA-1? That would be consistent with how you suggest
> that the search will work but, given that the previous intent was
> clear, I was thinking it might be better to go to PRODA-1 and provide
> disambiguation links at the top of the page as an encouragement to
> make people use properly scoped links.
Old-format links should always work, same as pre-multiproduct URLs
should work. Remember that the links do not only appear in BH tickets
and wikis, but also in mails or IM's and code comments etc. that we do
not control.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Gary Martin <ga...@wandisco.com>.
On 24/04/13 11:57, Joachim Dreimann wrote:
> On 24 April 2013 11:54, Joachim Dreimann <jo...@wandisco.com>wrote:
>
>> On 24 April 2013 10:19, Matevž Bradač <ma...@digiverse.si> wrote:
>>
>>> 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. =)
>>>
>> From the interface perspective I've always said that there should be no
>> product until a user decides to create one. I have changed my mind now
>> after seeing some of the issues that brings and our discussions.
>>
>> We could just prompt the user to name the default product during
>> installation:
>> *Name for initial product:*
>>
>> During upgrade from trac users get prompted for an upgrade trac command,
>> so we can do the same there.
>>
>> Wouldn't that make it much easier to ship a decent implementation of this
>> in 0.6?
>>
> Just to be clear I would then leave system wikis at a global level (matched
> by page name) and all other wiki pages and tickets etc moved to the default
> product. Permissions to edit the system wiki can remain with the admin for
> now.
>
> Incorrect links (#1 should really lead to #PRODA-1) should be dealt with by
> providing disambiguation.
I think I can agree with the idea of requesting a name for the initial
product if we are already treating the global product as a container.
I suppose that we will eventually have to start meddling with user edits
to the guide pages but I would still tend to go with moving all the
pages to the product wiki, rather than attempting to make any
distinction now. We can install a fresh set of guide pages, either in
the global wiki or in the orthogonal guide wiki I suggested earlier. I
am hoping that disambiguation will also help reduce any confusion this
causes here too.
Once we find we have to upgrade guide pages we should probably do this
as updates which maintain the history of the pages on the assumption
that there will be a means for users to edit them.
Meanwhile, are you suggesting that #1 should never actually lead
directly to PRODA-1? That would be consistent with how you suggest that
the search will work but, given that the previous intent was clear, I
was thinking it might be better to go to PRODA-1 and provide
disambiguation links at the top of the page as an encouragement to make
people use properly scoped links.
Cheers,
Gary
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Joachim Dreimann <jo...@wandisco.com>.
On 24 April 2013 11:54, Joachim Dreimann <jo...@wandisco.com>wrote:
>
> On 24 April 2013 10:19, Matevž Bradač <ma...@digiverse.si> wrote:
>
>>
>> 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. =)
>>
>
> From the interface perspective I've always said that there should be no
> product until a user decides to create one. I have changed my mind now
> after seeing some of the issues that brings and our discussions.
>
> We could just prompt the user to name the default product during
> installation:
> *Name for initial product:*
>
> During upgrade from trac users get prompted for an upgrade trac command,
> so we can do the same there.
>
> Wouldn't that make it much easier to ship a decent implementation of this
> in 0.6?
>
Just to be clear I would then leave system wikis at a global level (matched
by page name) and all other wiki pages and tickets etc moved to the default
product. Permissions to edit the system wiki can remain with the admin for
now.
Incorrect links (#1 should really lead to #PRODA-1) should be dealt with by
providing disambiguation.
>
> - Joe
>
>
>>
>> >
>> > Anyway, I'm trying to work out whether it is worth suggesting another
>> orthogonal wiki on a different path for the Guide pages so that we can
>> separate out concerns. So, if there is a path/to/wiki/ for each product's
>> wiki, path/to/guide/ could be for system pages and then we would only have
>> to consider upgrading the Guide pages in the Guide wiki and only actually
>> at a single location and we can drop any excuse to meddle with the product
>> wikis.
>>
>> That makes a lot of sense, and is IMO closely related to proposal 2 -
>> global
>> wikis moved to default product, empty global wiki populated with links to
>> product wikis. Would it make sense to replace the global WikiStart with
>> the
>> Guide page in this case?
>>
>> >
>> > Many of the same problems remain, including page duplication but the
>> general disambiguation link solution is equally valid here. This wiki
>> solution also seems consistent with subdomain setups that Olemis is so keen
>> on.
>> >
>> > Cheers,
>> > Gary
>>
>>
>> --
>> matevz
>>
>>
>
>
> --
> Joe Dreimann | *User Experience Designer* | WANdisco<http://www.wandisco.com/>
>
> @jdreimann <https://twitter.com/jdreimann>
>
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Joachim Dreimann <jo...@wandisco.com>.
On 24 April 2013 10:19, Matevž Bradač <ma...@digiverse.si> wrote:
>
> 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. =)
>
>From the interface perspective I've always said that there should be no
product until a user decides to create one. I have changed my mind now
after seeing some of the issues that brings and our discussions.
We could just prompt the user to name the default product during
installation:
*Name for initial product:*
During upgrade from trac users get prompted for an upgrade trac command, so
we can do the same there.
Wouldn't that make it much easier to ship a decent implementation of this
in 0.6?
- Joe
>
> >
> > Anyway, I'm trying to work out whether it is worth suggesting another
> orthogonal wiki on a different path for the Guide pages so that we can
> separate out concerns. So, if there is a path/to/wiki/ for each product's
> wiki, path/to/guide/ could be for system pages and then we would only have
> to consider upgrading the Guide pages in the Guide wiki and only actually
> at a single location and we can drop any excuse to meddle with the product
> wikis.
>
> That makes a lot of sense, and is IMO closely related to proposal 2 -
> global
> wikis moved to default product, empty global wiki populated with links to
> product wikis. Would it make sense to replace the global WikiStart with the
> Guide page in this case?
>
> >
> > Many of the same problems remain, including page duplication but the
> general disambiguation link solution is equally valid here. This wiki
> solution also seems consistent with subdomain setups that Olemis is so keen
> on.
> >
> > Cheers,
> > Gary
>
>
> --
> matevz
>
>
--
Joe Dreimann | *User Experience Designer* | WANdisco<http://www.wandisco.com/>
@jdreimann <https://twitter.com/jdreimann>
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Matevž Bradač <ma...@digiverse.si>.
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. =)
>
> Anyway, I'm trying to work out whether it is worth suggesting another orthogonal wiki on a different path for the Guide pages so that we can separate out concerns. So, if there is a path/to/wiki/ for each product's wiki, path/to/guide/ could be for system pages and then we would only have to consider upgrading the Guide pages in the Guide wiki and only actually at a single location and we can drop any excuse to meddle with the product wikis.
That makes a lot of sense, and is IMO closely related to proposal 2 - global
wikis moved to default product, empty global wiki populated with links to
product wikis. Would it make sense to replace the global WikiStart with the
Guide page in this case?
>
> Many of the same problems remain, including page duplication but the general disambiguation link solution is equally valid here. This wiki solution also seems consistent with subdomain setups that Olemis is so keen on.
>
> Cheers,
> Gary
--
matevz
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Gary Martin <ga...@wandisco.com>.
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.
> 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.
Anyway, I'm trying to work out whether it is worth suggesting another
orthogonal wiki on a different path for the Guide pages so that we can
separate out concerns. So, if there is a path/to/wiki/ for each
product's wiki, path/to/guide/ could be for system pages and then we
would only have to consider upgrading the Guide pages in the Guide wiki
and only actually at a single location and we can drop any excuse to
meddle with the product wikis.
Many of the same problems remain, including page duplication but the
general disambiguation link solution is equally valid here. This wiki
solution also seems consistent with subdomain setups that Olemis is so
keen on.
Cheers,
Gary
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Matevž Bradač <ma...@digiverse.si>.
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
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Gary Martin <ga...@wandisco.com>.
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
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Gary Martin <ga...@wandisco.com>.
On 22/04/13 16:26, Andrej Golcov wrote:
> IMO, there should be only one instance of "System" wiki pages.
> Otherwise, that brings a few problems:
> - user confusing - within single product user can be pointed out to
> global WikiFormatting page (as direct link on wiki edit page) and
> local WikiFormatting page from another product wiki page. If page
> content is different that can raise a lot of complaints.
> - system wiki upgrade will be complex and error-prone procedure.
>
> Cheers, Andrej
For these situations I would probably only attempt to keep the global
wiki up to date but provide disambiguation pages so that it is
relatively clear when the user might have been referring to a different
version of any page.
Cheers,
Gary
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Andrej Golcov <an...@digiverse.si>.
IMO, there should be only one instance of "System" wiki pages.
Otherwise, that brings a few problems:
- user confusing - within single product user can be pointed out to
global WikiFormatting page (as direct link on wiki edit page) and
local WikiFormatting page from another product wiki page. If page
content is different that can raise a lot of complaints.
- system wiki upgrade will be complex and error-prone procedure.
Cheers, Andrej
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Olemis Lang <ol...@gmail.com>.
On 4/23/13, Matevž Bradač <ma...@digiverse.si> wrote:
> On 22. Apr, 2013, at 17:12, Olemis Lang wrote:
[...]
>>
>>> - 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).
If that is the case then IMO we better locate attachments for system
wiki pages in trac/htdocs folder and make reference to them using
htdocs: shortcut . That way we do not have to deal with attachments ,
which is a bit complicated .
{{{
[[Image(htdocs:foo/bar.png)]] # image file in project htdocs dir.
}}}
http://trac.edgewall.org/wiki/WikiMacros
> This is also true if any of the Trac's default pages have been modified
> by the users to include attachments.
>
That's definitely another related subject . We can not make
assumptions if wiki page was previously edited .
[...]
--
Regards,
Olemis.
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Matevž Bradač <ma...@digiverse.si>.
On 22. Apr, 2013, at 17:12, Olemis Lang wrote:
> On 4/22/13, Matevž Bradač <ma...@digiverse.si> 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
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Olemis Lang <ol...@gmail.com>.
On 4/22/13, Matevž Bradač <ma...@digiverse.si> 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/
> 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 ?
> - most likely the attachments have to be duplicated as well - duplicate
> wikis, may confuse wiki editors
>
do default wikis contain 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 ?
> - 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 .
--
Regards,
Olemis.
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Matevž Bradač <ma...@digiverse.si>.
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?
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
- attachment handling
- most likely the attachments have to be duplicated as well - duplicate
wikis, may confuse wiki editors
2. Global wikis moved from global scope into default product
+ no wiki/attachment duplication
+ no broken wiki links
- 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
(There are likely other possibilities, feel free to add them to the list)
-- matevz
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Branko Čibej <br...@wandisco.com>.
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
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Gary Martin <ga...@wandisco.com>.
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.
Cheers,
Gary
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Andrej Golcov <an...@digiverse.si>.
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
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Gary Martin <ga...@wandisco.com>.
On 01/04/13 02:01, Olemis Lang wrote:
> On 3/31/13, Gary Martin <ga...@wandisco.com> wrote:
>> On 28/03/13 08:51, Jure Zitnik wrote:
>>
> [...]
>> Does any of that make sense?
>>
> I just wanted to mention that the fact that permissions are granted
> per-environment implies that it is possible that users will have no
> access to wiki on (some) products . At upgrade time it is important to
> keep system wiki pages alive in order to avoid dangling wiki refs .
>
I am aware that this is a potential problem and this effectively makes
it the responsibility of the admin to keep these links available. It
could also be considered a problem if someone deletes one of the pages
from the global system pages. We could of course provide the missing
page view with links to an external site with documentation or even just
recommend that the user asks the global admin to make the pages
available again.
I don't think that we should worry too much about such dangling links
for now as long as there is an appropriate way for people to find their
way to documentation.
Cheers,
Gary
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Olemis Lang <ol...@gmail.com>.
On 3/31/13, Gary Martin <ga...@wandisco.com> wrote:
> On 28/03/13 08:51, Jure Zitnik wrote:
>
[...]
>
> Does any of that make sense?
>
I just wanted to mention that the fact that permissions are granted
per-environment implies that it is possible that users will have no
access to wiki on (some) products . At upgrade time it is important to
keep system wiki pages alive in order to avoid dangling wiki refs .
--
Regards,
Olemis.
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Gary Martin <ga...@wandisco.com>.
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
Re: [BEP-0003] Wiki install vs. upgrade
Posted by Olemis Lang <ol...@gmail.com>.
On 3/28/13, Jure Zitnik <ju...@digiverse.si> 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.
>
I just wanted to add that a few comments :
1. for some deployments where there is little coupling
between sibling projects it might be a good idea to
add default wiki pages in all contexts .
2. it'd be nice to include a checkbox in new product
form to add default wiki pages (or not) on product
creation (maybe via IResourceChangeListener)
3. notice that after #475 it is possible to execute
wiki upgrade on product envs ... and they'll be
incorporated as well ;)
--
Regards,
Olemis.