You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Gary Martin <ga...@wandisco.com> on 2013/04/22 13:41:43 UTC
Re: [Apache Bloodhound] #450: TracLinks for BloodhoundSeach plugin
- after #390
On 22/04/13 11:03, Apache Bloodhound wrote:
> #450: TracLinks for BloodhoundSeach plugin - after #390
> -------------------------+-------------------------------------------------
> Reporter: olemis | Owner: nobody
> Type: task | Status: new
> Priority: major | Milestone:
> Component: search | Version:
> Resolution: | Keywords: search TracLinks bep-0004
> | bep-0004-stable
> -------------------------+-------------------------------------------------
>
> Comment (by jdreimann):
>
> I believe this local/global scope change of the search will prove
> confusing and annoying to the average user. Search should always remain
> global in scope.
>
> Our MultiProduct equivalent to TracLinks should require stating the scope
> to be valid and otherwise take users to a disambiguation page.
>
> See the following scenarios:
> Input: {{{#1}}}
> Output: {{{Did you mean: #PRODA-1, #PRODK-1, #PRODX-1}}}
>
> Input: {{{#PRODA-1}}}
> Ouptput: {{{Redirecting to PRODA-1}}}
>
> This should always be the behaviour, also for others objects like Wiki
> pages, Milestones, etc. While I am browsing ticket {{{#PRODA-1}}} (so I am
> in the {{{PRODA}}} scope) and insert a link to {{{#5}}}, it will lead to a
> disambiguation page (though {{{#PRODA-5}}} may be pushed to the top
> because it is likely relevant).
>
It is most annoying that search no longer understands these links at
all! In the long run I seem to remember hoping that we might end up
going to the resource that is in scope but providing disambiguation
links near the top of the page when the user has not specified scope
properly and there are other possible interpretations. I think that this
might balance keeping links working with being just annoying enough to
encourage users to use proper scoping into the future. It could then
also apply to any of the resource links in tickets and wiki pages and
not just search.
Cheers,
Gary
Re: [Apache Bloodhound] #450: TracLinks for BloodhoundSeach plugin
- after #390
Posted by Gary Martin <ga...@wandisco.com>.
On 23/04/13 17:43, Andrej Golcov wrote:
> As far as I know, bhsearch uses wiki links for quick links
> determination. If wiki links supports the syntax, bhsearch should
> support it also.
>
> Cheers, Andrej
I am happy that this is not effectively the responsibility of search,
particularly if it is not available elsewhere yet. I'll do some digging
in a bit.
Cheers,
Gary
Re: [Apache Bloodhound] #450: TracLinks for BloodhoundSeach plugin -
after #390
Posted by Andrej Golcov <an...@digiverse.si>.
As far as I know, bhsearch uses wiki links for quick links
determination. If wiki links supports the syntax, bhsearch should
support it also.
Cheers, Andrej
On 23 April 2013 18:29, Gary Martin <ga...@wandisco.com> wrote:
> On 22/04/13 17:47, Anze Staric wrote:
>>
>> Searching for links that point to resources in the current project,
>> should already work. There was a bug with links in default product
>> that I just fixed in r1470615. If the functionality still does not
>> work for you, please let me know and I will look into it.
>>
>>
>
> That seems to help a little. Are we meant to be supporting the PREFIX-1234
> style links yet?
>
> Cheers,
> Gary
Re: [Apache Bloodhound] #450: TracLinks for BloodhoundSeach plugin
- after #390
Posted by Gary Martin <ga...@wandisco.com>.
On 22/04/13 17:47, Anze Staric wrote:
> Searching for links that point to resources in the current project,
> should already work. There was a bug with links in default product
> that I just fixed in r1470615. If the functionality still does not
> work for you, please let me know and I will look into it.
>
>
That seems to help a little. Are we meant to be supporting the
PREFIX-1234 style links yet?
Cheers,
Gary
Re: [Apache Bloodhound] #450: TracLinks for BloodhoundSeach plugin -
after #390
Posted by Anze Staric <an...@gmail.com>.
Searching for links that point to resources in the current project,
should already work. There was a bug with links in default product
that I just fixed in r1470615. If the functionality still does not
work for you, please let me know and I will look into it.
Anze
On Mon, Apr 22, 2013 at 1:41 PM, Gary Martin <ga...@wandisco.com> wrote:
> On 22/04/13 11:03, Apache Bloodhound wrote:
>>
>> #450: TracLinks for BloodhoundSeach plugin - after #390
>>
>> -------------------------+-------------------------------------------------
>> Reporter: olemis | Owner: nobody
>> Type: task | Status: new
>> Priority: major | Milestone:
>> Component: search | Version:
>> Resolution: | Keywords: search TracLinks bep-0004
>> | bep-0004-stable
>>
>> -------------------------+-------------------------------------------------
>>
>> Comment (by jdreimann):
>>
>> I believe this local/global scope change of the search will prove
>> confusing and annoying to the average user. Search should always remain
>> global in scope.
>>
>> Our MultiProduct equivalent to TracLinks should require stating the
>> scope
>> to be valid and otherwise take users to a disambiguation page.
>>
>> See the following scenarios:
>> Input: {{{#1}}}
>> Output: {{{Did you mean: #PRODA-1, #PRODK-1, #PRODX-1}}}
>>
>> Input: {{{#PRODA-1}}}
>> Ouptput: {{{Redirecting to PRODA-1}}}
>>
>> This should always be the behaviour, also for others objects like Wiki
>> pages, Milestones, etc. While I am browsing ticket {{{#PRODA-1}}} (so I
>> am
>> in the {{{PRODA}}} scope) and insert a link to {{{#5}}}, it will lead to
>> a
>> disambiguation page (though {{{#PRODA-5}}} may be pushed to the top
>> because it is likely relevant).
>>
>
> It is most annoying that search no longer understands these links at all! In
> the long run I seem to remember hoping that we might end up going to the
> resource that is in scope but providing disambiguation links near the top of
> the page when the user has not specified scope properly and there are other
> possible interpretations. I think that this might balance keeping links
> working with being just annoying enough to encourage users to use proper
> scoping into the future. It could then also apply to any of the resource
> links in tickets and wiki pages and not just search.
>
> Cheers,
> Gary