You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Olemis Lang <ol...@gmail.com> on 2013/07/03 21:01:15 UTC
Request to not to redirect /timeline to default product
There is a problem I've noticed while trying to fix some failures in
the functional test suite. The global environment still hosts the wiki
pages and other resources (e.g. that we use in blood-hound.net second
level domain). In default installation however default hooks redirect
/timeline to default product which makes it impossible to track
changes performed in global scope. Another reason for not doing so is
that every time a wiki page is created by the functional tester the
next logical step is to check that the changes show up in the timeline
... but there's no way to access global events because of
aforementioned redirection .
Why is /timeline redirected to global scope ? May I change that and
exclude global /timeline so that it will be accessible at global URL
namespace once again ?
Notice: If there's a misconfiguration then the global timeline is
restored (per the changes committed recently by ... @rjollos?) .
PS: At this moment remaining failures in functional test suite are
related to this issue , the one described in #576 and nested forms in
ticket view.
--
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:
El (posible) significado de los números de versiones -
http://feedproxy.google.com/~r/simelo-es/~3/UZwM9YiljYI/el-posible-significado-de-los-numeros.html
Re: Request to not to redirect /timeline to default product
Posted by Olemis Lang <ol...@gmail.com>.
On 7/3/13, Olemis Lang <ol...@gmail.com> wrote:
> On 7/3/13, Ryan Ollos <ry...@wandisco.com> wrote:
[...]
>>
>>
>> We have a global dashboard, so I think it make sense to also have a
>> global
>> timeline. I confirm the behavior that `/timeline` redirects to
>> `/products/@/timeline`, though I can't say whether this was intentional.
>> If
>> there are no objections or basis for the current behavior, then I would
>> agree with the changes you suggest.
>>
>
> Even after restoring the global timeline there is a more critical
> subject ... It seems to be impossible to attach files to global wiki
> pages . This is due to the fact that /wiki remains global whereas
> /attachment is always redirected to default product . Therefore
> attaching a file to a global wiki page will result in
>
> 1. `SurprisedPhysiological doesn't exist, can't create attachment`
> (<= pasted from test report) messages if target wiki page does not
> exist in default product scope
> 2. File will be attached to the wiki page having the same name
> but in default product rather than global scope o.O
>
> For the time being I'll add a patch in order to **try** to do
> something about it. Nonetheless even if all this is (reverted / fixed
> / improved) there is another complication regarding functional test
> code (and thereby actual system behavior). It is a common practice
> throughout Trac's functional test cases to check for successful
> actions by inspecting the timeline with filters applied. We have
> ticket activity recorded in default product scope and OTOH wiki
> activity recorded in global environment. That means that ticket
> assertions working now (i.e. resolved in default product scope) will
> fail after
>
... showing global events at /timeline URL path (... sorry for the
previous omission ...)
> I hope you will understand if I propose to get rid of redirections to
> default product at all
>
> 1. the resulting URL scheme is confusing
> 2. there are annoying consequences , possibly leading to
> (invalid / unexpected) content
> * e.g. default product = x , user posts in a public ML
> URL http://example.com/bh/ticket/33
> referring to ticket 33 in product x ; admin configures default
> product = y
> and suddenly the URL and content are not related at all .
> 3. a lot of complexity is added
> 4. maintaining testing code becomes a real headache
> * what is fixed under the assumption of interacting with global env
> is broken every time interactions involve default product scope
>
> Just my opinion on this subject based on a few facts . What shall we
> do (looking forward to Release 7 as a target) ?
>
> PS: The issue regarding attachments and global wiki should be
> documented in release notes as a known bug .
>
--
Regards,
Olemis.
Re: Request to not to redirect /timeline to default product
Posted by Olemis Lang <ol...@gmail.com>.
On 7/3/13, Olemis Lang <ol...@gmail.com> wrote:
> On 7/3/13, Branko Čibej <br...@wandisco.com> wrote:
>> On 04.07.2013 00:53, Olemis Lang wrote:
>>> I hope you will understand if I propose to get rid of redirections to
>>> default product at all
>>
>> I think we've all come to the conclusion that the concept of "default
>> product" is only really useful during upgrades from non-multiproduct.
>>
>
> JFTR , notice that I've submitted new patches for #387 to deal with
> the problems mentioned in my previous message . Failure count has been
> reduced to 1 (see #476)
ouch ! #576
:-$
> and most of the errors are related to nested
> forms in ticket view (<= though in this case maybe there's more work
> to do).
>
>> IMO BEP-10 should address the issues related to maintaining URL aliases
>> for ticked numbers from before an upgrade, but other than that, it's IMO
>> OK to get rid of the default product /as long as/ we have a consistent
>> way to support non-multiproduct-aware plugins (i.e., making them work in
>> the "current selected product").
>>
>
> +
>
>> There should probably be a followup to BEP-3 to cover these changes.
>>
>
> A whole new BEP for this , if considered necessary , should be ok for
> me , afaict .
>
> --
> Regards,
>
> Olemis.
>
--
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: Request to not to redirect /timeline to default product
Posted by Olemis Lang <ol...@gmail.com>.
On 7/3/13, Branko Čibej <br...@wandisco.com> wrote:
> On 04.07.2013 00:53, Olemis Lang wrote:
>> I hope you will understand if I propose to get rid of redirections to
>> default product at all
>
> I think we've all come to the conclusion that the concept of "default
> product" is only really useful during upgrades from non-multiproduct.
>
JFTR , notice that I've submitted new patches for #387 to deal with
the problems mentioned in my previous message . Failure count has been
reduced to 1 (see #476) and most of the errors are related to nested
forms in ticket view (<= though in this case maybe there's more work
to do).
> IMO BEP-10 should address the issues related to maintaining URL aliases
> for ticked numbers from before an upgrade, but other than that, it's IMO
> OK to get rid of the default product /as long as/ we have a consistent
> way to support non-multiproduct-aware plugins (i.e., making them work in
> the "current selected product").
>
+
> There should probably be a followup to BEP-3 to cover these changes.
>
A whole new BEP for this , if considered necessary , should be ok for
me , afaict .
--
Regards,
Olemis.
Re: Request to not to redirect /timeline to default product
Posted by Branko Čibej <br...@wandisco.com>.
On 04.07.2013 00:53, Olemis Lang wrote:
> I hope you will understand if I propose to get rid of redirections to
> default product at all
I think we've all come to the conclusion that the concept of "default
product" is only really useful during upgrades from non-multiproduct.
IMO BEP-10 should address the issues related to maintaining URL aliases
for ticked numbers from before an upgrade, but other than that, it's IMO
OK to get rid of the default product /as long as/ we have a consistent
way to support non-multiproduct-aware plugins (i.e., making them work in
the "current selected product").
There should probably be a followup to BEP-3 to cover these changes.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: Request to not to redirect /timeline to default product
Posted by Olemis Lang <ol...@gmail.com>.
On 7/3/13, Ryan Ollos <ry...@wandisco.com> wrote:
> On Wed, Jul 3, 2013 at 12:01 PM, Olemis Lang <ol...@gmail.com> wrote:
>
>> There is a problem I've noticed while trying to fix some failures in
>> the functional test suite. The global environment still hosts the wiki
>> pages and other resources (e.g. that we use in blood-hound.net second
>> level domain). In default installation however default hooks redirect
>> /timeline to default product which makes it impossible to track
>> changes performed in global scope. Another reason for not doing so is
>> that every time a wiki page is created by the functional tester the
>> next logical step is to check that the changes show up in the timeline
>> ... but there's no way to access global events because of
>> aforementioned redirection .
>>
>> Why is /timeline redirected to global scope ? May I change that and
>> exclude global /timeline so that it will be accessible at global URL
>> namespace once again ?
>>
>> Notice: If there's a misconfiguration then the global timeline is
>> restored (per the changes committed recently by ... @rjollos?) .
>>
>> PS: At this moment remaining failures in functional test suite are
>> related to this issue , the one described in #576 and nested forms in
>> ticket view.
>
>
> We have a global dashboard, so I think it make sense to also have a global
> timeline. I confirm the behavior that `/timeline` redirects to
> `/products/@/timeline`, though I can't say whether this was intentional. If
> there are no objections or basis for the current behavior, then I would
> agree with the changes you suggest.
>
Even after restoring the global timeline there is a more critical
subject ... It seems to be impossible to attach files to global wiki
pages . This is due to the fact that /wiki remains global whereas
/attachment is always redirected to default product . Therefore
attaching a file to a global wiki page will result in
1. `SurprisedPhysiological doesn't exist, can't create attachment`
(<= pasted from test report) messages if target wiki page does not
exist in default product scope
2. File will be attached to the wiki page having the same name
but in default product rather than global scope o.O
For the time being I'll add a patch in order to **try** to do
something about it. Nonetheless even if all this is (reverted / fixed
/ improved) there is another complication regarding functional test
code (and thereby actual system behavior). It is a common practice
throughout Trac's functional test cases to check for successful
actions by inspecting the timeline with filters applied. We have
ticket activity recorded in default product scope and OTOH wiki
activity recorded in global environment. That means that ticket
assertions working now (i.e. resolved in default product scope) will
fail after
I hope you will understand if I propose to get rid of redirections to
default product at all
1. the resulting URL scheme is confusing
2. there are annoying consequences , possibly leading to
(invalid / unexpected) content
* e.g. default product = x , user posts in a public ML
URL http://example.com/bh/ticket/33
referring to ticket 33 in product x ; admin configures default
product = y
and suddenly the URL and content are not related at all .
3. a lot of complexity is added
4. maintaining testing code becomes a real headache
* what is fixed under the assumption of interacting with global env
is broken every time interactions involve default product scope
Just my opinion on this subject based on a few facts . What shall we
do (looking forward to Release 7 as a target) ?
PS: The issue regarding attachments and global wiki should be
documented in release notes as a known bug .
--
Regards,
Olemis.
Re: Request to not to redirect /timeline to default product
Posted by Ryan Ollos <ry...@wandisco.com>.
On Wed, Jul 3, 2013 at 12:01 PM, Olemis Lang <ol...@gmail.com> wrote:
> There is a problem I've noticed while trying to fix some failures in
> the functional test suite. The global environment still hosts the wiki
> pages and other resources (e.g. that we use in blood-hound.net second
> level domain). In default installation however default hooks redirect
> /timeline to default product which makes it impossible to track
> changes performed in global scope. Another reason for not doing so is
> that every time a wiki page is created by the functional tester the
> next logical step is to check that the changes show up in the timeline
> ... but there's no way to access global events because of
> aforementioned redirection .
>
> Why is /timeline redirected to global scope ? May I change that and
> exclude global /timeline so that it will be accessible at global URL
> namespace once again ?
>
> Notice: If there's a misconfiguration then the global timeline is
> restored (per the changes committed recently by ... @rjollos?) .
>
> PS: At this moment remaining failures in functional test suite are
> related to this issue , the one described in #576 and nested forms in
> ticket view.
We have a global dashboard, so I think it make sense to also have a global
timeline. I confirm the behavior that `/timeline` redirects to
`/products/@/timeline`, though I can't say whether this was intentional. If
there are no objections or basis for the current behavior, then I would
agree with the changes you suggest.