#592: Incorrect resolution of absolute hrefs
---------------------------+--------------------------------------
Reporter: olemis | Owner: rjollos
Type: defect | Status: review
Priority: minor | Milestone: Release 7
Component: multiproduct | Version:
Resolution: | Keywords: global product TracLinks
---------------------------+--------------------------------------
Old description:
> Recently I've noticed that `global:` TracLinks do not point at the
> resource URL in the right product context when using bootstrap handlers
> to deploy custom URL mappings. E.g. in this page http://dataviz.blood-
> hound.net/wiki/UserDoc/TracLinks `[global:wiki:TracLinks]` is expanded to
> ''http://dataviz.blood-hound.net/wiki/TracLinks'' instead of global URL
> ''http://blood-hound.net/wiki/TracLinks''.
>
> **Update** : After some more testing with sub-domain deployments the
> situation is as follows:
>
> - If `base_url` option in `[trac]` section of the global env
> [wiki:TracIni configuration file] is not set then `product:` links
> will point at the correct URL but `global:` links will not work
> as expected in product context.
> - OTOH once `base_url` option in `[trac]` section of the global env
> [wiki:TracIni configuration file] is set then `product_base_url` in
> `[multiproduct]` section is ignored and both `product:` and `global:`
> links
> will not work as expected in any context.
>
> PS: This is working fine for default URL mappings in my local working
> copy.
New description:
Recently I've noticed that `global:` TracLinks do not point at the
resource URL in the right product context when using bootstrap handlers to
deploy custom URL mappings. E.g. in this page http://dataviz.blood-
hound.net/wiki/UserDoc/TracLinks `[global:wiki:TracLinks]` is expanded to
''http://dataviz.blood-hound.net/wiki/TracLinks'' instead of global URL
''http://blood-hound.net/wiki/TracLinks''.
**Update** : After some more testing with sub-domain deployments the
situation is as follows:
1. If `base_url` option in `[trac]` section of the global env
[wiki:TracIni configuration file] is not set then `product:` links
will point at the correct URL but `global:` links will not work
as expected in product context.
2. OTOH once `base_url` option in `[trac]` section of the global env
[wiki:TracIni configuration file] is set then `product_base_url` in
`[multiproduct]` section is ignored and both `product:` and `global:`
links
will not work as expected in any context.
PS: This is working fine for default URL mappings in my local working
copy.
--
Comment (by olemis):
Replying to [comment:8 rjollos]:
> I've been studying the code, and it seems like we've carried over some
unnecessary code from Trac. To show the simplest example of what I mean,
in `trac.env.Environment` the
[http://trac.edgewall.org/browser/tags/trac-1.0.1/trac/env.py?marks=719-723#L718
href] property is evaluated and cached in the `_href` attribute. This was
probably implemented when Trac supported Python < 2.4 and decorators were
not available, so it seems that, now that decorators are available for all
versions of Python that Trac supports, we could propose the following
patch to Trac:
>
[...]
Why not to create a ticket in Trac issue tracker and see what other trac-
devs have to say about your patch ?
>
> For `multiproduct.product.ProductEnvironment`, it looks like we've
replicated the `href` method from `trac.env.Environment`, and replicated
and then modified the `abs_href` method. In both cases though, the
`@property` decorator was replaced with `@lazy`.
I got the idea you want to express in your comment , however I'm not
completely sure of all the implications . The duplication of
''_base_url''s proposed in the patch is due to the fact that product
configuration options inherit global values. The issue in situation (2)
listed in ticket description consists in the fact that if global option is
set to a given value then DB configuration objects of all other products
will inherit the very same value unless explicitly updated in a given
product `base_url` configuration option. That's not a good idea since that
leads to some of the errors mentioned in #594 . The way to work around
this consists in reading product option and return its value only if it's
different to global env's.
> It looks like we are "double-cacheing" the value.
[...]
>
> but we should have eliminated the `_href` variable when replacing
`property` with `lazy`
[...]
>
> What do you think?
I have no major objections as long as test cases will be satisfied. Maybe
it's a good idea to solve target issue here and create another ticket for
such refactoring (enhancement) ?
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/592#comment:9>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound issue tracker
