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/03/13 05:08:32 UTC
Re: svn commit: r1455576 - in /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct:
api.py hooks.py web_ui.py
On 3/12/13, jure@apache.org <ju...@apache.org> wrote:
> Author: jure
> Date: Tue Mar 12 15:15:22 2013
> New Revision: 1455576
>
> URL: http://svn.apache.org/r1455576
> Log:
> Renamed default product to '@',
@jure: why ?
--
Regards,
Olemis.
Re: svn commit: r1455576 - in /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct:
api.py hooks.py web_ui.py
Posted by Branko Čibej <br...@wandisco.com>.
On 13.03.2013 10:04, Jure Zitnik wrote:
> On 3/13/13 9:31 AM, Olemis Lang wrote:
>> On 3/13/13, Jure Zitnik <ju...@digiverse.si> wrote:
>>> On 3/13/13 8:58 AM, Olemis Lang wrote:
>>>> On 3/13/13, Jure Zitnik <ju...@digiverse.si> wrote:
>>>>> On 3/13/13 5:18 AM, Branko Čibej wrote:
>>>>>> On 13.03.2013 05:08, Olemis Lang wrote:
>>>>>>> On 3/12/13, jure@apache.org <ju...@apache.org> wrote:
>>>>>>>> Author: jure
>>>>>>>> Date: Tue Mar 12 15:15:22 2013
>>>>>>>> New Revision: 1455576
>>>>>>>>
>>>>>>>> URL: http://svn.apache.org/r1455576
>>>>>>>> Log:
>>>>>>>> Renamed default product to '@',
>>>>>>> @jure: why ?
>>>>>> Because it's a token that is forbidden as a product tag and
>>>>>> therefore
>>>>>> cannot conflict with existing product names.
>>>> I'll ask the negation of the negation .
>>>>
>>>> Why is it that we'll have to apply this change instead of sticking to
>>>> '' as global prefix?
>>> Just to clarify things, we did not change '' as the global prefix. The
>>> default product '@' is the product to which all the tickets w/o product
>>> get migrated during upgrade process.
>>>
>> Oh ! Now I see ... and how will that data be retrieved if we use a
>> non-standard prefix ?
> Don't see a problem with that as product prefix will only be validated
> on product creation through UI.
Validation must happen in the API. Validating in the UI is good, but not
sufficient.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: svn commit: r1455576 - in /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct:
api.py hooks.py web_ui.py
Posted by Jure Zitnik <ju...@digiverse.si>.
On 3/13/13 9:31 AM, Olemis Lang wrote:
> On 3/13/13, Jure Zitnik <ju...@digiverse.si> wrote:
>> On 3/13/13 8:58 AM, Olemis Lang wrote:
>>> On 3/13/13, Jure Zitnik <ju...@digiverse.si> wrote:
>>>> On 3/13/13 5:18 AM, Branko Čibej wrote:
>>>>> On 13.03.2013 05:08, Olemis Lang wrote:
>>>>>> On 3/12/13, jure@apache.org <ju...@apache.org> wrote:
>>>>>>> Author: jure
>>>>>>> Date: Tue Mar 12 15:15:22 2013
>>>>>>> New Revision: 1455576
>>>>>>>
>>>>>>> URL: http://svn.apache.org/r1455576
>>>>>>> Log:
>>>>>>> Renamed default product to '@',
>>>>>> @jure: why ?
>>>>> Because it's a token that is forbidden as a product tag and therefore
>>>>> cannot conflict with existing product names.
>>> I'll ask the negation of the negation .
>>>
>>> Why is it that we'll have to apply this change instead of sticking to
>>> '' as global prefix?
>> Just to clarify things, we did not change '' as the global prefix. The
>> default product '@' is the product to which all the tickets w/o product
>> get migrated during upgrade process.
>>
> Oh ! Now I see ... and how will that data be retrieved if we use a
> non-standard prefix ?
Don't see a problem with that as product prefix will only be validated
on product creation through UI.
Cheers,
Jure
Re: svn commit: r1455576 - in /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct:
api.py hooks.py web_ui.py
Posted by Olemis Lang <ol...@gmail.com>.
On 3/13/13, Branko Čibej <br...@wandisco.com> wrote:
>
[...]
> No. I'm not worried about Unicode *validation*, I'm worried about
> Unicode *normalization*.
>
Before I was obviously misunderstanding what you were saying .
>>> Database collations typically
>>> are not normalization-agnostic.
>>>
>> Yes u'r right ... Trac core takes care of that .
>
> Where?
>
... hence this is not accurate as I did not notice I was talking of
another thing .
[...]
>
> Only the second hit actually normalizes anything. Browsers, Javascript,
> etc. etc. do not care about normalization, so two people, e.g., one
> using Mac and another using Windows, can create a product with the tag
>
> unglücklich
>
> and would get two different products with what appears to be the same
> prefix -- but with one in NFD form and the other in NFC form.
>
I'm hoping we can reproduce such scenario(s) in a test case ... based
on your experience do you think having two different OS will be the
only way to reproduce this situation ?
> If you insist this is up to trac-core,
No . Like I said in my previous message the initial proposal does not
touch anything in Trac core . It's about product prefix , so like I
already said BH is the target .
> then this needs to be fixed
> there; however, I'd expect such a fix to also require a database upgrade
> -- i.e., explicitly normalizing all such keys in existing databases.
>
+1
> Of course that could lead to conflicts, but its better to resolve them
> by renaming the keys than by not doing the homework WRT Unicode
> normalization in the first place.
>
We shall see .
https://issues.apache.org/bloodhound/ticket/463
>
> FWIW, Subversion suffers from the same problem, and it's even harder to
> fix there, which is why I'm kind of sensitive to it.
>
... and you are right . Good you were around , otherwise that would
have been overlooked .
--
Regards,
Olemis.
Re: svn commit: r1455576 - in /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct:
api.py hooks.py web_ui.py
Posted by Branko Čibej <br...@wandisco.com>.
On 13.03.2013 17:41, Olemis Lang wrote:
> On 3/13/13, Branko Čibej <br...@wandisco.com> wrote:
>> On 13.03.2013 17:17, Olemis Lang wrote:
>>> On 3/13/13, Branko Čibej <br...@wandisco.com> wrote:
> [...]
>>>> Not to mention that those 4 variants of i have 6 different Unicode
>>>> representations. You do *not* want to deal with Unicode normalization
>>>> issues in primary keys.
>>>>
>>> Like I just said in my previous message ... we already deal with
>>> unicode values in primary keys , so that belongs in the past ...
>> Just make triply sure that Trac core actually does normalize the keys
>> before writing them to the database.
> Ok . In advance I could say that I've seen before test cases all over
> for unicode values and primary keys . Nevertheless , my initial
> suggestion will only have an impact on product prefixes , so anything
> else in Trac will not be the target , it's BH
> ;)
>
>> Otherwise I'd consider that a
>> serious bug, because it leaves room for having two identical-looking
>> primary keys with different bit values.
> A few test cases , and invoking `to_unicode` in the right places and
> afaict everything will be fine .
No. I'm not worried about Unicode *validation*, I'm worried about
Unicode *normalization*.
>> Database collations typically
>> are not normalization-agnostic.
>>
> Yes u'r right ... Trac core takes care of that .
Where?
>> As far as I can see, Trac core only normalizes the names of attachments.
>> That's not enough.
>>
> there are test cases for others e.g. wiki pages ...
Test cases do not cut it. I see a single instance of normalization in
the Trac code:
$ find trac -name '*.py' | xargs fgrep unicodedata
trac/trac/attachment.py:import unicodedata
trac/trac/attachment.py: filename = unicodedata.normalize('NFC', unicode(upload.filename,
trac/trac/util/text.py:from unicodedata import east_asian_width
Only the second hit actually normalizes anything. Browsers, Javascript,
etc. etc. do not care about normalization, so two people, e.g., one
using Mac and another using Windows, can create a product with the tag
unglücklich
and would get two different products with what appears to be the same
prefix -- but with one in NFD form and the other in NFC form.
If you insist this is up to trac-core, then this needs to be fixed
there; however, I'd expect such a fix to also require a database upgrade
-- i.e., explicitly normalizing all such keys in existing databases.
Of course that could lead to conflicts, but its better to resolve them
by renaming the keys than by not doing the homework WRT Unicode
normalization in the first place.
FWIW, Subversion suffers from the same problem, and it's even harder to
fix there, which is why I'm kind of sensitive to it.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: svn commit: r1455576 - in /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct:
api.py hooks.py web_ui.py
Posted by Olemis Lang <ol...@gmail.com>.
On 3/13/13, Branko Čibej <br...@wandisco.com> wrote:
> On 13.03.2013 17:17, Olemis Lang wrote:
>> On 3/13/13, Branko Čibej <br...@wandisco.com> wrote:
[...]
>>> Not to mention that those 4 variants of i have 6 different Unicode
>>> representations. You do *not* want to deal with Unicode normalization
>>> issues in primary keys.
>>>
>> Like I just said in my previous message ... we already deal with
>> unicode values in primary keys , so that belongs in the past ...
>
> Just make triply sure that Trac core actually does normalize the keys
> before writing them to the database.
Ok . In advance I could say that I've seen before test cases all over
for unicode values and primary keys . Nevertheless , my initial
suggestion will only have an impact on product prefixes , so anything
else in Trac will not be the target , it's BH
;)
> Otherwise I'd consider that a
> serious bug, because it leaves room for having two identical-looking
> primary keys with different bit values.
A few test cases , and invoking `to_unicode` in the right places and
afaict everything will be fine .
> Database collations typically
> are not normalization-agnostic.
>
Yes u'r right ... Trac core takes care of that .
> As far as I can see, Trac core only normalizes the names of attachments.
> That's not enough.
>
there are test cases for others e.g. wiki pages ...
--
Regards,
Olemis.
Re: svn commit: r1455576 - in /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct:
api.py hooks.py web_ui.py
Posted by Branko Čibej <br...@wandisco.com>.
On 13.03.2013 17:17, Olemis Lang wrote:
> On 3/13/13, Branko Čibej <br...@wandisco.com> wrote:
>> On 13.03.2013 15:20, Branko Čibej wrote:
>>> On 13.03.2013 09:31, Olemis Lang wrote:
>>>> On 3/13/13, Jure Zitnik <ju...@digiverse.si> wrote:
>>>>> On 3/13/13 8:58 AM, Olemis Lang wrote:
>>>>>
>>>>>> -0 ... I'd suggest (?:(?!\d)\w+) ... which is already available in
>>>>>> multiproduct.util.IDENTIFIER after recent patches .
>>>>> Sure, we can go with that one too ...
>>>>>
>>>> things like Hønsdrükḱenshàpełlmünçen (i.e. unicode chars ;) will be
>>>> supported , which is nice to have ; and will be matched by TracLinks
>>>> expressions
>>>> ;)
>>> I very much disagree with using something like that as the tag that is
>>> effectively a unique key in database columns. Display name is different,
>>> but for database debugging, I really don't want to have to tell the
>>> difference between i and í and ì and ı.
>> Not to mention that those 4 variants of i have 6 different Unicode
>> representations. You do *not* want to deal with Unicode normalization
>> issues in primary keys.
>>
> Like I just said in my previous message ... we already deal with
> unicode values in primary keys , so that belongs in the past ...
Just make triply sure that Trac core actually does normalize the keys
before writing them to the database. Otherwise I'd consider that a
serious bug, because it leaves room for having two identical-looking
primary keys with different bit values. Database collations typically
are not normalization-agnostic.
As far as I can see, Trac core only normalizes the names of attachments.
That's not enough.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: svn commit: r1455576 - in /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct:
api.py hooks.py web_ui.py
Posted by Olemis Lang <ol...@gmail.com>.
On 3/13/13, Branko Čibej <br...@wandisco.com> wrote:
> On 13.03.2013 15:20, Branko Čibej wrote:
>> On 13.03.2013 09:31, Olemis Lang wrote:
>>> On 3/13/13, Jure Zitnik <ju...@digiverse.si> wrote:
>>>> On 3/13/13 8:58 AM, Olemis Lang wrote:
>>>>
>>>>> -0 ... I'd suggest (?:(?!\d)\w+) ... which is already available in
>>>>> multiproduct.util.IDENTIFIER after recent patches .
>>>> Sure, we can go with that one too ...
>>>>
>>> things like Hønsdrükḱenshàpełlmünçen (i.e. unicode chars ;) will be
>>> supported , which is nice to have ; and will be matched by TracLinks
>>> expressions
>>> ;)
>> I very much disagree with using something like that as the tag that is
>> effectively a unique key in database columns. Display name is different,
>> but for database debugging, I really don't want to have to tell the
>> difference between i and í and ì and ı.
>
> Not to mention that those 4 variants of i have 6 different Unicode
> representations. You do *not* want to deal with Unicode normalization
> issues in primary keys.
>
Like I just said in my previous message ... we already deal with
unicode values in primary keys , so that belongs in the past ...
--
Regards,
Olemis.
Re: svn commit: r1455576 - in /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct:
api.py hooks.py web_ui.py
Posted by Andrej Golcov <an...@digiverse.si>.
> Yeah, I don't think we have any need to provide such a large character space
> to work from. I would also make sure that we are case-insensitive for
> prefixes as there should be little need for pr1 not to refer to the same
> thing as PR1. It is annoying to me that milestones are case-sensitive.
+1 to have limited and case-insensitive product prefixes.
Just imaging how uncomfortable it can be to reference product prefix
with escaped url or write wiki links in some language that you don't
have keyboard layout installed for.
Re: svn commit: r1455576 - in /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct:
api.py hooks.py web_ui.py
Posted by Gary Martin <ga...@wandisco.com>.
On 13/03/13 14:23, Branko Čibej wrote:
> On 13.03.2013 15:20, Branko Čibej wrote:
>> On 13.03.2013 09:31, Olemis Lang wrote:
>>> On 3/13/13, Jure Zitnik <ju...@digiverse.si> wrote:
>>>> On 3/13/13 8:58 AM, Olemis Lang wrote:
>>>>
>>>>> -0 ... I'd suggest (?:(?!\d)\w+) ... which is already available in
>>>>> multiproduct.util.IDENTIFIER after recent patches .
>>>> Sure, we can go with that one too ...
>>>>
>>> things like Hønsdrükḱenshàpełlmünçen (i.e. unicode chars ;) will be
>>> supported , which is nice to have ; and will be matched by TracLinks
>>> expressions
>>> ;)
>> I very much disagree with using something like that as the tag that is
>> effectively a unique key in database columns. Display name is different,
>> but for database debugging, I really don't want to have to tell the
>> difference between i and í and ì and ı.
> Not to mention that those 4 variants of i have 6 different Unicode
> representations. You do *not* want to deal with Unicode normalization
> issues in primary keys.
>
> -- Brane
>
>
Yeah, I don't think we have any need to provide such a large character
space to work from. I would also make sure that we are case-insensitive
for prefixes as there should be little need for pr1 not to refer to the
same thing as PR1. It is annoying to me that milestones are case-sensitive.
Cheers,
Gary
Re: svn commit: r1455576 - in /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct:
api.py hooks.py web_ui.py
Posted by Branko Čibej <br...@wandisco.com>.
On 13.03.2013 15:20, Branko Čibej wrote:
> On 13.03.2013 09:31, Olemis Lang wrote:
>> On 3/13/13, Jure Zitnik <ju...@digiverse.si> wrote:
>>> On 3/13/13 8:58 AM, Olemis Lang wrote:
>>>
>>>> -0 ... I'd suggest (?:(?!\d)\w+) ... which is already available in
>>>> multiproduct.util.IDENTIFIER after recent patches .
>>> Sure, we can go with that one too ...
>>>
>> things like Hønsdrükḱenshàpełlmünçen (i.e. unicode chars ;) will be
>> supported , which is nice to have ; and will be matched by TracLinks
>> expressions
>> ;)
> I very much disagree with using something like that as the tag that is
> effectively a unique key in database columns. Display name is different,
> but for database debugging, I really don't want to have to tell the
> difference between i and í and ì and ı.
Not to mention that those 4 variants of i have 6 different Unicode
representations. You do *not* want to deal with Unicode normalization
issues in primary keys.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: svn commit: r1455576 - in /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct:
api.py hooks.py web_ui.py
Posted by Olemis Lang <ol...@gmail.com>.
On 3/13/13, Olemis Lang <ol...@gmail.com> wrote:
> On 3/13/13, Branko Čibej <br...@wandisco.com> wrote:
>> On 13.03.2013 09:31, Olemis Lang wrote:
>>> On 3/13/13, Jure Zitnik <ju...@digiverse.si> wrote:
>>>> On 3/13/13 8:58 AM, Olemis Lang wrote:
>
[...]
>
> OTOH we have a deployment with product prefix all in Simplified
> Chinese
>
[...]
Indeed , at this moment we have 11 instances deployed in local
intranets . 1 in Chinese , all others being Portuguese and Spanish ,
which do have a bunch of non-ASCII chars , but I only recall such
product prefix in the first case ... though I don't know them all .
PS: Indeed in the first case there is a software product that will be
released soon with a public online BH instance . i18n support is a
very important part of the equation for both the target product GUI
and documentation (i.e. BH wiki) .
This all implies that soon somebody in my team will be spending some
time to prepare BH core for i18n I'm hoping such patches will make
their way to upstream ... eventually . As a result we'll also offer at
least a Spanish translation , maybe French and Russian , and clients
will be interested in Simplified Chinese , Korean and Japanese ,
German and Swedish (<= or whatever they use in Sweden to communicate
;) .
--
Regards,
Olemis.
Re: svn commit: r1455576 - in /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct:
api.py hooks.py web_ui.py
Posted by Olemis Lang <ol...@gmail.com>.
On 3/13/13, Branko Čibej <br...@wandisco.com> wrote:
> On 13.03.2013 09:31, Olemis Lang wrote:
>> On 3/13/13, Jure Zitnik <ju...@digiverse.si> wrote:
>>> On 3/13/13 8:58 AM, Olemis Lang wrote:
>>>
>>>> -0 ... I'd suggest (?:(?!\d)\w+) ... which is already available in
>>>> multiproduct.util.IDENTIFIER after recent patches .
>>> Sure, we can go with that one too ...
>>>
>> things like Hønsdrükḱenshàpełlmünçen (i.e. unicode chars ;) will be
>> supported , which is nice to have ; and will be matched by TracLinks
>> expressions
>> ;)
>
> I very much disagree with using something like that as the tag that is
> effectively a unique key in database columns.
I don't think that would be more problematic than what we have right
now . Just notice that wiki page name (+ version) is a key field in
wiki table . I just created one such wiki page named ÁéíóúÄëïöü and it
goes through without any particular trouble . Indeed if you make the
experiment just type ÁéíóúÄëïöü inside in any other wiki text and
Trac's built-in wiki parser will even detect it as a CamelCase
expression . Isn't it great ? :)
Then I type
http://server.tld/bh/env/wiki/ÁéíóùÄëïöü and everything works as a charm ...
> Display name is different,
> but for database debugging, I really don't want to have to tell the
> difference between i and í and ì and ı.
>
I understand your point
OTOH we have a deployment with product prefix all in Simplified
Chinese (I will not have the courage to suggest a CamelCase expression
like I did above :P) and I see no particular reason for limiting users
this way , if they want to . Trac core is smart enough to deal with
these matters . Other deployment-specific concerns such as missing
keyboard layouts will not be a problem in many contexts .
Laissez-faire !
;)
Considering those facts I kindly request to make support for unicode
product prefixes an option , turned off by default .
--
Regards,
Olemis.
Re: svn commit: r1455576 - in /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct:
api.py hooks.py web_ui.py
Posted by Branko Čibej <br...@wandisco.com>.
On 13.03.2013 09:31, Olemis Lang wrote:
> On 3/13/13, Jure Zitnik <ju...@digiverse.si> wrote:
>> On 3/13/13 8:58 AM, Olemis Lang wrote:
>>
>>> -0 ... I'd suggest (?:(?!\d)\w+) ... which is already available in
>>> multiproduct.util.IDENTIFIER after recent patches .
>> Sure, we can go with that one too ...
>>
> things like Hønsdrükḱenshàpełlmünçen (i.e. unicode chars ;) will be
> supported , which is nice to have ; and will be matched by TracLinks
> expressions
> ;)
I very much disagree with using something like that as the tag that is
effectively a unique key in database columns. Display name is different,
but for database debugging, I really don't want to have to tell the
difference between i and í and ì and ı.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: svn commit: r1455576 - in /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct: api.py hooks.py web_ui.py
Posted by Joe Dreimann <jo...@wandisco.com>.
On 13 Mar 2013, at 08:31, Olemis Lang <ol...@gmail.com> wrote:
> On 3/13/13, Jure Zitnik <ju...@digiverse.si> wrote:
>> On 3/13/13 8:58 AM, Olemis Lang wrote:
>>> On 3/13/13, Jure Zitnik <ju...@digiverse.si> wrote:
>>>> On 3/13/13 5:18 AM, Branko Čibej wrote:
>>>>> On 13.03.2013 05:08, Olemis Lang wrote:
>>>>>> On 3/12/13, jure@apache.org <ju...@apache.org> wrote:
>>>>>>> Author: jure
>>>>>>> Date: Tue Mar 12 15:15:22 2013
>>>>>>> New Revision: 1455576
>>>>>>>
>>>>>>> URL: http://svn.apache.org/r1455576
>>>>>>> Log:
>>>>>>> Renamed default product to '@',
>>>>>> @jure: why ?
>>>>> Because it's a token that is forbidden as a product tag and therefore
>>>>> cannot conflict with existing product names.
>>> I'll ask the negation of the negation .
>>>
>>> Why is it that we'll have to apply this change instead of sticking to
>>> '' as global prefix?
>>
>> Just to clarify things, we did not change '' as the global prefix. The
>> default product '@' is the product to which all the tickets w/o product
>> get migrated during upgrade process.
>
> Oh ! Now I see ... and how will that data be retrieved if we use a
> non-standard prefix ?
>
> PS: /me just wandering to be consistent with the new convention ;)
>
>>>> Brane, I double checked and currently there's no prefix checking on
>>>> product creation, though we should add one to prevent someone from
>>>> adding product with funky prefixes, including the reserved '@' ... I
>>>> think '^[a-zA-Z0-9_]+$' would suffice for now.
>>> -0 ... I'd suggest (?:(?!\d)\w+) ... which is already available in
>>> multiproduct.util.IDENTIFIER after recent patches .
>>
>> Sure, we can go with that one too ...
>
> things like Hønsdrükḱenshàpełlmünçen (i.e. unicode chars ;) will be
> supported , which is nice to have ; and will be matched by TracLinks
> expressions
> ;)
That would make many Germans überglücklich!
- Joachim
>
> --
> Regards,
>
> Olemis.
Re: svn commit: r1455576 - in /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct:
api.py hooks.py web_ui.py
Posted by Olemis Lang <ol...@gmail.com>.
On 3/13/13, Jure Zitnik <ju...@digiverse.si> wrote:
> On 3/13/13 8:58 AM, Olemis Lang wrote:
>> On 3/13/13, Jure Zitnik <ju...@digiverse.si> wrote:
>>> On 3/13/13 5:18 AM, Branko Čibej wrote:
>>>> On 13.03.2013 05:08, Olemis Lang wrote:
>>>>> On 3/12/13, jure@apache.org <ju...@apache.org> wrote:
>>>>>> Author: jure
>>>>>> Date: Tue Mar 12 15:15:22 2013
>>>>>> New Revision: 1455576
>>>>>>
>>>>>> URL: http://svn.apache.org/r1455576
>>>>>> Log:
>>>>>> Renamed default product to '@',
>>>>> @jure: why ?
>>>> Because it's a token that is forbidden as a product tag and therefore
>>>> cannot conflict with existing product names.
>> I'll ask the negation of the negation .
>>
>> Why is it that we'll have to apply this change instead of sticking to
>> '' as global prefix?
>
> Just to clarify things, we did not change '' as the global prefix. The
> default product '@' is the product to which all the tickets w/o product
> get migrated during upgrade process.
>
Oh ! Now I see ... and how will that data be retrieved if we use a
non-standard prefix ?
PS: /me just wandering to be consistent with the new convention ;)
>>> Brane, I double checked and currently there's no prefix checking on
>>> product creation, though we should add one to prevent someone from
>>> adding product with funky prefixes, including the reserved '@' ... I
>>> think '^[a-zA-Z0-9_]+$' would suffice for now.
>>>
>> -0 ... I'd suggest (?:(?!\d)\w+) ... which is already available in
>> multiproduct.util.IDENTIFIER after recent patches .
>
> Sure, we can go with that one too ...
>
things like Hønsdrükḱenshàpełlmünçen (i.e. unicode chars ;) will be
supported , which is nice to have ; and will be matched by TracLinks
expressions
;)
--
Regards,
Olemis.
Re: svn commit: r1455576 - in /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct:
api.py hooks.py web_ui.py
Posted by Jure Zitnik <ju...@digiverse.si>.
On 3/13/13 8:58 AM, Olemis Lang wrote:
> On 3/13/13, Jure Zitnik <ju...@digiverse.si> wrote:
>> On 3/13/13 5:18 AM, Branko Čibej wrote:
>>> On 13.03.2013 05:08, Olemis Lang wrote:
>>>> On 3/12/13, jure@apache.org <ju...@apache.org> wrote:
>>>>> Author: jure
>>>>> Date: Tue Mar 12 15:15:22 2013
>>>>> New Revision: 1455576
>>>>>
>>>>> URL: http://svn.apache.org/r1455576
>>>>> Log:
>>>>> Renamed default product to '@',
>>>> @jure: why ?
>>> Because it's a token that is forbidden as a product tag and therefore
>>> cannot conflict with existing product names.
> I'll ask the negation of the negation .
>
> Why is it that we'll have to apply this change instead of sticking to
> '' as global prefix?
Just to clarify things, we did not change '' as the global prefix. The
default product '@' is the product to which all the tickets w/o product
get migrated during upgrade process.
>> Brane, I double checked and currently there's no prefix checking on
>> product creation, though we should add one to prevent someone from
>> adding product with funky prefixes, including the reserved '@' ... I
>> think '^[a-zA-Z0-9_]+$' would suffice for now.
>>
> -0 ... I'd suggest (?:(?!\d)\w+) ... which is already available in
> multiproduct.util.IDENTIFIER after recent patches .
Sure, we can go with that one too ...
Cheers,
Jure
Re: svn commit: r1455576 - in /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct:
api.py hooks.py web_ui.py
Posted by Olemis Lang <ol...@gmail.com>.
On 3/13/13, Jure Zitnik <ju...@digiverse.si> wrote:
> On 3/13/13 5:18 AM, Branko Čibej wrote:
>> On 13.03.2013 05:08, Olemis Lang wrote:
>>> On 3/12/13, jure@apache.org <ju...@apache.org> wrote:
>>>> Author: jure
>>>> Date: Tue Mar 12 15:15:22 2013
>>>> New Revision: 1455576
>>>>
>>>> URL: http://svn.apache.org/r1455576
>>>> Log:
>>>> Renamed default product to '@',
>>> @jure: why ?
>> Because it's a token that is forbidden as a product tag and therefore
>> cannot conflict with existing product names.
I'll ask the negation of the negation .
Why is it that we'll have to apply this change instead of sticking to
'' as global prefix?
>
> Brane, I double checked and currently there's no prefix checking on
> product creation, though we should add one to prevent someone from
> adding product with funky prefixes, including the reserved '@' ... I
> think '^[a-zA-Z0-9_]+$' would suffice for now.
>
-0 ... I'd suggest (?:(?!\d)\w+) ... which is already available in
multiproduct.util.IDENTIFIER after recent patches .
--
Regards,
Olemis.
Re: svn commit: r1455576 - in /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct:
api.py hooks.py web_ui.py
Posted by Jure Zitnik <ju...@digiverse.si>.
On 3/13/13 5:18 AM, Branko Čibej wrote:
> On 13.03.2013 05:08, Olemis Lang wrote:
>> On 3/12/13, jure@apache.org <ju...@apache.org> wrote:
>>> Author: jure
>>> Date: Tue Mar 12 15:15:22 2013
>>> New Revision: 1455576
>>>
>>> URL: http://svn.apache.org/r1455576
>>> Log:
>>> Renamed default product to '@',
>> @jure: why ?
> Because it's a token that is forbidden as a product tag and therefore
> cannot conflict with existing product names.
Brane, I double checked and currently there's no prefix checking on
product creation, though we should add one to prevent someone from
adding product with funky prefixes, including the reserved '@' ... I
think '^[a-zA-Z0-9_]+$' would suffice for now.
Cheers,
Jure
Re: svn commit: r1455576 - in /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct:
api.py hooks.py web_ui.py
Posted by Branko Čibej <br...@wandisco.com>.
On 13.03.2013 05:08, Olemis Lang wrote:
> On 3/12/13, jure@apache.org <ju...@apache.org> wrote:
>> Author: jure
>> Date: Tue Mar 12 15:15:22 2013
>> New Revision: 1455576
>>
>> URL: http://svn.apache.org/r1455576
>> Log:
>> Renamed default product to '@',
> @jure: why ?
Because it's a token that is forbidden as a product tag and therefore
cannot conflict with existing product names.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com