Re: [tryton-dev] Debian link broken

[Mathias Behrle]

* Cédric Krier: " Re: [tryton-dev] Debian link broken" (Sat, 2 Jun 2018
  10:14:19 +0200):

> On 2018-05-31 10:27, Luciano Rossi wrote:
> > The url http://debian.tryton.org still is redirecting to the old entry 
> > http://tryton.alioth.debian.org  
> 
> The Tryton DNS only set an IP for debian.tryton.org. This is an IP that
> Mathias provided. So I do not know if we should stop this DNS record and
> manage the redirect ourself, or if the targeted machine can be updated
> or if we should just drop this shortcut.

Thanks, Luciano, for the hint. The redirect is now adjusted.

The DNS is currently (still) needed to resolve to the mirror. The forward of
the root entry could be managed by tryton.org. So no big deal one way or the
other.

Cheers,
Mathias

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

-- 
You received this message because you are subscribed to the Google Groups 
"tryton-dev" group.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tryton-dev/20180602150242.3d040a67%40monsterix.mbehrle.de.


pgp4VIVBuntTH.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] Debian link broken

[Mathias Behrle]

* Cédric Krier: " [tryton-dev] Debian link broken" (Thu, 24 May 2018 13:26:34
  +0200):

> Hi,
> 
> The Debian link https://tryton.alioth.debian.org/ on
> http://www.tryton.org/download.html does not return any more useful
> information.
> Does anyone know what is happening?

alioth.debian.org has finally closed down and all repositories have moved over
to salsa.debian.org.

The new entry point is

 https://tryton-team.pages.debian.net/


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

-- 
You received this message because you are subscribed to the Google Groups 
"tryton-dev" group.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tryton-dev/20180524215322.4b4d4053%40monsterix.mbehrle.de.


pgpjJ7TtRYsYj.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] Impact mitigation for DDoS attack

[Mathias Behrle]

* Nicolas Évrard: " Re: [tryton-dev] Impact mitigation for DDoS attack" (Wed,
  14 Feb 2018 13:55:48 +0100):

Hello again,

> * Mathias Behrle  [2018-02-14 12:17 +0100]: 
>>* Nicolas Évrard: " Re: [tryton-dev] Impact mitigation for DDoS attack" (Wed,
>>  14 Feb 2018 10:46:38 +0100):
>>
>>Hi together,  
> 
> Hello,
> 
>>I am still missing a thorough handling of the _several_ _different_ involved
>>issues as proposed in
>>
>>https://bugs.tryton.org/issue5375 (specifically
>>https://bugs.tryton.org/msg24691)  
> 
> Quite frankly I don't think there is much to discuss in this message.
> But you might elaborate more on the issue so that I can understand
> what should be discussed.

There are 3 topics explicitely identified. Could you please elaborate what you
don't understand?

>>and
>>
>>https://bugs.tryton.org/issue7111 (specifically
>>https://bugs.tryton.org/msg38228)  
> 
> - Session management: there is a recent issue about that

To which issue are you refering exactly, a quick search on the bugtracker
didn't reveal any hit [1]?
 
> - Login delay: we can discuss it at length, the policy we have
>   won't change for the reasons exposed by Cédric in another email
>   But as my review on appspot displays if people want they can use
>   a different strategy.

Thanks for that. It is a bit complicated to find that review under a
totally unrelated topic (Remove openSUSE packages)

https://bugs.tryton.org/issue7111 >
https://bugs.tryton.org/msg38228 >
https://bugzilla.opensuse.org/show_bug.cgi?id=1078111 >
https://bugzilla.opensuse.org/show_bug.cgi?id=1078111#c19 >
https://codereview.appspot.com/335550043/

Wouldn't it be worth to post that example of a possible modification on a more
prominent place?
   
> - Usability aspects: I don't understand what you mean

You shortened the complete sentence which was
- Usability aspects (as in punishment of wrong password entries and with regard
  to distributions in general)

I want to elaborate on the two given examples:
- punishment of wrong password entries
  While there was a lot of input and I would say agreement, that there *has* to
  be a login delay, there was never agreement about the duration. The
  exponential login timeout in terms of brute force attack is fairly oversized.
  So when you want to keep that absolutely we comes to usability aspects
  in terms of user friendlyness: a well concepted login manager (e.g. on
  android) doesn't let the user in the dark, but tells him, that after a
  failed login he has to wait for x seconds and then counts them down. The
  Tryton GTK-interface instead just goes unresponsive giving the impression of
  a hanging application. There is great probability that a half-experienced
  user will just hard kill it, because he thinks there is going something wrong.
- and with regard to distributions in general
  
  Speaking with my Debian maintainer hat on I consider the step taken in
  https://bugs.tryton.org/issue7111 as regrettably and wrong.
  - I can not see how the mere *listing* of distributions on the website
can be considered an *advice*.
  - Shouldn't it be just a sign of mutual respect for both sides? Distributions
should be happy about the existence of Tryton and in the same way Tryton
should be glad to be recognized and integrated into the major
distributions. Glad to here your and the general input on this subject.
  - Compared to some other security related topics issue7111 is highly
exaggerated. What will the foundation or the maintainer do about sao where
the maintained series will be affected by a security-wise unmaintained
jquery version?
Have a look at https://bugs.tryton.org/issue5925 which was created
at 2016-10-03.16:09:27. The referenced issue [2] to justify the now
impending upgrade dates from 2016-10-06. It was already clear at the time
of the creation of issue5925 that bootstrap 3.3.7 supports jquery 3+,
but there was no action taken. Sao now will suffer in all currently
maintained stable series from the usage of an unsupported jquery version.
  
Will that lead to a big fat warning on the website or to the removal of sao
<= 4.6?
 
> - Hardening of trytond against brute force attack: It's linked to
>   the login delay. If you're able to display another kind of
>   attack vector please open a security issue

I would have prefered to have the discussion at discuss.tryton.org or at
least bugs.tryton.org. Unfortunately the further discussion of this topic
happened on the OpenSUSE tracker.The last comment is
https://bugzilla.opensuse.org/show_bug.cgi?id=1078111#c22
with the proposal of a patch that is uncommented so far.

> - Hardening trytond agains DDOS attack: we can also discuss it at
>   length on the mailing list but in the e

Re: [tryton-dev] Impact mitigation for DDoS attack

[Mathias Behrle]

* Nicolas Évrard: " Re: [tryton-dev] Impact mitigation for DDoS attack" (Wed,
  14 Feb 2018 10:46:38 +0100):

Hi together,

I am still missing a thorough handling of the _several_ _different_ involved
issues as proposed in

https://bugs.tryton.org/issue5375 (specifically
https://bugs.tryton.org/msg24691)

and

https://bugs.tryton.org/issue7111 (specifically
https://bugs.tryton.org/msg38228)

So I am not really surprised to see the discussion moving in circles.
Nevertheless there is work in progress to improve the situation which is (while
nto sufficiently discussed and reviewed) probably a good thing:

https://codereview.tryton.org/41031002/
https://codereview.tryton.org/39171002/

> * Axel Braun  [2018-02-14 10:27 +0100]: 
>>Am Sonntag, 4. Februar 2018 00:30:05 UTC+1 schrieb Cédric Krier:  
>>> On 2018-02-03 07:48, Axel Braun wrote:  
>>>> Am Montag, 29. Januar 2018 23:25:07 UTC+1 schrieb Cédric Krier:  
>>>>> On 2018-01-29 12:47, Axel Braun wrote:  
>>>>>> I would like to discuss https://bugs.tryton.org/issue5375 with all
>>>>>> developers involved.  
>>>>>
>>>>> All developers have already commented on the issue and we all agree
>>>>> that the proposal is wrong, solves nothing and weakens the brute force
>>>>> attack protection.  
>>>>
>>>> We had a constructive and friendly discussion about the topic
>>>> here: https://bugzilla.opensuse.org/show_bug.cgi?id=1078111  
>>>
>>> What I read is that more people agree that the applied patch does not
>>> solve any issue and disable the brute force attack protection.  
>>
>>Maybe you should read more carefully: The current implementation in
>>Tryton, that allows you to bring the whole system down by flooding
>>the database with login requests is rubbish (OK, the security team
>>phrased it more politely)  
> 
> If you've read everything carefully then you will also notice that the
> security team does not have all the use cases in mind when it comes to
> make a decision. Of course, in a single instance trytond there are
> better options available but I am still waiting for a better approach
> when taking into account the multi-platform, multi-instance use cases
> that we do care about.

I just want to re-throw into the discussion to consider the use of an in-memory
database like redis for session management.

https://stackoverflow.com/questions/10278683/how-safe-it-is-to-store-session-with-redis
https://www.digitalocean.com/community/tutorials/how-to-set-up-a-redis-server-as-a-session-handler-for-php-on-ubuntu-16-04
https://matomo.org/faq/how-to/faq_20521/

I think we all agree that it is better to catch (D)DoS on the server level
instead of the database level, i.e. when undergoing a DDoS attack the Tryton
server or its authentication backend should catch the load and eventually go
unresponsive, but not the database backend. I think many of the concerns
presented by Luis and by Axel could be mitigated by the implementation of an
optional session management bypassing the production database.

Thoughts?

>>>> The advise from the security team should be considered for a future
>>>> patch.  
>>>
>>> But more importantly, the applied patch on the OpenSUSE package must be
>>> removed ASAP to not expose OpenSUSE users of the Tryton package to brute
>>> force attack against their password.  
>>
>>Dunno if you have read the link you have posted above
>>(https://www.schneier.com/blog/archives/2009/01/bad_password_se.html)
>>yourself, but the first comment already describes it pretty well.
>>
>>Up to now we have no better patch in place. The proposed patch
>>https://codereview.appspot.com/335550043/ makes thing even worse.  
> 
> Explain how exactly.
> 
> Because for me that would be a solution: instead of patching trytond
> with the really bad patch you're using you could just patch GNU Health
> (thus not impacting users of trytond) and you're done, this whole
> issue become void.

I beg to disagree. There is not this whole issue, but as depicted above there
are several separate issues. Let's identify them and handle them separately in
a clean way. We all will profit from the results of the then hopefully fruitful
discussions.
 
> Granted the patch is not perfect (a check on the size of the
> dictionary and the use of the database name are things that comes to
> my mind). But it does what Luis wants so badly: stop anonymous logging
> in the database.
> 



-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BB

-- 
You received this message because you are subscribed to the Google Groups 
"tryton-dev" group.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tryton-dev/20180214121746.67cefc26%40monsterix.mbehrle.de.


pgpIafFlcpvEl.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] Translations updated for 4.4

[Mathias Behrle]

* Cédric Krier: " Re: [tryton-dev] Translations updated for 4.4" (Thu, 13 Apr
  2017 16:22:32 +0200):

> On 2017-04-04 11:59, Cédric Krier wrote:
> > If you want to help, please contact the language administrators to be
> > included in the team.  
> 
> Indeed it is not so ease to find the language administrator on Pootle.
> So if you have doubt, you can just send an email here.

JFTR the German language leader since 27.2.2017 is Clemens Hupka (with
username "clews" on pootle.tryton.org).

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6l

-- 
You received this message because you are subscribed to the Google Groups 
"tryton-dev" group.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tryton-dev/20170416231019.4d67a6bc%40privatix.mbehrle.de.


pgp8EeB8PHHWV.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] How to write tooltips

[Mathias Behrle]

* 'Udo Spallek' via tryton-dev: " Re: [tryton-dev] How to write tooltips" (Wed,
  28 Sep 2016 11:34:14 +0200):

> Hi,
> 
> Wed, 28 Sep 2016 10:34:21 +0200
> Cédric Krier <cedric.kr...@b2ck.com>:
> >I started a discussion to rationalize how we should write tooltips in
> >Tryton:
> >https://discuss.tryton.org/t/how-to-write-tooltips/212
> >I think the TUB2016 sprint could be a good place to improve the
> >discoverability of the application. (to replace the never starting
> >project of writing documentation)  
> 
> it is IMHO a very good initiative! 

+1

> And it would push a bit the idea of
> an auto-generated documentation made of internal help strings.

Perhaps a little bit, but tooltips can not and should not replace
documentation (see my answer at
https://discuss.tryton.org/t/how-to-write-tooltips/212)

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

-- 
You received this message because you are subscribed to the Google Groups 
"tryton-dev" group.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tryton-dev/20160928122819.22ba3430%40monsterix.mbehrle.de.


pgprij2f6F7vg.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] New __init__ style

[Mathias Behrle]

* Cédric Krier: " [tryton-dev] New __init__ style" (Wed, 24 Aug 2016 12:59:25
  +0200):

> Hi,
> 
> Since some time, I'm a little bit annoyed by our exception about
> "import *" in __init__.py. It will be great if we could have no more
> those warning.
> So I propose to gradually change our style to use this one (example from
> party module):
> 
> import category
> import party
> …
> 
> def register():
> Pool.register(
> category.Category,
> party.Party,
> party.PartyCategory,
> …)
> 
> I find that it has three advantages:
> 
> - remove the "import *"
> - remove collision risk about class name
> - show which python file comes a class
> 
> What do you think?


Alternative:

from category import Category
from party import Party, PartyCategory
...

def register():
...no need to change
 

While this should meet all three advantages cited above as well, it has for me
the additional advantage of a more accustomed view of imports.


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

-- 
You received this message because you are subscribed to the Google Groups 
"tryton-dev" group.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tryton-dev/20160824164451.74dd0b2f%40monsterix.mbehrle.de.


pgpwlmIwpV1DZ.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] Translation

[Mathias Behrle]

* Cédric Krier: " Re: [tryton-dev] Translation" (Tue, 20 Oct 2015 15:20:03
  +0200):

> On 2015-10-20 13:58, Mathias Behrle wrote:
> > * Cédric Krier: " [tryton-dev] Translation" (Tue, 6 Oct 2015 01:42:07
> > +0200):
> > 
> > @translators
> > 
> > We just made available a script, that allows one to link the po files to a
> > Tryton clone thus being able to use the Tryton translation interface and
> > re-import the generated po files to pootle. The script is available at
> > 
> > https://gitlab.com/m9s/tryton-tools/raw/master/link_pootle2tryton.py
> > 
> > and quite self-documented.
> 
> I will discourage translators to use this way because it completely
> breaks the goal of Pootle which is to make translation a shared and
> collaborative effort. Because having one single translator holding the
> all process (as we had before) just creates a bottleneck and make
> contribution almost impossible. We can already see the benefit of Pootle
> by the number of new languages we have for this release (4).

As you can easily see from the german translation both ways are complementary.
Instead of discouraging people it would be better to support the best overall
possible tool set.

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgp_0L793EUpP.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] Question regarding new translatons in 3.6.1

[Mathias Behrle]

* Axel Braun:  [tryton-dev] Question regarding new translatons in 3.6.1 (Wed,
  8 Jul 2015 03:07:44 -0700 (PDT)):

 Hi all,
 
 the RPM build script removes the newly translated languages in 
 Tryton-Client 3.6.1:
 
 [   80s] + /usr/lib/rpm/find-lang.sh 
 /home/abuild/rpmbuild/BUILDROOT/tryton-3.6.1-0.i386 tryton --without-C
 [   80s] removing translation 
 /usr/share/locale/bg_BG/LC_MESSAGES/tryton.mo: 377 translated messages.
 [   81s] removing translation 
 /usr/share/locale/lt_LT/LC_MESSAGES/tryton.mo: 386 translated messages.
 [   81s] removing translation 
 /usr/share/locale/ca_ES/LC_MESSAGES/tryton.mo: 402 translated messages.
 [   81s] removing translation 
 /usr/share/locale/nl_NL/LC_MESSAGES/tryton.mo: 338 translated messages.
 [   81s] removing translation 
 /usr/share/locale/ja_JP/LC_MESSAGES/tryton.mo: stdin:81: 'msgid' and 
 'msgstr' entries do not both end with '\n'
 [   81s] stdin:383: 'msgid' and 'msgstr' entries do not both end with '\n'
 [   81s] stdin:709: 'msgid' and 'msgstr' entries do not both end with '\n'
 [   81s] stdin:877: 'msgid' and 'msgstr' entries do not both end with '\n'
 [   81s] msgfmt: found 4 fatal errors
 [   81s] 337 translated messages.
 
 Anyone seen such an error before?

Yes. You can have the look at the Debian l10n QA page to see the used command
and the result there. Those sanity checks make sense (and often reveal slight
mistakes in translation), but shouldn't be fatal for the package result as such
differences can be intended by translators.

The removal of those (espacially the clean) languages above seems for me a bug
in /usr/lib/rpm/find-lang.sh 

 How can I check the content of the .mo file?

Correct the po file and recompile the mo file, mostly automatically done when
working with poedit.


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgpcbpJ62Tw7Z.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] Colors of fields and feedback for current interface

[Mathias Behrle]

* Jordi Esteve:  Re: [tryton-dev] Colors of fields (Sat, 04 Jul 2015 10:49:44
  +0200):

 On 04/07/15 08:58, Cédric Krier wrote:
  Hi,
 
  For now, we put a blue color on entries when they are required (and
  switch to red when validated as empty).
  I think it is a bad practice for 2 reasons:
 
   - the colors are not custumizable and so they could not work on some
 thèmes.
 
   - it is doesn't help the accessibility [1] as this information is
 only based on color.
 
  So I was thinking instead about adding a * on the labels of the
  required fields. This still stay quite visual (but not too much) and
  readable for accessibility.
 
  What do you think? Has anyone a better idea?
 
 
 I suggest to not remove the current behaviour. The blue color and 
 switching to red if the field is not filled is intuitive and clear for 
 most people, the asterisk is not intuitive (needs a previous 
 explanation), so I suggest adding a * without removing current behaviour.

Marking a field with a star is On/Off, while currently with colors we have the
evidence, that a field is required *and* showing after the validation,
which fields missed the validation. So by replacing colors with stars we would
lose one information level. Perhaps this could be solved by differentiating with
small and big star (small for required field, big for missing validation).

OTOH I would appreciate indeed, that the idea to surround the field with a red
line instead of coloring the background would make its way [0].
This change would make the interface less shouting, but more informative.

BTW the current state after [1] indeed confirms my reservations about a
unsteady moving interface [2]. You did your best to make it unobtrusive, but
the result is nevertheless, that after clicking a record and shifting of the
interface the mouse pointer is located above a different record and the user
has to re-orientate himself. I really don't like those unintentional jumping
interfaces on user interactions, perhaps other Trytonistas could give feedback
as well.
Even if in sao the info bar should be better placed at the top (I didn't have a
look at that), this shouldn't dictate the behavior of the gtk client. I don't
feel it to be the right approach to try to copy *slavishly* the gtk and the web
interface. Both interfaces have different pros and cons. When the web interface
affords different means for informational messages, the gtk client shouldn't
lose parts of his usability just to match the layout of this info bar in the
web client.

Just last but not least: I would prefer to have the messages centered like in
the initial proposal [3]. Currently they display left-aligned.


[0] https://bugs.tryton.org/msg20371
[1] http://hg.tryton.org/tryton/rev/4aabbd421cf5
[2] https://bugs.tryton.org/issue3465
[3] https://bugs.tryton.org/file2223/form_error.png

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgpkMU6crk1XU.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] Confirm date on sales and purchases

[Mathias Behrle]

* Albert Cervera i Areny:  [tryton-dev] Confirm date on sales and
  purchases (Mon, 22 Jun 2015 09:43:17 +0200):

 Currently sales (and purchases) have a single date field which in case
 of a sale will usually show the date the user used as the quotation
 date.

Yes, the field should rather be named 'Quotation date'.
 
 Many times it is important to keep that date when the sale is
 confirmed yet it is also important to know the date at which the sale
 was confirmed.

Indeed the confirmation date is even more important, since it determines the
effective date in relation to legislation.

 I'm thinking on adding a confirmation date on sales and in my opinion
 it makes sense to add that to core sale module.
 
 Opinions?


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgpaNUFXYmWbe.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] Using Pootle to translate Tryton

[Mathias Behrle]

* Cédric Krier:  [tryton-dev] Using Pootle to translate Tryton (Sat, 13 Jun
  2015 13:59:31 +0200):

 I have setup a Pootle instance to ease the translation of Tryton.
 The instance is running at http://pootle.tryton.org/
 
 If you are a current translator, please create an account, I will give
 you administration right for this language. This will give you the right
 to request update from the source, push/commit the translation and
 manage access right for this language.

I don't understand so far the complete process. As far as German translation is
concerned we have a well established procedure using codereview which is much
better laid out for our purpose than the pootle interface. I see practically no
advantage for us (German translation) in using pootle, it will create more work
instead. I would really like to keep the well established and productive
process for the German community. I can not read from this thread so far, if I
will be forced to use pootle or if it is possible to use the old well-proven and
productive process.


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgpRVNxMDOWkM.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] Database schema name limit

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Database schema name limit (Sat, 23 May
  2015 12:18:32 +0200):

 On 23 May 11:01, Mathias Behrle wrote:
  * Cédric Krier:  [tryton-dev] Database schema name limit (Thu, 21 May 2015
17:52:57 +0200):
  
   Hi,
   
   I'm facing a limitation with how trytond generate the table name for a
   ModelSQL. Databases have different length limitation for schema name.
   For example,
   PostgreSQL has the limit to 64 when Oracle has the limit to 30
   (yes I'm working on an Oracle backend).
   
   I don't want that we change our naming convention because it is quite
   good and reducing the name will just bring a lot in readability.
   And we will be forced to use the least common constraint.
   
   So my idea is to have a configuration section which will provide the
   table name to use for a Model.
   
   Example:
   
   [table]
   account.invoice.payment_term.line.relativedelta = acc_inv_pt_l_reldelta
   account.payment.sepa.message = acc_payment_sepa_msg
   
   Of course such configuration could not be modified once a database has
   been created (or the table should be renamed).
   
   Side effect, it could also be used to fix naming conflict between 2
   unrelated module (at the database level not Model.__name__).
   
   What do you think?
  
  The backside of this translation table is, that you have to know beforehand
  all tables in your database, before you install them and that it has to be
  done manually.
 
 Yes but any way, any *real* production installation will require to
 customize the database schema. I always thought that Tryton will never
 generate the perfect schema but only a minimal working schema.
 
  What about a configuration option 'oracle_compatibility = True', that will
  slug the ususal names in a reproducible way?
 
 The problem is not oracle. The problem is the limitation that all
 databases have.
 But if you have a better solution, I will be graceful to evaluate.
 For example, a good algorithm to generate size compatible from Model
 name.

As we seem to have a maximal length of 64, I would propose to just truncate
table names, that hit that limit and to number them for avoidance of
collisions, e.g.:
table_name_longer_than_sixtyfour_xx
would transform to 
table_name_longer_than_sixtyfour_xx_001

If that maximal table name length cannot be determined automatically
(with python-sql or by some other means) this could be
the configuration parameter 'table_name_max_length'.

Additionally we could introduce the configuration option
'table_element_length'

The expected results would be
e.g. with 
table_element_length = 3
table_name_max_length = 32

account.invoice.payment_term.line.relativedelta = acc_inv_pay_ter_lin_rel
account.payment.sepa.message = acc_pay_sep_mes

table.name.longer.than.sixtyfour..y =
tab_nam_lon_tha_six_xxx_yyy

table.name.longer.than.sixtyfour..yy.z =
tab_nam_lon_tha_six_xxx_yyy_001

The shorter the elements will be, the less a table name of course will be
readable for its underlying model. But an algorithm like this seems to a good
compromise for me.


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgpgQmEkq2TVD.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] Database schema name limit

[Mathias Behrle]

* Cédric Krier:  [tryton-dev] Database schema name limit (Thu, 21 May 2015
  17:52:57 +0200):

 Hi,
 
 I'm facing a limitation with how trytond generate the table name for a
 ModelSQL. Databases have different length limitation for schema name.
 For example,
 PostgreSQL has the limit to 64 when Oracle has the limit to 30
 (yes I'm working on an Oracle backend).
 
 I don't want that we change our naming convention because it is quite
 good and reducing the name will just bring a lot in readability.
 And we will be forced to use the least common constraint.
 
 So my idea is to have a configuration section which will provide the
 table name to use for a Model.
 
 Example:
 
 [table]
 account.invoice.payment_term.line.relativedelta = acc_inv_pt_l_reldelta
 account.payment.sepa.message = acc_payment_sepa_msg
 
 Of course such configuration could not be modified once a database has
 been created (or the table should be renamed).
 
 Side effect, it could also be used to fix naming conflict between 2
 unrelated module (at the database level not Model.__name__).
 
 What do you think?

The backside of this translation table is, that you have to know beforehand all
tables in your database, before you install them and that it has to be done
manually.

What about a configuration option 'oracle_compatibility = True', that will slug
the ususal names in a reproducible way?



-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgp4KUq7yLfz8.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] Freeze of repositories

[Mathias Behrle]

* Mathias Behrle:  Re: [tryton-dev] Freeze of repositories (Wed, 1 Apr 2015
  02:41:37 +0200):

 * Cédric Krier:  Re: [tryton-dev] Freeze of repositories (Wed, 1 Apr 2015
   00:45:46 +0200):
 
  On 31 Mar 16:56, Cédric Krier wrote:
   On 31 Mar 15:47, Mathias Behrle wrote:
Using most recent hgnested:

$ hg nclone ssh://h...@hg.tryton.org/trytond 
Zielverzeichnis: trytond
[trytond]
Sende alle Änderungen
582 Dateien zum Übertragen, 8.58 MB an Daten
8.58 MB in 33.8 Sekunden übertragen (260 KB/Sek)
Aktualisiere auf Zweig default
382 Dateien aktualisiert, 0 Dateien zusammengeführt, 0 Dateien
entfernt, 0 Dateien ungelöst

[trytond/trytond/modules/account]
Gegenseite: mercurial-server: access denied
Abbruch: Keine passende Antwort des entfernten hg!
   
   It should be fixed now.
  
  Please re-test as I had to change the configuration to allow write
  access to committers.
 
 hg nclone ssh://h...@hg.tryton.org/trytond/
 
 works now, push to be tested of course later.

Currently all ssh access broken again. 

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgpIzyFAszFBM.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] Freeze of repositories

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Freeze of repositories (Mon, 6 Apr 2015
  00:52:22 +0200):

 On 06 Apr 00:41, Mathias Behrle wrote:
  * Mathias Behrle:  Re: [tryton-dev] Freeze of repositories (Wed, 1 Apr
  2015 02:41:37 +0200):
  
   * Cédric Krier:  Re: [tryton-dev] Freeze of repositories (Wed, 1 Apr
   2015 00:45:46 +0200):
   
On 31 Mar 16:56, Cédric Krier wrote:
 On 31 Mar 15:47, Mathias Behrle wrote:
  Using most recent hgnested:
  
  $ hg nclone ssh://h...@hg.tryton.org/trytond 
  Zielverzeichnis: trytond
  [trytond]
  Sende alle Änderungen
  582 Dateien zum Übertragen, 8.58 MB an Daten
  8.58 MB in 33.8 Sekunden übertragen (260 KB/Sek)
  Aktualisiere auf Zweig default
  382 Dateien aktualisiert, 0 Dateien zusammengeführt, 0 Dateien
  entfernt, 0 Dateien ungelöst
  
  [trytond/trytond/modules/account]
  Gegenseite: mercurial-server: access denied
  Abbruch: Keine passende Antwort des entfernten hg!
 
 It should be fixed now.

Please re-test as I had to change the configuration to allow write
access to committers.
   
   hg nclone ssh://h...@hg.tryton.org/trytond/
   
   works now, push to be tested of course later.
  
  Currently all ssh access broken again. 
 
 The problem must be on your side.

Now working again.

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgpTBxWnACRpt.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] Freeze of repositories

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Freeze of repositories (Tue, 31 Mar 2015
  14:33:46 +0200):

 On 31 Mar 14:24, Mathias Behrle wrote:
  * Cédric Krier:  [tryton-dev] Freeze of repositories (Mon, 23 Mar 2015
19:19:36 +0100):
  
   There are some new modules to not forget: account_tax_rule_country,
   stock_lot_sled, account_payment_sepa_cfonb, account_deposit and
   sale_extra.
  
  Could you please link them in for hg nclone? It will be easier to download
  and no one will forget them.
 
 They are.

Ok, I used ssh to our local mirror;)

Could you please indicate, what is the correct ssh access at present, I am
unable to (n)clone with ssh at all.

I tried with

hg clone ssh://yang...@hg.tryton.org//home/hg/trytond Gegenseite: Abbruch: Es
gibt hier kein Mercurial-Archiv (.hg nicht gefunden)! Abbruch: Keine passende
Antwort des entfernten hg!

- trytond no more linked to /home/hg

as well as with

hg clone ssh://yang...@hg.tryton.org//var/lib/mercurial-server/repos/trytond
Zielverzeichnis: trytond Abbruch: Sperren des entfernten Projektarchivs
fehlgeschlagen

- locking of remote failing


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgprkhkqY3iMd.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] Freeze of repositories

[Mathias Behrle]

* Cédric Krier:  [tryton-dev] Freeze of repositories (Mon, 23 Mar 2015
  19:19:36 +0100):

 There are some new modules to not forget: account_tax_rule_country,
 stock_lot_sled, account_payment_sepa_cfonb, account_deposit and
 sale_extra.

Could you please link them in for hg nclone? It will be easier to download and
no one will forget them.

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgp0a4_xFwIkR.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] Freeze of repositories

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Freeze of repositories (Tue, 31 Mar 2015
  15:20:25 +0200):

 On 31 Mar 15:06, Mathias Behrle wrote:
  * Cédric Krier:  Re: [tryton-dev] Freeze of repositories (Tue, 31 Mar 2015
14:33:46 +0200):
  
   On 31 Mar 14:24, Mathias Behrle wrote:
* Cédric Krier:  [tryton-dev] Freeze of repositories (Mon, 23 Mar 2015
  19:19:36 +0100):

 There are some new modules to not forget: account_tax_rule_country,
 stock_lot_sled, account_payment_sepa_cfonb, account_deposit and
 sale_extra.

Could you please link them in for hg nclone? It will be easier to
download and no one will forget them.
   
   They are.
  
  Ok, I used ssh to our local mirror;)
  
  Could you please indicate, what is the correct ssh access at present, I am
  unable to (n)clone with ssh at all.
 
 https://groups.google.com/d/topic/tryton-dev/QSAovIeRPPA/discussion
 http://code.google.com/p/tryton/wiki/Mercurial

Using most recent hgnested:

$ hg nclone ssh://h...@hg.tryton.org/trytond 
Zielverzeichnis: trytond
[trytond]
Sende alle Änderungen
582 Dateien zum Übertragen, 8.58 MB an Daten
8.58 MB in 33.8 Sekunden übertragen (260 KB/Sek)
Aktualisiere auf Zweig default
382 Dateien aktualisiert, 0 Dateien zusammengeführt, 0 Dateien entfernt, 0
Dateien ungelöst

[trytond/trytond/modules/account]
Gegenseite: mercurial-server: access denied
Abbruch: Keine passende Antwort des entfernten hg!


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgpmuCLEdph2v.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] Freeze of repositories

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Freeze of repositories (Tue, 31 Mar 2015
  15:20:25 +0200):

 On 31 Mar 15:06, Mathias Behrle wrote:
  * Cédric Krier:  Re: [tryton-dev] Freeze of repositories (Tue, 31 Mar 2015
14:33:46 +0200):
  
   On 31 Mar 14:24, Mathias Behrle wrote:
* Cédric Krier:  [tryton-dev] Freeze of repositories (Mon, 23 Mar 2015
  19:19:36 +0100):

 There are some new modules to not forget: account_tax_rule_country,
 stock_lot_sled, account_payment_sepa_cfonb, account_deposit and
 sale_extra.

Could you please link them in for hg nclone? It will be easier to
download and no one will forget them.
   
   They are.
  
  Ok, I used ssh to our local mirror;)
  
  Could you please indicate, what is the correct ssh access at present, I am
  unable to (n)clone with ssh at all.
 
 https://groups.google.com/d/topic/tryton-dev/QSAovIeRPPA/discussion
 http://code.google.com/p/tryton/wiki/Mercurial

Thanks.

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgpASWnJUvWZk.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] Client translation

[Mathias Behrle]

* Cédric Krier:  [tryton-dev] Client translation (Sun, 22 Mar 2015 14:08:50
  +0100):

 Hi,
 
 I wrote a proposal to improve the client translation process:
 https://bugs.tryton.org/issue4664
 I would like to setup this workflow for the coming release.
 So please comment, especially the translators.

AFAIS this proposal concerns not mainly translators (it's not a big deal to
not commit .mo files), but generally users/developers running Tryton from
sources. The repository won't work any more out of the box when running in a
localization different from english.

The question is more:
- does the gain in repository size (currently about half a MB) outweigh the
  disadvantages of having to compile the mo files before usage and evtl. have
  requests fom users not being aware of the fact?

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgpZuIwiNUEug.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] Request testing of new sale_opportunity workflow

[Mathias Behrle]

* Albert Cervera i Areny:  Re: [tryton-dev] Request testing of new
  sale_opportunity workflow (Fri, 27 Feb 2015 19:04:36 +0100):

 2015-02-27 18:21 GMT+01:00 Cédric Krier cedric.kr...@b2ck.com:
  On 27 Feb 17:22, Albert Cervera i Areny wrote:
  2015-02-27 16:45 GMT+01:00 Cédric Krier cedric.kr...@b2ck.com:
   On 27 Feb 15:47, Albert Cervera i Areny wrote:
   2015-02-27 15:45 GMT+01:00 Albert Cervera i Areny alb...@nan-tic.com:
2015-02-27 13:00 GMT+01:00 Cédric Krier cedric.kr...@b2ck.com:
Hi,
   
I would like to push the issue3320 [1] before the 3.6 release.
As it is quite a big workflow change, I would like to have feedback
on it.
   
Though I did not test the patch:
   
- I like the general workflow and it is, in fact, what we're already
using in our installs
- I would consider making it possible to use the convert button
several times. So it is possible to create another sale instead of
creating a new one and using the origin or instead of duplicating the
existing sale. We did that change and renamed Convert to Create
sale. In fact, for me Convert is misleading as a conversion is when
you convert a lead into a paying customer [1].
  
   I think the convert is the correct term.
 
  Could you point to some place where the term Convert is used in the
  same sense that it is being used in Tryton? Everything I can find uses
  the term for getting paying customers or paid sales. Not converting a
  lead into a quotation which is the first step of the sale.
 
  I think it is a matter of usage. It could fit the general meaning or
  not. The user will decide when he does the convertion so he will decide
  the meaning. He could convert only when the sale is sure to be done or
  he could convert at a state where he is not sure at all.
  So I don't think it is wrong to call a button that convert an object
  into an other object convert.
 
 I see. Yet, maybe it is only me but when I think of converting one
 object into another it means that the former disappears. That's why we
 create an invoice, not convert the sale into an invoice.

Same feeling here. We also *create* purchases from purchase requests and so on.
 
 On the other hand, we have a button named  Convert to Opportunity
 which converts Lead into an Opportunity because the same object is
 changed from one state to another.

I would also leave the term 'Convert' to this specific functionality in
Lead/Opportunity Management.


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgpOfOlv_ROUY.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] mercurial-server and roundup

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] mercurial-server and roundup (Mon, 22 Dec
  2014 00:19:08 +0100):

 On 21 Dec 19:22, Cédric Krier wrote:
  But before using it, we have to consolidate the user names.
  It will be easier to change the login on roundup to match the mercurial
  user. Here is the list of the user that should change their roundup
  login:
  
  - albert-nan - albertca
  - oscaralvarez - oscar
  - rayanAyar - rayanayar
  - matb - yangoon

Done.


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgplTQNVo5SiD.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] contributions: approval rules

[Mathias Behrle]

* Pierre-Louis Bonicoli:  Re: [tryton-dev] contributions: approval
  rules (Tue, 16 Dec 2014 04:38:03 +0100):

 On 20/08/2014 12:50, Pierre-Louis Bonicoli wrote:
 [...]
  The rules - as explained by Cédric [1], are:
  
  Any core developer is allowed to push, core developers take
  responsibility. The core developers are: Cédric, nicoe, pokoli and albert.
  
  People allowed to push without being core developers are allowed to push
  small fixes without LGTM. Bigger fixes need approval (LGTM) of a core
  developer.
  
  For bigger fixes, in case of disagreement a consensus should be reached,
  at last the project leader takes a decision.
 [...]
  [1] French:
  http://www.tryton.org/~irclog/fr/2014-08-20.log.html#t2014-08-20%2011:35
 
 Hi,
 
 There have been many modifications since August :) There are fewer steps
 (some have been automated), a better documentation (quick start added)
 and fewer rules (no differences between core dev and committers).
 
 About the HowToContribute wiki page:
 - why is there a link to http://codereview.tryton.org/6451002/ ? It
 seems unrelated.

Indeed the link was wrong. I just corrected it.

 - what is the Vote results performed on 2010-07-05 ?

See [1][2].

Thanks for taking care,
Mathias



[1] thread.gmane.org/gmane.comp.python.tryton/1591/
[2] http://article.gmane.org/gmane.comp.python.tryton/1641


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgpq9gIKxZYaL.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] contributions: approval rules

[Mathias Behrle]

* Pierre-Louis Bonicoli:  Re: [tryton-dev] contributions: approval
  rules (Tue, 16 Dec 2014 12:54:02 +0100):

Hi Pierre-Louis,

 Thanks for your modifications :)
 
 In order to improve clarity, could I:
 - join the Must section with the paragraph starting with If the
 contributor has a significant amount of code (this time I will keep the
 link to the thread about the vote :)

IIUC then it is not the same. Those rules apply to each contribution, whether
you add yourself to COPYRIGHT or not.

 - move the Nice to have, but not required at the end of the Rules
 section ?

Basically the same as above.

Since those rules are preconditions for any contribution I would expose them
very clearly at the beginning of the chapter (as is the case). 

my 2¢


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgptnKvph9wwi.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] contributions: approval rules

[Mathias Behrle]

* Udo Spallek:  Re: [tryton-dev] contributions: approval rules (Tue, 16 Dec
  2014 13:06:20 +0100):

 As an old discussion I participated is *swimming up*, I would like to
 explain my opinion today.
 After the SCO-Linux controversies[3] I changed my opinion[4]
 in many of the proposals.

I am not really up-to-date with this subject, but AFAIS SCO was defeated on its
law suits? [A] And SCO attacked on the validty of the GPL itself, where we
can't do a lot?

  - The contributor name must be the real name of the natural person
  who submit the code
  - The contributor email must be a valid email address
  - The username of mercurial patch must be in the form:
  Name email
 
 Today, I would strongly vote *yes* for the above proposals.
 Because it makes the project stronger in case of copyright questions.
 In my country the copyright of a creation is fixed to the natural
 persons who act as a creators.
 IANAL, but AFAIK in Germany the copyright is not transferable to anyone
 else (§ 29 Abs. 1 UrhG).
 In other countries like USA it is different, the copyright is
 transferable even to legal person.
 
 I think it is good when the Tryton project is able to identify a
 natural or legal person as author.
 Additionally I find we need a sign-off process for contributors to the 
 developer-certificate-of-origin[5], as many other projects do[6].

For me the situation is still the same as of our first discussions on this
subject.

- We shouldn't try to require arrangements, that we cannot enforce.

or the other way round

- If we require something, then we must enforce it correctly.

AFAIS in [B] it is said:

  ... then you just add a line saying
   Signed-off-by: ...

There is nowhere said, that this commit has to be gpg signed. Perhaps this
document is not complete (and I currently don't have the time to investigate),
but this way you could just use any name. That's just snakeoil;) [C]

The only somewhat reliable process would be to require to sign commits etc.
with a key signed by at least (put in a number here) project members. I doubt
that this can be, what we want to simplify contribution.

So just today I even would be inclined to not vote for any of the
requirements in [D].

 [3]http://en.wikipedia.org/wiki/SCO%E2%80%93Linux_controversies
 [4]http://thread.gmane.org/gmane.comp.python.tryton/1591/
 [5]http://www.do-not-panic.com/2014/02/developer-certificate-of-origin.html
 [6]https://www.gnu.org/licenses/why-assign.en.html
 https://www.kernel.org/doc/Documentation/SubmittingPatches

[A]
http://www.zdnet.com/article/novell-defeats-sco-in-unix-copyright-case-3039288508/
[B] https://www.kernel.org/doc/Documentation/SubmittingPatches
[C] http://www.merriam-webster.com/dictionary/snakeoil
[D] http://thread.gmane.org/gmane.comp.python.tryton/1591/

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgpGGFFRIviWn.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] contributions: approval rules

[Mathias Behrle]

* Pierre-Louis Bonicoli:  Re: [tryton-dev] contributions: approval
  rules (Tue, 16 Dec 2014 16:41:13 +0100):

 Does the following seem ok to you (s/rules/contributions/ and 'rules'
 subtitle added) ?
 
 - Contributions
 - requirements
 - must
 - nice to have, but not required
 - rules

Perfect for me.


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgph1ThP0fLEw.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] Faster contribution

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Faster contribution (Wed, 19 Nov 2014
  15:24:40 +0100):

 On 19 Nov 14:59, Mathias Behrle wrote:
  * Cédric Krier:  Re: [tryton-dev] Faster contribution (Wed, 19 Nov 2014
12:44:15 +0100):
  
   On 19 Nov 12:12, Mathias Behrle wrote:
* Cédric Krier:  Re: [tryton-dev] Faster contribution (Wed, 19 Nov
2014 11:27:25 +0100):
- It should still be possible to track issues and reviews in the commit
message.
   
   review is appended to the patch.
   issue depends if the submitter add it or not.
  
  So this is dropped as a requirement?
 
 It will depend of the issue.
 If the contributor will only provide a patch for an issue core
 developers find it needs one, it will be requested as comment.
 
- It should be possible to use a specified name and email address for
the commit message.
   
   Such contributor will have to use their preferred email address to login
   in rietveld. And they will have to set their real name.
  
  I doubt that will work. Not everyone wants to register every address (and
  especially addresses for this usage) at Google.
 
 That's another topic. The move from appspot to self hosting is there
 since more than 3 years and nobody ever takes any steps, so we can guess
 it is not really an issue.

It seems to be an issue, even for the usage of appspot itself. If I understood
correctly, Sharoon stated at TUL, that it is impossible for him to participate
on reviews, because there are conflicts between mail adresses. Of course it
would be best, if he would jump into this discussion to explain exactly the
matter.
 
 https://bugs.tryton.org/issue2177

I think, that no one took it is rather a sign of limited resources than not
being it an issue. Which raises oviously the question: why shouldn't we use an
external infrastructure, where we get all this for free?

As I already stated at TUL, I am not a big fan of making global players to
monopolists by reinforcing them in getting dependent from them. Nevertheless I
would appreciate a lot a solution, that takes the best from the two worlds:

If we could get away by using github just as a frontend, from which we pipe all
requests to the project owned infrastructure
- we had a very comfortable interface for easy contributions
- we would be more known and better reachable, because github is just what it
  is: a huge place of code and coders
- we nevertheless would be masters of our infrastructure and such completely
  independet
- this would just be an additional way to get into contact with and
  contribute to the project doing no harm in keeping all current procedures
  alive
 
Additional open questions for me with the proposed setup:

- Until now I am missing the procedure, how the review gets into trunk.
   
   One core dev has to take it.
  
  That doesn't explain, how the procedure should work.
 
 A core dev will take a patch and push it.
 As contributor you don't have to care of any of this.

As long as this will be in the following way, this could save work for all of
us:

- Lets get an additional field for the commit message (or misuse the current
  description for it). The final commit message including bug and review tags
  should go into it.
- Core dev could integrate the patch with hg import directly.

which would save all this export and attaching to bugs work.
 
- It should at least exist an additional field for the mail address.
Since we are (still) tied to google for authentication, you don't want
necessarily take the google registered address for the commit message.
   
   Use a google account for your preferred email address. I think it is the
   best way to do it as this will ensure we will have a valid address.
  
  I think this could be another quite substantial barrier for contribution at
  all.
 
 Too bad for them. At some point, ...

I agree about 'at some point'. I doubt, this point is the same for you and
me...;)

 ...we must realize that people who are
 nitpicking to contribute, are losing but not the project. If you can fix
 an issue and you don't do it, it is bad for you not for us.

It is bad for all and misses the advantage of being OpenSource and getting
stronger by contribution.

  I found another point to add:
  
  - It should be able to work on a tree of repos (this being a feature of the
current setup and not being possible on github AFAIK). 
 
 Such cases are for big changes (so out of cusual contributor) and we
 already have a good workflow for that for the core developers.

Of course. But the subject is about 'Faster contribution', not only for casual
contributots.


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgpt8lYvxvquh.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] Faster contribution

[Mathias Behrle]

* Pierre-Louis Bonicoli:  Re: [tryton-dev] Faster contribution (Thu, 20 Nov
  2014 10:54:20 +0100):

 On 20/11/2014 10:37, Cédric Krier wrote:
  On 20 Nov 10:24, Pierre-Louis Bonicoli wrote:
  On 20/11/2014 01:42, Simon Klemenc wrote:
  The current contribution process seems very intransparent and it is
  not easy to see which party allowed for which change and who actually
  merged it.
 
  Could you please list the points that are missing/intransparent in the
  related documentation :
  https://code.google.com/p/tryton/wiki/HowtoContribute ?
 
  I would be happy to improve the documentation.
  
  By the way, Pilou, I think it will be good to have a TL;TR since you
  started to add a lot of details.
 
 You mean that a quick start is necessary ?

Just saw. that you did great work on this page, thanks for this!

What do you think about moving this page rather on top just below 'Organization
of this Project'? For me it is too hidden at the current place.

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgps7cjvC70jg.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] Faster contribution

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Faster contribution (Wed, 19 Nov 2014
  11:27:25 +0100):

 On 19 Nov 09:48, LAG Robin Baumgartner wrote:
  On 18.11.2014 22:39, Cédric Krier wrote:
   If we apply this patch the contribution guide could be reduced for
   simple fix to:
   
   $ hg clone http://hg.tryton.org/trytond
   $ cd trytond; vi …
   $ curl -o ~/.local/bin/upload.py
   http://codereview.tryton.org/static/upload.py $ python
   ~/.local/bin/upload.py
  
  I don't quite see the benefit for the contributor, that looks exactly
  like the current workflow for creating a code review.
 
 He doesn't need any more to:
 
 - commit the changeset
 - export the changeset into a patch
 - attach the patch to an issue
 
 After some talks with people complaining about the current workflow, it
 was this part that was the most difficult for them when doing a small
 contribution.

Perhaps this could be a step in the right direction, but I agree with Robin,
that this is still much too cumbersome for newcomers or random contributors.

The main feature from the easy contribution setup on github is, that the user
can just directly edit the file in question and then push the button. All other
stuff happens behind the scenes. 

I will try to specify here a list of requirements, that can serve as a layout
for a solution (being of more or less importance as a matter of course). I
would like them to be discussed and amended.

- The user should get the file presented ready for edition (currently he has
  to do a lot of steps, before he can edit).

- The user should see his/her changes immediately (currently the
  unexperienced user sees his beautified diff after upload).

- The user should be able to submit the changes in a simple way (by just pushing
  a button, evtl. running one command).

- It should still be possible to track issues and reviews in the commit message.

- It should be possible to use a specified name and email address for the
  commit message.


Additional open questions for me with the proposed setup:

- Until now I am missing the procedure, how the review gets into trunk.

- Until now there was a requirement to attach each review to a bug. How is this
  made with this setup?

- Who will be in charge of closing the review? Until now we have the guideline
  to close reviews after commit.

- Who will be in charge of doing the commit? Do we need a set of
  release/contribution managers?

- How shall it be differentiated, if a review will be submitted/pushed to trunk
  automatically or by the review owner himself?

- It should at least exist an additional field for the mail address. Since we
  are (still) tied to google for authentication, you don't want necessarily
  take the google registered address for the commit message.

Hope to get into a fruitful discussion, how we can improve the current
situation.

Cheers,
Mathias


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgptvpV18mr5J.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] Faster contribution

[Mathias Behrle]

* Sergi Almacellas Abellana:  Re: [tryton-dev] Faster contribution (Wed, 19
  Nov 2014 12:22:05 +0100):

 El 19/11/14 a les 12:12, Mathias Behrle ha escrit:

 Maybe this will work for other projects, but I don't understand how a 
 user could send a fix without testing it works and so having a local 
 copy of the files to test it.

I should have been more verbose, sorry for that.

There was a lengthy discussion at this TUL about moving the codebase evtl. to
github to ease those contribution steps. On github you can define automatic
testing by integration servers, so this is also done in an automatic way
transparent both to the contributor and to the owner of the target repos.

So this would already be an amendment to my points:

- There should be automated integration tests on proposed changes.


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


pgp7EQaXPN2JD.pgp
Description: Digitale Signatur von OpenPGP

Re: [tryton-dev] Faster contribution

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Faster contribution (Wed, 19 Nov 2014
  12:44:15 +0100):

 On 19 Nov 12:12, Mathias Behrle wrote:
  * Cédric Krier:  Re: [tryton-dev] Faster contribution (Wed, 19 Nov 2014
11:27:25 +0100):
  
   On 19 Nov 09:48, LAG Robin Baumgartner wrote:
On 18.11.2014 22:39, Cédric Krier wrote:
 If we apply this patch the contribution guide could be reduced for
 simple fix to:
 
 $ hg clone http://hg.tryton.org/trytond
 $ cd trytond; vi …
 $ curl -o ~/.local/bin/upload.py
 http://codereview.tryton.org/static/upload.py $ python
 ~/.local/bin/upload.py

I don't quite see the benefit for the contributor, that looks exactly
like the current workflow for creating a code review.
   
   He doesn't need any more to:
   
   - commit the changeset
   - export the changeset into a patch
   - attach the patch to an issue
   
   After some talks with people complaining about the current workflow, it
   was this part that was the most difficult for them when doing a small
   contribution.
  
  Perhaps this could be a step in the right direction, but I agree with Robin,
  that this is still much too cumbersome for newcomers or random contributors.
  
  The main feature from the easy contribution setup on github is, that the
  user can just directly edit the file in question and then push the button.
  All other stuff happens behind the scenes. 
  
  I will try to specify here a list of requirements, that can serve as a
  layout for a solution (being of more or less importance as a matter of
  course). I would like them to be discussed and amended.
  
  - The user should get the file presented ready for edition (currently he has
to do a lot of steps, before he can edit).
  
  - The user should see his/her changes immediately (currently the
unexperienced user sees his beautified diff after upload).
  
  - The user should be able to submit the changes in a simple way (by just
  pushing a button, evtl. running one command).
 
 I don't have any solution for this and I don't really think we should
 try. If such unexperienced user find a such easy thing to fix by just
 editing remotely the source file, this means it is nothing more than
 just a typo in a label. If this user find it, it is in the UI not in
 the source code. So having all this machinery will not help him to find
 where to make the change.
 
 And for a little bit more experienced user, I think making a clone of
 the repository is not so difficult.

I completely agree, that for bigger contributions the user will be more
experienced anyway. Nevertheless a fast and easy contribution process will help
those experienced users, too.
 
  - It should still be possible to track issues and reviews in the commit
  message.
 
 review is appended to the patch.
 issue depends if the submitter add it or not.

So this is dropped as a requirement?
 
  - It should be possible to use a specified name and email address for the
commit message.
 
 Such contributor will have to use their preferred email address to login
 in rietveld. And they will have to set their real name.

I doubt that will work. Not everyone wants to register every address (and
especially addresses for this usage) at Google.

  Additional open questions for me with the proposed setup:
  
  - Until now I am missing the procedure, how the review gets into trunk.
 
 One core dev has to take it.

That doesn't explain, how the procedure should work.
 
  - Until now there was a requirement to attach each review to a bug. How is
  this made with this setup?
 
 It is not required expect if a core dev think an issue need a bug
 report.
 
  - Who will be in charge of closing the review? Until now we have the
  guideline to close reviews after commit.
 
 The author could do it but we could add this right to the core dev and
 so when he import the patch he can close the review.
 But closing review is not really an important thing.

  - Who will be in charge of doing the commit? Do we need a set of
release/contribution managers?
 
 core dev.
 
  - How shall it be differentiated, if a review will be submitted/pushed to
  trunk automatically or by the review owner himself?
 
 core dev know each others so as they are the only one who can push a
 patch, they will not push a patch of another core dev.
 
  - It should at least exist an additional field for the mail address. Since
  we are (still) tied to google for authentication, you don't want necessarily
take the google registered address for the commit message.
 
 Use a google account for your preferred email address. I think it is the
 best way to do it as this will ensure we will have a valid address.

I think this could be another quite substantial barrier for contribution at all.


I found another point to add:

- It should be able to work on a tree of repos (this being a feature of the
  current setup and not being possible on github AFAIK

Re: [tryton-dev] trytond.conf

[Mathias Behrle]

* Axel Braun:  [tryton-dev] trytond.conf (Mon, 3 Nov 2014 11:52:50 -0800
  (PST)):

Hi Axel,

 I've read about the changes to the trytond.conf file
 Is the config file generated dynamically in between?
 
 (I noticed that the build failed due to the fact that there is no 
 etc/trytond.conf in source package of 3.4. In 3.2 there was 
 etc/trytond.conf.)

Feel free to use the commented conf file from the debian package [1][2],

Cheers,
Mathias

[1] https://code.google.com/p/tryton/wiki/InstallationOnDebian
[2]
https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=tryton/tryton-server.git;a=blob;f=debian/trytond.conf;h=fd28e1f6d398694b36535284b4797338c43fdce5;hb=HEAD


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] update/install module

[Mathias Behrle]

* Cédric Krier:  [tryton-dev] update/install module (Wed, 10 Sep 2014
  09:29:56 +0200):

 Hi,
 
 There is a side effect of the changeset [1] which is that the update and
 install arguments have indeed the same behavior.
 For example, if you run:
 
 trytond -d DB -u all
 
 this will install all the modules.
 This is because there was only at one places where there was a
 difference between both options and this difference is no more possible
 with the refactoring because it lays on global variables.
 
 I think the best way to fix that if to explicitly make them one options
 (for example keep -u) which will install or update the named module.
 Also we should remove the all special keyword because it doesn't help
 who wants to install all the module. So instead to update all the
 installed module, you should simply update ir (because all module must
 depend on it, otherwise they do nothing).
 For the record, I would like in the future merge both module ir and
 res into a single base module and move webdav as a normal module.
 
 Comments?

For option -u:
Why not making --all internally updating just 'ir' (later 'base') and keep that
way the behavior of the options across releases?

For option -i:
-i all is a useful option for developers and it should behave like -u all does
currently. 


 [1] http://hg.tryton.org/trytond/rev/01399128964f



-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Toward a working multi-company

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Toward a working multi-company (Mon, 8 Sep
  2014 10:05:28 +0200):

 On 24 Jul 11:08, Cédric Krier wrote:
  On 24 Jul 01:13, Cédric Krier wrote:
   On 24 Jul 00:53, Mathias Behrle wrote:
* Cédric Krier:  Re: [tryton-dev] Toward a working
multi-company (Wed, 23 Jul 2014 22:54:04 +0200):

 On 03 Jul 09:59, Cédric Krier wrote:
  Hi,
  
  I was requested to provide a plan for multi-company as I say in
  issue3974 [1].
  
  TL;DR: drop record rule, add domain on fields
 
 Here is
 
 - the issue: https://bugs.tryton.org/issue4080
 - the review: http://codereview.tryton.org/10461002/

Much appreciated! As we are at the point to make the decision for a
customer to use a multi-company in favor of a multi-database setup I
want to ask, if we can supposedly rely on this feature in the future.
If there are uncertainties about the persistance of this feature,
please let us know.
   
   For me, it is the way to go but still waiting feedback from others.
   But about feature as you can see it is more about removing rules than
   adding new stuff. The new code is mainly adding missing domain (should
   be there in any cases) or missing company field and in few places it
   just hard code the previous rule because anything else don't make sense
   (ex: stock quantity)
  
  Also this review needs more testing especially for new cases, like
  creating a sale for an other company then the current user one.
 
 For me, the state of the patch is good for inclusion so I plan to push
 it by the end of the week of I get no bad feedbacks.

The test of this patch is on my TODO, but I didn't manage so far to find the
time. I will try to do it this week.

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] RFC: account_tax_rule_country

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] RFC: account_tax_rule_country (Thu, 4 Sep
  2014 09:36:58 +0200):

 On 04 Sep 09:02, Udo Spallek wrote:
  Thu, 28 Aug 2014 10:49:59 +0200
  Cédric Krier cedric.kr...@b2ck.com:
  I created a module to add from/to country on the matching mechanism of
  tax rule. It is more a POC about how tax rule should be customized.
  Comments are welcomed.
  https://bugs.tryton.org/issue4139
  
  it would be good to have additionally a coarse grained structuring, 
  for supra-regional groups like, trade agreement zones or free trade
  agreements ...
  These groups are collections of countries or other groups.
  Every membering country has an entry date and could have an exit
  date to the group.
  
  E.g. countries in the European Union use special tax rules for
  business with other membering countries.
  Instead of defining and maintaining with every single country a single
  tax rule, it would be good to define one tax rule for one group.
 
 The main difficulty is that often your local country is handled
 differently than others one of the same zone.

So the own country shouldn't be added to such a group. But indeed such groups
should be very useful.


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] RFC: account_tax_rule_country

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] RFC: account_tax_rule_country (Thu, 4 Sep
  2014 11:49:13 +0200):

 On 04 Sep 11:43, Mathias Behrle wrote:
  * Cédric Krier:  Re: [tryton-dev] RFC: account_tax_rule_country (Thu, 4
  Sep 2014 09:36:58 +0200):
  
   On 04 Sep 09:02, Udo Spallek wrote:
Thu, 28 Aug 2014 10:49:59 +0200
Cédric Krier cedric.kr...@b2ck.com:
I created a module to add from/to country on the matching mechanism of
tax rule. It is more a POC about how tax rule should be customized.
Comments are welcomed.
https://bugs.tryton.org/issue4139

it would be good to have additionally a coarse grained structuring, 
for supra-regional groups like, trade agreement zones or free trade
agreements ...
These groups are collections of countries or other groups.
Every membering country has an entry date and could have an exit
date to the group.

E.g. countries in the European Union use special tax rules for
business with other membering countries.
Instead of defining and maintaining with every single country a single
tax rule, it would be good to define one tax rule for one group.
   
   The main difficulty is that often your local country is handled
   differently than others one of the same zone.
  
  So the own country shouldn't be added to such a group.
 
 But such design will make them not shareable.

Indeed. But having the possibility to use them is already better than nothing
at all. 

Random thoughts:

- We could share the records for such a group, but disable the own country on
  configuration (e.g. when creating the account chart). Looks hackish, groups
  could be used for different purposes.

- If we had an excludes field on the tax rule, we could define: members of the
  group, but not the excluded ones. Still hackish, but a little less.

Other ideas?


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Toward a working multi-company

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Toward a working multi-company (Wed, 23 Jul
  2014 22:54:04 +0200):

 On 03 Jul 09:59, Cédric Krier wrote:
  Hi,
  
  I was requested to provide a plan for multi-company as I say in
  issue3974 [1].
  
  TL;DR: drop record rule, add domain on fields
 
 Here is
 
 - the issue: https://bugs.tryton.org/issue4080
 - the review: http://codereview.tryton.org/10461002/

Much appreciated! As we are at the point to make the decision for a customer to
use a multi-company in favor of a multi-database setup I want to ask, if we can
supposedly rely on this feature in the future. If there are uncertainties about
the persistance of this feature, please let us know.

BTW the current multi-company support wrt. to shared models would work quite
well for this use case.


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] What should be the search on: 1..42

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] What should be the search on: 1..42 (Thu,
  12 Jun 2014 12:11:13 +0200):

 On 12 Jun 11:59, Mathias Behrle wrote:
  * Cédric Krier:  [tryton-dev] What should be the search on: 1..42 (Thu, 12
Jun 2014 11:06:34 +0200):
  
   Hi,
   
   We get some astonishement with the current behavior of the client with
   the range search syntax.
   
   Currently: `Field: 1..42` will become
   
   `[('field', '=', 1), ('field', '', 42)]`
   
   But it seems people expect:
   
   `[('field', '=', 1), ('field', '=', 42)]`
   
   One point about the current behavior is that you can slide the range by
   the length and it will not contain any duplication.
   
   So what do you think?
  
  From a user perspective the search imitates 'from 1 to 42', which includes
  42 in the selection.
 
 What is the original of 'from 1 to 42'?

Sorry, I don't understand the question.



-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] What should be the search on: 1..42

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] What should be the search on: 1..42 (Thu,
  12 Jun 2014 12:38:45 +0200):

 On 12 Jun 12:29, Mathias Behrle wrote:
  * Cédric Krier:  Re: [tryton-dev] What should be the search on:
  1..42 (Thu, 12 Jun 2014 12:11:13 +0200):
  
   On 12 Jun 11:59, Mathias Behrle wrote:
* Cédric Krier:  [tryton-dev] What should be the search on:
1..42 (Thu, 12 Jun 2014 11:06:34 +0200):

 Hi,
 
 We get some astonishement with the current behavior of the client with
 the range search syntax.
 
 Currently: `Field: 1..42` will become
 
 `[('field', '=', 1), ('field', '', 42)]`
 
 But it seems people expect:
 
 `[('field', '=', 1), ('field', '=', 42)]`
 
 One point about the current behavior is that you can slide the range
 by the length and it will not contain any duplication.
 
 So what do you think?

From a user perspective the search imitates 'from 1 to 42', which
includes 42 in the selection.
   
   What is the original of 'from 1 to 42'?
  
  Sorry, I don't understand the question.
 
 You say that the search imitates something which has a specific
 behavior. But where does it come from?

As Albert says:
When you talk to the user about a range, he answers: 'Ah yes, you mean from ...
to ...'.

And he will expect to see both boundary values included.


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] RFC: Use DateEdit from gnomeui

[Mathias Behrle]

* Cédric Krier:  [tryton-dev] RFC: Use DateEdit from gnomeui (Wed, 28 May
  2014 11:42:55 +0200):

 Hi,
 
 I created a patch [1] to replace the current DateEdit widget (inherited
 from TinyERP ha! OpenERP oops! Odoo) by one that follow the gnomeui.
 The current one is not the most userfriendly widget and it is not
 possible to enter a datetime using the mouse only.
 
 So you can test this prototype by running:
 
 python tryton/common/dateentry.py
 
 Comments are welcome.

It is hard for me to reproduce the motivations leading to that change. If it is
only for the cause, that the code of the widget is coming from a certain party,
I think this is hardly sufficient.

Let me explain:

Looking at the DateTime widget of version 2.2, we had a very comfortable
solution, that allowed also the entry of distinct minutes [1]. This solution
was from the user experience much superior to both the current state and the
new proposal.

Furthermore it seems, that the new widget will be more unfreindly for user
input:

- no more simple overwriting of a date possible, the chars to replace have to
  be deleted first
- no more simple input of the date without separator possible, separator must
  always be put in explicitely
- loosing the possibility to handle date input with +2d, -1w etc., a feature
  widely used by the users we know
- missing input validation (this probably due to POC state?)

Until now for me there is less we gain and more we loose with this widget.

[1] http://picpaste.com/datetime22-4k8qFdMS.png

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] RFC: client multi-notebook

[Mathias Behrle]

* Cédric Krier:  [tryton-dev] RFC: client multi-notebook (Wed, 28 May 2014
  11:59:45 +0200):

 Hi,
 
 I created a patch [1] that is a POC for a support of multi-notebook in the
 client. The idea is to follow the well-known behavior of browser with
 the SHIFT-click to open in a new window (which could be seen as a new
 notebook). So the client in case of SHIFT-click on a window action will
 create on the fly a new notebook of the most right. For now it shows
 only the 2 last notebooks at the same time (it is a NOTEBOOKS variable
 in main.py).
 I think this functionnality could be useful on large screen and when
 people want to compare records etc.
 
 Comments are welcome.

Absolutely nice feature.

As long as it is possible, that there can be hidden notebooks, I agree, that
there should be some information about that. Or probably better just limit the
number of open notebooks to a maximum of 2.

Tryton 2 monitors wide is just awesome...;) [1]

[1] http://picpaste.com/tryton2monitors-gxxpxAyn.png

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Test and dependecies

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Test and dependecies (Wed, 14 May 2014
  16:06:49 +0200):

 On 14 May 11:26, Mathias Behrle wrote:
  The second issue is, that sooner or later there *can* be the case, where a
  dependent module will add constraints breaking a test in the former module.
  Just not implementing necessary constraints, because they could break tests,
  can not be the goal.
 
 But such module will be just like account_stock_continental, a bad
 designed module.

So you mean basically, that adding a requires on a field of a supered
model is generally bad design?


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Test and dependecies

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Test and dependecies (Thu, 15 May 2014
  13:06:29 +0200):

 On 15 May 12:50, Mathias Behrle wrote:
  * Cédric Krier:  Re: [tryton-dev] Test and dependecies (Wed, 14 May 2014
16:06:49 +0200):
  
   On 14 May 11:26, Mathias Behrle wrote:
The second issue is, that sooner or later there *can* be the case,
where a dependent module will add constraints breaking a test in the
former module. Just not implementing necessary constraints, because
they could break tests, can not be the goal.
   
   But such module will be just like account_stock_continental, a bad
   designed module.
  
  So you mean basically, that adding a requires on a field of a supered
  model is generally bad design?
 
 Yes constraints are always bad.

I agree, that they should be avoided as much as possible, but the consequence
of your statement is to not use constraints at all. Is this correct?


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Test and dependecies

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Test and dependecies (Tue, 13 May 2014
  14:58:58 +0200):

 On 13 May 13:48, Mathias Behrle wrote:
   There is a problem with the new tests added to purchase (see
   http://tests.tryton.org/~test/postgresql.html).
   The test fails when running with account_stock_continental because this
   module add a constraint on product account stock.
   
   I wrote a patch: http://codereview.tryton.org/13311003
   but I'm not sure it is the right way to go.
   An other possibility would be to remove the required of
   account_stock_continental for bad design reason (there are still the
   *_used which raise error message).
   
   What do you think?
  
  What about testing in tests/test_purchase.py, if module
  account_stock_continental is installed and just in case provide the needed
  values?
 
 Basicly it is similar solution to my patch but as explained in previous
 email, 

Agreed. Similar, but not the same, as my proposal would have the benefit to be
more clearly documented.

 I think the issue is in the design of account_stock_continental.

So we have to differentiate between several problems.

The first one seems to be the design of account_stock_continental. If this
issue can be solved by correcting the design, it is of course the way to go.

The second issue is, that sooner or later there *can* be the case, where a
dependent module will add constraints breaking a test in the former module.
Just not implementing necessary constraints, because they could break tests,
can not be the goal.

For me, in a closed suite like the upstream modules are, tests could be made
aware of other modules.

Remains the problem depicted by Sergi:

 So if i develop module XX (which is not part of core modules) and adds 
 another required field on product, I will need to add test in 
 test_purchase.py (which is a core module) in order to get the test pass, 
 so core modules must know about all the existing modules? IMHO this is 
 not the right way.

I think, a possible solution could then be to include the test of the core
module into the custom module, adapt it, and not to run the the test in the
core module. Perhaps I am jumping too short here?


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Test and dependecies

[Mathias Behrle]

* Cédric Krier:  [tryton-dev] Test and dependecies (Mon, 12 May 2014 17:28:35
  +0200):

 There is a problem with the new tests added to purchase (see
 http://tests.tryton.org/~test/postgresql.html).
 The test fails when running with account_stock_continental because this
 module add a constraint on product account stock.
 
 I wrote a patch: http://codereview.tryton.org/13311003
 but I'm not sure it is the right way to go.
 An other possibility would be to remove the required of
 account_stock_continental for bad design reason (there are still the
 *_used which raise error message).
 
 What do you think?

What about testing in tests/test_purchase.py, if module
account_stock_continental is installed and just in case provide the needed
values?

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] production_route module

[Mathias Behrle]

* Albert Cervera i Areny:  Re: [tryton-dev] production_route module (Fri, 2
  May 2014 19:16:34 +0200):

 2014-05-02 15:08 GMT+02:00 Cédric Krier cedric.kr...@b2ck.com:
  On 15 Mar 19:04, Albert Cervera i Areny wrote:
  For more information about the initial blueprint take a look at this
  thread [4].
 
  I have a big problem with this proposal, it is the missing of a
  blueprint.
  I can not think or evaluate base on such large code base especially for
  a so large feature. Code contains too much noize to be able to get a
  clear picture.
  So I'm missing a document which describes the goals/features and also
  the design proposal of the implementation. A good place for it is the
  wiki because we could collaborate on it.
 
 Here's the wiki page. Tried to explain what we're trying to solve in
 this first step as well as the approaches and some design decisions we
 took so far:
 
 https://code.google.com/p/tryton/wiki/ProductionProcesses

Thanks for the blueprint. Before diving into deeper modelling I would like to
return first to the basics. I think, if the basics are agreed upon, the rest
will be solved much more easily. So here are my 2¢:

From a very generic point of view a production needs:

a) resources
b) a sequence of steps
c) the result

a) can be of kind
- human
- machine
- material
- instruction (what to do, how to do it)
- ...?

b) will mostly require a time dimension, some production step
could even be to only assign time for e.g. drying time.


Currently the resource of materials is covered by the production module, all
others are necessary features to represent a full production process.


I would like to put the sequence of steps (b) in the center of the conception,
because a step can afford a subset of resources. So ideally I would see it like:

Production (as the container of one whole process)
- consisting of several Production Steps (or subprocesses)
   A Production Step should be able to describe all needs and expectations
   of this single step.

My impression of the discussion so far is, that if we have Production Steps
with all kinds of resources attached we should meet all requirements.

Do we agree on that?



-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Re: production_route module

[Mathias Behrle]

* Albert Cervera i Areny:  [tryton-dev] Re: production_route module (Sun, 20
  Apr 2014 10:35:51 +0200):

[...]

 I've just updated the patch to link route with the product but I'm not
 yet satisfied with it. The reason is I think route and bom cannot be
 disconnected if we want them to be useful to describe the real
 production process. Even if the link is between bom and route (instead
 of route and bom to product) current models are not able to describe
 the complete recipe, if we take the cooking analogy.
 
 In cooking we do have the bom as we currently have it in Tryton (that
 is, the ingredients) but there is no route without products. That is,
 you cannot say you need to spend 10 minutes mixing and 15 minutes
 in the frying pan. You must say which ingredients of the bom must be
 mixed and which ones must be put in the frying pan. Of course, there
 may be some exceptions where all the components of the bom are used
 for all operations but that is only for the simpler cases.
 
 Let me put a simplified real example of the steps necessary for
 producing paint colors:
 
 - Put the container on the scale
 - Add the following components in the following order:
   - P1 50Kg
   - P2 4Kg
   - P3 2Kg
   - P4 500g
   - P5 300g
   - P6 100g
 - Check total weight
 - Add the following components while mixing:
   - P7 50Kg
   - P8 2Kg
 - Mix during 10 minutes
 - Add the following components while mixing:
   - P1 4Kg
 - Mix during 10 minutes
 - Add the following components while mixing:
   - P10 1Kg
 - Mix during 15 minutes
 
 For me, it would be possible to describe that easily by simply adding
 a new model to current production module that contains several
 production.bom model. Here I rename existing production.bom into
 production.process.step because I think it would be more
 appropriate:
 
 class Process:
 __name__ = 'production.process'
 steps = fields.One2Many('production.process.step')
 inputs = fields.Function(fields.One2Many('production.bom.input'))
 outputs = fields.Function(fields.One2Many('production.bom.output'))
 
 class Step:
 __name__= 'production.process.step'
 name = fields.Char('name')
 description = fields.Char('Description')
 inputs = fields.One2Many('production.bom.input')
 outputs = fields.One2Many('production.bom.output')
 
 Another module could add operation-related information to
 'production.process.step':
 
 class Step:
 __name__ = 'production.process.step'
 operations = fields.One2Many('production.route.operation')

I like very much the idea of putting the process as the central part of
production [1].
 
 It is also possible to add the Process concept in another module
 instead of current production one but I think it is simpler this way.
 For example, production module adds a m2o from production to bom which
 should be replaced by a link to process if it is created in a separate
 module.
 
 Before taking that road I'd like to have some feedback. Anybody sees a
 need of route without bom link? 

I could imagine the route model more generic, not just production orientated.
If route is just a sequence of steps, it could be used also for workflows
where no products are involved (e.g. a service consisting of doing several
defined steps). Then no bom would be necessary for such a route. But that's
probably overkill instead of creating a separate model for such use cases.

 If so, how would you achieve a
 reasonable user interface when the link is necessary? Pros and cons
 for keeping it in/out of main production module?
 

[1] http://commons.wikimedia.org/wiki/File:Production_process_model.png

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Duplicate translations

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Duplicate translations (Sun, 6 Apr 2014
  23:55:13 +0200):

 On 04 Apr 18:48, Cédric Krier wrote:
  On 04 Apr 18:36, Cédric Krier wrote:
   Dear translators,
   
   I just discover that the changeset [1] generates duplicate translations
   for the error message defined in translation.xml.
   You have to manually delete the old one from your database and po file.
   If you don't this can generate a traceback when the server will try to
   raise those error message. Be careful to keep the new error message.
   
   [1] http://hg.tryton.org/trytond/rev/dbbbe6cae2bb
  
  To search from the client, you can just type this filter:
  
  Type: Error Module: =ir Field Name: domain_validation_record
  
  Of course change `domain_validation_record` by each translation names in
  the changeset [1]
 
 The es_CO translation is already affected.

Just for fellow translators to give examples of the changes to be done. You can
search for these error strings and delete the translation from the client.

[1]
http://codereview.tryton.org/4881002/diff2/1:20001/trytond/ir/locale/fr_FR.po
[2]
https://codereview.appspot.com/84560043/diff2/60001:80001/trytond/trytond/ir/locale/de_DE.po?column_width=80

Cheers

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Bugtracker access right

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Bugtracker access right (Sun, 6 Apr 2014
  11:52:46 +0200):

 On 06 Apr 10:02, Cédric Krier wrote:
  On 06 Apr 01:39, Mathias Behrle wrote:
   * Cédric Krier:  Re: [tryton-dev] Bugtracker access right (Sun, 6 Apr
   2014 01:15:12 +0200):
   
On 06 Apr 00:54, Mathias Behrle wrote:
 * Cédric Krier:  [tryton-dev] Bugtracker access right (Sat, 5 Apr
 2014 23:52:40 +0200):
 
  Hi,
  
  For now, every user had the right to remove any msg or file from the
  bugtracker. I find it very annoying as we already got (spam)bot that
  does it (needed to retire the corrupted user) and also users who
  wrongly remove message preventing to have a clear picture of the
  history of an issue.
  So I write a patch that only allows Admin users to remove:
  http://codereview.tryton.org/4931002/
  The patch is already temporary applied on the instance for testing
  purpose.
  In case if someone really wants with a valid reason to remove a
  message then he could ask to one of the Admin.
 
 Hiding a msg to replace it with a new one is the only way to correct
 messages.

This is a false idea because you don't replace it as everyone will any
way receive the message by email. It is much better to have a second
message explaining the correction than trying badly to hide the error.
   
   Of course it is possible to replace a message silently as long as there
   is no one on the nosy list. And then still not *everyone* will get the
   messages, but only nosy list. And for later reference it is still cleaner
   to only have a corrected message.
  
  No it is not. It is rewritting history.

No, it is not. It is unlinking a msg from an issue. And linking a better
suitable msg to the issue. A tracker is not a VCS and history is preserved
completely and transparently (take a look at the bottom of the issue).

  It is specially because people
  has this behavior that I want to remove the button.

First it was the spambot, now you changed your mind?

 It should only be
  used to remove inappropriate message and this should be exceptional.
  For example, bugs.python.org, bugs.gentoo.org (and as far as I see
  bugs.debian.org) don't have such button.
 
 This is also the configuration of roundup tracker.

Hiding of messages AFAIK is a default feature of roundup. 

Please don't get in over-control.



-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Bugtracker access right

[Mathias Behrle]

* Cédric Krier:  [tryton-dev] Bugtracker access right (Sat, 5 Apr 2014
  23:52:40 +0200):

 Hi,
 
 For now, every user had the right to remove any msg or file from the
 bugtracker. I find it very annoying as we already got (spam)bot that
 does it (needed to retire the corrupted user) and also users who wrongly
 remove message preventing to have a clear picture of the history of an
 issue.
 So I write a patch that only allows Admin users to remove:
 http://codereview.tryton.org/4931002/
 The patch is already temporary applied on the instance for testing
 purpose.
 In case if someone really wants with a valid reason to remove a message
 then he could ask to one of the Admin.

Hiding a msg to replace it with a new one is the only way to correct messages.

I would prefer to restrict the deletion to just own messages of the user. This
would keep the feature, but eliminate 'foreign deletions'.


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Bugtracker access right

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Bugtracker access right (Sun, 6 Apr 2014
  01:15:12 +0200):

 On 06 Apr 00:54, Mathias Behrle wrote:
  * Cédric Krier:  [tryton-dev] Bugtracker access right (Sat, 5 Apr 2014
23:52:40 +0200):
  
   Hi,
   
   For now, every user had the right to remove any msg or file from the
   bugtracker. I find it very annoying as we already got (spam)bot that
   does it (needed to retire the corrupted user) and also users who wrongly
   remove message preventing to have a clear picture of the history of an
   issue.
   So I write a patch that only allows Admin users to remove:
   http://codereview.tryton.org/4931002/
   The patch is already temporary applied on the instance for testing
   purpose.
   In case if someone really wants with a valid reason to remove a message
   then he could ask to one of the Admin.
  
  Hiding a msg to replace it with a new one is the only way to correct
  messages.
 
 This is a false idea because you don't replace it as everyone will any
 way receive the message by email. It is much better to have a second
 message explaining the correction than trying badly to hide the error.

Of course it is possible to replace a message silently as long as there is no
one on the nosy list. And then still not *everyone* will get the messages, but
only nosy list. And for later reference it is still cleaner to only have a
corrected message.


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Git[hub] mirror of Tryton repositories

[Mathias Behrle]

* Sharoon Thomas:  [tryton-dev] Git[hub] mirror of Tryton repositories (Sun,
  19 May 2013 16:33:50 +0530):

Hi Sharoon,

 We have setup a github mirror [1] for the tryton repositories.
 
 The mirror is updated once everyday between 01:00 UTC and 02:00 UTC.

This is just a little feedback, that we enjoyed very much the service of
keeping this mirror up-to-date. Since the new branching of the upstream repos
the mirror is no more updated. Could you please share, if you plan to resume
the update?

Thanks a lot,
Mathias
 

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Side effect of named branch

[Mathias Behrle]

* Cédric Krier:  [tryton-dev] Side effect of named branch (Sat, 8 Mar 2014
  01:22:33 +0100):

 Hi,
 
 I just strated «grafting» changeset to series and I discover a side
 effect of the named branch.
 The hgroundup hook updates the old issue with branch backport
 information [1] which is great but it also makes roundup to set the
 status to chatting. I don't feel to go back to all «grafted» issue to
 reset the status to resolved. So I propose that the hgroundup hook set
 always the status of the issue to resolved. This means that when working
 on an issue which will require many changesets over a long period, the
 status should be reset to in-progress manually because it will be set to
 resolved on each commit.
 
 What do you think?
 
 [1] https://bugs.tryton.org/issue3688

That's the reason, why we adapted the script to use xml-rpc. Like this it is
possible to keep/reset the state of the issue. Find a review at [1].

[1] http://codereview.tryton.org/4201002

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Scenario fail on MySQL

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Scenario fail on MySQL (Wed, 19 Feb 2014
  00:50:21 +0100):

 On 06 Feb 01:00, Cédric Krier wrote:
  Hi,
  
  With the recent drop of Python 2.6, I re-wrote the scenario to get
  better error message like this [1]. It allowed to find some misbehavior
  between PostgreSQL and SQLite.
  The problem is that MySQL again doesn't play well [2] because we have to
  put constraint on the DECIMAL column [3] and MySQL doesn't succeed to
  return Decimal with the same precision as we send.
  I thought about using Decimal.normalize() [4] to get standard format to
  test in doctest but I don't like too much because it will hide other
  issues (like the one fixed with this change for SQLite).
  
  So I'm calling for ideas…
 
 So I'm thinking about skipping all doctest with MySQL backend because in
 some way, it is just the unittest that really should check the internal
 behavior of the code and scenario are just there for the big picture
 workflow (and so they should not depend on the backend).

As long as MySQL is a supported database, all tests should be run for this
backend. If it can not comply, it is better to show the results instead of
hiding them. There could also be other failures than the current Decimal
precision.

I for my share have less concerns to introduce backend specific doctests,
clearly commenting the behavior of MySQL and not hiding issues for other
backends.


  [1] http://hg.tryton.org/modules/account/rev/3f5a5a854341#l4.1
  [2] http://tests.tryton.org/~test/mysql.html
  [3]
  http://hg.tryton.org/trytond/file/631515bc8c82/trytond/model/fields/numeric.py#l31
  [4] http://docs.python.org/2/library/decimal.html#decimal.Decimal.normalize
 



-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Scenario fail on MySQL

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Scenario fail on MySQL (Wed, 19 Feb 2014
  12:19:50 +0100):

 On 19 Feb 12:11, Mathias Behrle wrote:
  * Cédric Krier:  Re: [tryton-dev] Scenario fail on MySQL (Wed, 19 Feb 2014
00:50:21 +0100):
  
   On 06 Feb 01:00, Cédric Krier wrote:
Hi,

With the recent drop of Python 2.6, I re-wrote the scenario to get
better error message like this [1]. It allowed to find some misbehavior
between PostgreSQL and SQLite.
The problem is that MySQL again doesn't play well [2] because we have to
put constraint on the DECIMAL column [3] and MySQL doesn't succeed to
return Decimal with the same precision as we send.
I thought about using Decimal.normalize() [4] to get standard format to
test in doctest but I don't like too much because it will hide other
issues (like the one fixed with this change for SQLite).

So I'm calling for ideas…
   
   So I'm thinking about skipping all doctest with MySQL backend because in
   some way, it is just the unittest that really should check the internal
   behavior of the code and scenario are just there for the big picture
   workflow (and so they should not depend on the backend).
  
  As long as MySQL is a supported database, all tests should be run for this
  backend. If it can not comply, it is better to show the results instead of
  hiding them. There could also be other failures than the current Decimal
  precision.
  
  I for my share have less concerns to introduce backend specific doctests,
  clearly commenting the behavior of MySQL and not hiding issues for other
  backends.
 
 What the point to run 8 hours of scenario that all fails for sure.

They are not all failing and you still can see, why some are failing.

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Add history to taxes

[Mathias Behrle]

* Mathias Behrle:  Re: [tryton-dev] Add history to taxes (Sun, 19 Jan 2014
  12:34:37 +0100):

 * Cédric Krier:  [tryton-dev] Add history to taxes (Sat, 18 Jan 2014
 16:18:39 +0100):
 
  What does it mean? How does it work?  What is it trying to solve?
 
 Detailed answer will follow later (after packaging of the bug fix releases). I
 will try to present some use cases. 

First of all, I am not an accountant, but will do my best to shed some light on
the situation in Germany. If someone knows better or different, please make
your voice heard.

As an example coming to my mind we had the VAT tax change 2005 in Germany with
the following situation:

until 31.12.2005: [1]

code description   value
(input taxes)
1575 Abziehbare Vorsteuer 16%  16%
1576 Abziehbare Vorsteuer 15%  15%
(output taxes)
1775 Umsatzsteuer 16%  16%
1776 empty


from 01.01.2006: [2]

code description   value
(input taxes)
1575 Abziehbare Vorsteuer 16%  16%
1576 Abziehbare Vorsteuer 19%  19%
(output taxes)
1775 Umsatzsteuer 16%  16%
1776 Umsatzsteuer 19%  19%


Please don't discuss with me, if you find such layout useful. It is provided by
Datev, the de-facto standard in Germany, to which we have to comply
(practically all german accountants are using their software).

- They overwrote an old account (1576) with a new one.
- For customer payments after 1.1.2006 refering to invoices before you had to
  use the old tax (1775)
- For customer payments after 1.1.2006 refering to invoices after you had to
  use the new tax (1776)
- For supplier payments after 1.1.2006 refering to invoices before you had to
  use the old tax (1575)
- For customer payments after 1.1.2006 refering to invoices after you had to
  use the new tax (1576) (which was used before for tax 15%)

Our needs are:

- Get for payments the correct accounts per fiscal year
- Get for deferrals the correct follower in the following fiscal
  year/predecessor in the previous year
- Be as flexible as possible with respect to the date ranges (IIRC a VAT change
  in Spain happened under year).
- Preserve for correct reporting all old accounts, taxes and tax codes, related
  in a timely manner.



[1] http://www.smixx.de/ra/Links_S-T/DATEV-Standardkontenrahmen.pdf
[2]
http://hg.tryton.org/modules/account_de_skr03/file/95f78c08e033/account_de.xml#l3437
[3]
http://hg.tryton.org/modules/account_de_skr03/file/95f78c08e033/account_de.xml#l6237


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Add history to taxes

[Mathias Behrle]

* Cédric Krier:  [tryton-dev] Add history to taxes (Sat, 18 Jan 2014 16:18:39
  +0100):

 What does it mean? How does it work?  What is it trying to solve?

Detailed answer will follow later (after packaging of the bug fix releases). I
will try to present some use cases. 

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Re: [issue3600] Add history to taxes

[Mathias Behrle]

* Albert Cervera i Areny:  Re: [tryton-dev] Re: [issue3600] Add history to
  taxes (Sun, 19 Jan 2014 00:05:46 +0100):

 We had a chart of accounts change on 2008 in Spain but still I prefer
 current approach without linking accounts to fiscal years. Didn't
 deactivating the old accounts work for you?

No, deactivating accounts isn't an option I would even like to consider.
They are perfectly valid, for a given date range. 

Think of doing the closing of a fiscal year in year n+1 (perhaps in a 13
period), but the accounts of the previous year n are no more available. In the
same way the accounts of the following year must be available in advance, you
need them at latest at 00:00 of the beginning of the fiscalyear.

I am perfectly aware of the downsides of tying accounts to fiscalyear, but we
finally got no other clean solution than to use some kind of timeline on
accounts. If there is a more flexible approach it is more than welcome. We
should collect some use cases (s other mail) to evaluate, if those needs are
generic enough to fit into account, if an extension module account_timeline
would be appropriate at least for use in EU countries, or if we just have to
stick to our own solution, because we have still to comply to specific needs
for Germany.

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] What is your internal workflow

[Mathias Behrle]

* Albert Cervera i Areny:  Re: [tryton-dev] What is your internal
  workflow (Fri, 10 Jan 2014 15:44:49 +0100):

 2014/1/9 Mathias Behrle mbeh...@m9s.biz:
  * Jean C:  [tryton-dev] What is your internal workflow (Wed, 8 Jan 2014
09:34:59 +0100):
 
  We are currently using mercurial with bitbucket. We want to try on the
  pull-request workflow, but we understood it may be difficult regarding the
  way mercurial manages branches.
 
  One of your primary decisions will be, if you want to maintain versions
  older than current. If you want to do so with mercurial, the layout from
  tryton.org seems still the way to go (while I have to admit, that it is
  looong ago, that I looked at the branching capabilities of mercurial).
  Publishing on the usual hosters will be tedious.
  If you don't intend to do maintenance of different versions, you can choose
  the same way as Zikzakmedia and NaN·tic and just publish the current branch.
 
 Note that we created 3.0 branches for all repositories, and will add
 3.2 when it is released, etc.

Good news. Looking forward to your experience with series maintenance on 'real'
mercurial branches.
I suppose, you meant that you currently work on default = 2.9/3.0 and that you
will branch as soon as 3.2 is out (apart from account_es*, which have 2.8, like
Sergi said)?

I agree, that the choice of VCS is mostly a matter of habit. 
Out of interest I made a short test on branching and transplanting with
mercurial. As long as you intend to work with persistent branches, there seems
no problem. What I am really going to miss for my everyday work is the removal
of a (feature/hotfix/whatever) branch. It seems in mercurial you only can close
them and they will be in history forever. Perhaps I am not using the right
workflow, because I am accustomed to git.
Not a point in publishing series branches, but important for me in daily
development.


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Re: tryton: Adding *.po and *.pot of translation files to package.

[Mathias Behrle]

* Axel Braun:  [tryton-dev] Re: tryton: Adding *.po and *.pot of translation
  files to package. (Sun, 24 Nov 2013 04:20:31 -0800 (PST)):

 Am Mittwoch, 2. Oktober 2013 12:36:59 UTC+2 schrieb Code Review - New 
 issues: yangoon:
 
  (No description) 
 
  URL:
  http://codereview.tryton.org/1116002/http://www.google.com/url?q=http%3A%2F%2Fcodereview.tryton.org%2F1116002%2Fsa=Dsntz=1usg=AFQjCNEUQb_g8dzj-UYv2FyyYj6BdSekzQ
   
 
 
 I'm wondering what the sense of this is. *po and pot files should be 
 compiled to *mo files.  
 There is no need to add them to a final package. If needed, they should go 
 to a -devel package

We are using GPL(3).

https://bugs.tryton.org/issue3397




-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Proposal to move sao from sandbox to main repo

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Proposal to move sao from sandbox to main
  repo (Sat, 16 Nov 2013 16:08:15 +0100):

 On 16/11/13 13:47 +0100, Mathias Behrle wrote:
  * Cédric Krier:  [tryton-dev] Proposal to move sao from sandbox to main
repo (Sat, 16 Nov 2013 02:09:36 +0100):
  
   What do you think about making sao a little more official?
  
  I think, you should clarify which purpose the sandbox branch should serve.
 
 It is not a branch.

Tryton versions are not branched in the VCS, but on filesystem level. So call
the sandbox ??? like you want.
 
  There were recently several discussions where to host repositories.
 
 I don't see what you are refering.

http://www.tryton.org/~irclog/2013-11-14.log.html
 
  sao until
  now is the only repos getting the privilege to be hosted on tryton.org
  while it is initially developed and not yet released. 
 
 First, I don't see where is the privilege.

Help me to make better understable: it is the only repos hosted on tryton.org
being not yet released.

 Second, yes it is the first large project started by the core
 developpers.
 
  So better make some rules
  - who can get a repos there
 
 Nobody.

Does this mean:
Nobody apart from 'core developers'?
 
  - which criteria must be fulfilled to include a repos there
 
 I realy don't want to start a bureaucratic management. Let's deal it
 when it happens.

When what happens?
 
  and then make the sandbox public, if it is an official play ground of the
  project.
 
 What is not public?

The official character of the sandbox. Why else would you ask: Proposal to
move sao from sandbox to main repo: What do you think about making sao a little
more official?
 
  Or don't use it at all, if it is not needed (and then make rules for
  inclusion in main ;) ).
 
 There can not be rules.

There are already rules:

Leaders also must review patches before submitting them to B2CK for inclusion
in the main repository.
(http://code.google.com/p/tryton/wiki/ProjectOrganization#Organization)

The clearer the rules are, the better for the project. Comprehensible and
reproducible behavior will help to minimize frustration.

Just my 1¢,
Mathias

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Tryton 3.0: change to localization files

[Mathias Behrle]

* Axel Braun:  [tryton-dev] Tryton 3.0: change to localization files (Thu, 24
  Oct 2013 04:53:02 -0700 (PDT)):

 Hi,
 
 I started building the new release, and found out that the build scripts 
 stop with an error, resp. with a couple of files that were not there in the 
 2.8 release:
 
 [   75s]  Installed (but unpackaged) file(s) found:
 [   75s]/usr/share/locale/cs_CZ/LC_MESSAGES/tryton.po
 [   75s]/usr/share/locale/de_DE/LC_MESSAGES/tryton.po
 [   75s]/usr/share/locale/es_AR/LC_MESSAGES/tryton.po
 [   75s]/usr/share/locale/es_CO/LC_MESSAGES/tryton.po
 [   75s]/usr/share/locale/es_ES/LC_MESSAGES/tryton.po
 [   75s]/usr/share/locale/fr_FR/LC_MESSAGES/tryton.po
 [   75s]/usr/share/locale/ru_RU/LC_MESSAGES/tryton.po
 [   75s]/usr/share/locale/sl_SI/LC_MESSAGES/tryton.po
 [   75s]/usr/share/locale/tryton.pot
 
 
 Was there a change in the setup of the localization files?

Yes, see here

http://hg.tryton.org/tryton/rev/d3c09019f48a


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Unoconv stability

[Mathias Behrle]

* Vincent (CloudSuite):  [tryton-dev] Unoconv stability (Mon, 21 Oct 2013
  01:18:40 -0700 (PDT)):

 Hi,
 
 I am curious to your experience with unoconv (a module part of OpenOffice / 
 LibreOffice and
 used in Tryton to convert ODT files to PDF or other formats).
 
 We use LibreOffice 3.6, IIRC mainly because OpenOffice had Java 
 dependencies that we did not want to install. 
 We are also still on Tryton 2.4.
 
 On one of our production servers we have a lot of stability issues. 
 Unoconv crashes several times a month and all we can do is kill the running 
 soffice.bin and unoconv processes
 and restart the unoconv deamon. And then hope it will not happen again 
 soon. When it does, the customer has to kill the client process to restart.
 
 On our development server it's quite stable. But on this machine unoconv is 
 idle most of the time. On the
 production server it is much more busy, as I think about all of the 
 customer's documents are in PDF format.
 
 Tryton 2.4 originally uses pipes, but we had even more stability problems 
 with this. So I changed it to sockets:
 unoconv = socket,name=trytond;urp;StarOffice.ComponentContext
 
 And this is how I start the deamon:
  /opt/libreoffice3.6/program/soffice --display :0.0 --norestore --headless 
 --accept=socket,host=localhost,port=2002

unoconv indeed is not threadsafe. Repeating the process as Ralf says
solves/workarounds for us this problem.

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Translations status

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Translations status (Sat, 19 Oct 2013
  18:39:02 +0200):

 On 19/10/13 17:21 +0200, Cédric Krier wrote:
 On 19/10/13 11:46 +0200, Mathias Behrle wrote:
  * Cédric Krier:  [tryton-dev] Translations status (Sat, 19 Oct 2013
  08:28:10 +0200):
  
  Hi Cédric,
  
  For the module account_de_skr03, there are German translation but the
  module is already in German. So I will remove the file because it just
  slow the installation of the module and like that it will be follow the
  same rules as the other account chart modules.
  
  I don't agree. The german translation was necessary, because at its ceation
  time you wanted english descriptions for the root account. Now it is too
  late to change this. So don't delete the translation, but please file an
  issue against it for the next release,
 
 All others chart module doesn't have it so I don't see why having an
 exception for this one. I will just set the translated name for roots.

I see neither review nor commit for this late fix. What is the status of this
subject?
 
 Here the issue to fix for future: https://bugs.tryton.org/issue3432

I think, it would be worth to discuss, if there could be need for the
translation of chart accounts. Until now we we prefer to show itmes in the
interface in the language of the user. And until now it was easy to add a
translation if considered necessary or useful.
I imagine some international chart of accounts, that until now was in the
translation process and in future will be no more. How do you want to get the
translations for such an account? It will be much more complicate than to leave
it as is: to the translators.

Anyway this is a very late change not caused by any severe impact to the
application and should be evaluated for the next version.


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Translations status

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Translations status (Sun, 20 Oct 2013
  14:17:56 +0200):

 On 20/10/13 12:31 +0200, Mathias Behrle wrote:
 I imagine some international chart of accounts, that until now was in the
 translation process and in future will be no more.
 
 It is purly hypotetical, please provide an example where someone has to
 provide an identical chart of account in different languages.

There is a really simple example: the Minimal account chart. There could be
others of general interest as well.
 
 How do you want to get the
 translations for such an account? It will be much more complicate than to
 leave it as is: to the translators.
 
 No because there will be no translation at all.

Ok, so you will remove translations for the mnimal account chart as well? Fair
enough.
 

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Translations status

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Translations status (Sun, 20 Oct 2013
  16:14:20 +0200):

 On 20/10/13 15:36 +0200, Mathias Behrle wrote:
 * Cédric Krier:  Re: [tryton-dev] Translations status (Sun, 20 Oct 2013
   14:17:56 +0200):
 
  On 20/10/13 12:31 +0200, Mathias Behrle wrote:
  I imagine some international chart of accounts, that until now was in the
  translation process and in future will be no more.
  
  It is purly hypotetical, please provide an example where someone has to
  provide an identical chart of account in different languages.
 
 There is a really simple example: the Minimal account chart. There could be
 others of general interest as well.
 
 I will not call the minimal account char a real example.

Why?
 
  How do you want to get the
  translations for such an account? It will be much more complicate than to
  leave it as is: to the translators.
  
  No because there will be no translation at all.
 
 Ok, so you will remove translations for the mnimal account chart as well?
 Fair enough.
 
 I guess we should remove also the minimal account chart.

Why?


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Translations status

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Translations status (Sun, 20 Oct 2013
  18:40:46 +0200):

 On 20/10/13 18:17 +0200, Albert Cervera i Areny wrote:
 2013/10/20 Cédric Krier cedric.kr...@b2ck.com:
  On 20/10/13 15:36 +0200, Mathias Behrle wrote:
  * Cédric Krier:  Re: [tryton-dev] Translations status (Sun, 20 Oct 2013
14:17:56 +0200):
 
  On 20/10/13 12:31 +0200, Mathias Behrle wrote:
  I imagine some international chart of accounts, that until now was in
  the translation process and in future will be no more.
 
  It is purly hypotetical, please provide an example where someone has to
  provide an identical chart of account in different languages.
 
  There is a really simple example: the Minimal account chart. There could
  be others of general interest as well.
 
  I will not call the minimal account char a real example.
 
  How do you want to get the
  translations for such an account? It will be much more complicate than
  to leave it as is: to the translators.
 
  No because there will be no translation at all.
 
  Ok, so you will remove translations for the mnimal account chart as well?
  Fair enough.
 
  I guess we should remove also the minimal account chart.
 
 I think the minimal account chart is useful for companies who do not
 want to manage accounting but want to make invoices. We could move it
 to another module, though.

+1

As long es invoicing is in module *account*-invoice, there has to be an easy
way to do invoicing with minimal accounting.
 

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Translations status

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Translations status (Sun, 20 Oct 2013
  21:06:25 +0200):

 On 20/10/13 20:50 +0200, Mathias Behrle wrote:
  As long es invoicing is in module *account*-invoice, there has to be an easy
  way to do invoicing with minimal accounting.
 
 Please explain what is an easy way to do invoicing.

I think Albert pointed this out sufficiently.

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Translations status

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Translations status (Sun, 20 Oct 2013
  14:17:56 +0200):

 On 20/10/13 12:31 +0200, Mathias Behrle wrote:
  * Cédric Krier:  Re: [tryton-dev] Translations status (Sat, 19 Oct 2013
18:39:02 +0200):
  
   On 19/10/13 17:21 +0200, Cédric Krier wrote:
   On 19/10/13 11:46 +0200, Mathias Behrle wrote:
* Cédric Krier:  [tryton-dev] Translations status (Sat, 19 Oct 2013
08:28:10 +0200):

Hi Cédric,

For the module account_de_skr03, there are German translation but the
module is already in German. So I will remove the file because it just
slow the installation of the module and like that it will be follow
the same rules as the other account chart modules.

I don't agree. The german translation was necessary, because at its
ceation time you wanted english descriptions for the root account. Now
it is too late to change this. So don't delete the translation, but
please file an issue against it for the next release,
   
   All others chart module doesn't have it so I don't see why having an
   exception for this one. I will just set the translated name for roots.
  
  I see neither review nor commit for this late fix. What is the status of
  this subject?
 
 It is trivial change, it doesn't deserve a codereview as it just about
 copying string from one place to an other. I will commit it today.

You didn't manage to copy the translation correctly. 

http://hg.tryton.org/modules/account_de_skr03/rev/44e9528b215c

Please fix this.


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Translations status

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Translations status (Sun, 20 Oct 2013
  23:33:40 +0200):

 On 20/10/13 23:08 +0200, Mathias Behrle wrote:
  * Cédric Krier:  Re: [tryton-dev] Translations status (Sun, 20 Oct 2013
14:17:56 +0200):
  
   On 20/10/13 12:31 +0200, Mathias Behrle wrote:
* Cédric Krier:  Re: [tryton-dev] Translations status (Sat, 19 Oct
2013 18:39:02 +0200):

 On 19/10/13 17:21 +0200, Cédric Krier wrote:
 On 19/10/13 11:46 +0200, Mathias Behrle wrote:
  * Cédric Krier:  [tryton-dev] Translations status (Sat, 19 Oct 2013
  08:28:10 +0200):
  
  Hi Cédric,
  
  For the module account_de_skr03, there are German translation but
  the module is already in German. So I will remove the file
  because it just slow the installation of the module and like that
  it will be follow the same rules as the other account chart
  modules.
  
  I don't agree. The german translation was necessary, because at its
  ceation time you wanted english descriptions for the root account.
  Now it is too late to change this. So don't delete the
  translation, but please file an issue against it for the next
  release,
 
 All others chart module doesn't have it so I don't see why having an
 exception for this one. I will just set the translated name for
 roots.

I see neither review nor commit for this late fix. What is the status of
this subject?
   
   It is trivial change, it doesn't deserve a codereview as it just about
   copying string from one place to an other. I will commit it today.
  
  You didn't manage to copy the translation correctly. 
  
  http://hg.tryton.org/modules/account_de_skr03/rev/44e9528b215c
  
  Please fix this.
 
 I don't see any error, I used vim to do copy/paste.

http://hg.tryton.org/modules/account_de_skr03/rev/44e9528b215c#l1.8
vs
http://hg.tryton.org/modules/account_de_skr03/rev/44e9528b215c#l2.5244
etc.
?

This isn't copy/paste and believe me: 'Germany' is not a German word.

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Translations status

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Translations status (Mon, 21 Oct 2013
  00:04:29 +0200):

 On 20/10/13 23:42 +0200, Mathias Behrle wrote:
  * Cédric Krier:  Re: [tryton-dev] Translations status (Sun, 20 Oct 2013
23:33:40 +0200):
You didn't manage to copy the translation correctly. 

http://hg.tryton.org/modules/account_de_skr03/rev/44e9528b215c

Please fix this.
   
   I don't see any error, I used vim to do copy/paste.
  
  http://hg.tryton.org/modules/account_de_skr03/rev/44e9528b215c#l1.8
  vs
  http://hg.tryton.org/modules/account_de_skr03/rev/44e9528b215c#l2.5244
  etc.
  ?
  
  This isn't copy/paste and believe me: 'Germany' is not a German word.
 
 Re-use the same scheme as other module, it is fair to show at least that
 to non-native speaker.

- The non-native speaker in your perception always speaks English
- The only word, if at all, he understands will be a country name
- Users will rather be deranged by such a strange entry in their native language

So this new 'guideline' is rather annoyance than convenience.

But for me now EOT.

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Translations status

[Mathias Behrle]

* Cédric Krier:  [tryton-dev] Translations status (Sat, 19 Oct 2013 08:28:10
  +0200):

Hi Cédric,

 For the module account_de_skr03, there are German translation but the
 module is already in German. So I will remove the file because it just
 slow the installation of the module and like that it will be follow the
 same rules as the other account chart modules.

I don't agree. The german translation was necessary, because at its ceation
time you wanted english descriptions for the root account. Now it is too late
to change this. So don't delete the translation, but please file an issue
against it for the next release,


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] tip 2.9 tryton: translation for de_DE

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] tip 2.9 tryton: translation for de_DE (Sat,
  12 Oct 2013 18:06:25 +0200):

 On 12/10/13 15:53 -, Code Review - New issues: yangoon wrote:
 (No description)
 
 URL: http://codereview.tryton.org/1137002/
 
 
 Please try to use the standardized prefix for review:
 
 repository name: …
 
 and for non trunk:
 
 repository name x.y: …

Seems not very applicable for nested reviews, but anyway...;)

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] hg: applying additional development while one is under review

[Mathias Behrle]

* Axel Braun:  [tryton-dev] hg: applying additional development while one is
  under review (Wed, 9 Oct 2013 02:06:30 -0700 (PDT)):

 Gents, 
 
 I need another help from you experts.
 While there is one change under review [1] I thing of adding more 
 translation. How do I manage to have this not impacting the first review, 

One review per feature. Translation is different from adding content. So please
open a separate review for translation stuff.

If I understand correctly you are volunteering to translate the website to
German? So be very welcome and please add yourself to
http://code.google.com/p/tryton/wiki/ProjectOrganization

Cheers,
Mathias


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] www.tryton.org: message to commit

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] www.tryton.org: message to commit (Thu, 3
  Oct 2013 10:21:34 +0200):

 On 03/10/13 09:06 +0200, Raimon Esteve wrote:
 I check download page from tryton.org and Linux section. Gentoo is a
 link to wiki page.
 
 Yes it is just a very simple page (the simplest) to explain how to do.
 It is a page similar to the one for debian http://debian.tryton.org/ Of
 course, it could/should be migrated to the website.
 
 A solution we are agree togheter is all linux distributions available
 in wiki page, add in download page; same as Gentoo
 
 on openSUSE
 on FreeBSD
 on Debian
 on Mandriva
 on Ubuntu
 on Fedora / Redhat
 on ForesightLinux
 on Slackware
 on Gentoo
 
 Almost all those pages are invalid/out of date/depracated. I was against
 such pages since day one and I think time proof I was right about my
 concern. For me the best solution is to remove all of them.

This is exactly the reason, why I personally don't care too much on those
pages. Because tomorrow they could be removed by you. So what is first: hen or
egg?



-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] www.tryton.org: message to commit

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] www.tryton.org: message to commit (Thu, 3
  Oct 2013 11:25:12 +0200):

 On 03/10/13 11:14 +0200, Raimon Esteve wrote:
 2013/10/3 Cédric Krier cedric.kr...@b2ck.com:
  Or you can do it.
 
 I upload CentOS 6.4 last month:
 
 http://code.google.com/p/tryton/wiki/InstallationOnFedora
 
 Please read carefully what I say. I'm not talking about adding more
 crappy stuff but put documentation in trytond/doc.

Give the community places, where it can work without being subject to
codereview etc. This in most cases of communizy driven projects is the wiki.
So leave it to the community.
Also installation hints could be subject to change while a release is out, not
to speak from documentation in old versions, which could just be wrong.

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] www.tryton.org: message to commit

[Mathias Behrle]

* Guillem Barba Domingo:  Re: [tryton-dev] www.tryton.org: message to
  commit (Thu, 3 Oct 2013 08:56:11 +0200):

 El 02/10/2013 20:23, Cédric Krier cedric.kr...@b2ck.com va escriure:

 On 02/10/13 19:50 +0200, Guillem Barba Domingo wrote:
  El 02/10/2013 16:05, Cédric Krier cedric.kr...@b2ck.com va escriure:
 
  On 02/10/13 06:46 -0700, Axel Braun wrote:
  
  
   Am Dienstag, 1. Oktober 2013 18:39:08 UTC+2 schrieb Cédric Krier:
  
   
URL: http://codereview.tryton.org/1110002/
   
  
   My concern is that it is a personal package and not an official
  openSUSE
   (if I understand correctly).  I would prefer (as I don't have any
   knowledge in openSUSE package) that we link only packages managed
 by
  the
   official workflow of the distribution.
  
   The build service offers users the ability to build packages for
  various
   platforms (Fedora, Red Hat, Cent OS, Ubuntu, Debian,..) from a
 single
   source. openSUSE as distribution bases completely on packages from
 the
   build service.
 
  We are not really concern, packages already exist for Fedora (and I
  guess derivates), Ubuntu and Debian
 
  I think it's good to have packages of Tryton, specially it they are
 updated.
  The webpage could have two lists of packages: officials and personals,
 and
  each one with the list of available versions.

 Personals packages are against all the rules of good practice.
 Moreover, *I don't want to manage such volatile list*.
 
 You don't need. Other people from the community, like Axel with this parch,
 will maage it.
 
  Cedk, you talk about the official workflow of distribution, but
 sometimes
  it's bad.

 Not bad but doesn't match your need. So it is this just mean that the
 distribution is not for you.
 
 Or it's perfect to me for the 95% of cases and I accept manage some
 exceptions out of the official way of distribution.
 
 Debian (and their children) have tools to manage different package
 repositories, event to manage priorities if the same package is in more
 thab one repository... So it supports personal/third party repositories
 (what I want to say is that it isn't out of the official way of
 distribution).
  For example, in Debian the packages are for a very old version of
  Tryton, so Debian and Ubuntu users will prefere a PPA with the latests
  stable versions.
  It is a very common situation for many products.

 Everyone is free but we don't have the ability to evaluate the quality
 of packages. So we delegate to the distributions.

I agree. There is a big difference between packages backed by the distribution
and packages from third parties. In the first case you trust the distribution,
in the second case it is up to the user to decide about the quality resp. trust
of the individual distributor.

 Or you can delegate to other members of Tryton's community, or community
 can decide to have this list with a disclaimer about thw non-proved quality.
 
  In summary, I think that more packages (and all of them listed in
 Tryton's
  website) and more explicit information (officials/personal) is better
 for
  users.

 No, more is not often better.
 Having such structure will make things much more complicate for the
 visitor.
 
 Maybe. In this case I think that these packages are very valuable for.the
 newbie (who could try the latest stable version easier than installing
 python packages, what some newbies have problems).

It is not only for newbies. Running productive environments you are much better
when using the package management of the distribution.



-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Submitting change via mercurial

[Mathias Behrle]

* Axel Braun:  Re: [tryton-dev] Submitting change via mercurial (Mon, 30 Sep
  2013 07:21:03 -0700 (PDT)):

 - First you need push access to tryton.org 
   As translator for Germany you should get it for this repository. 

 
 How can I verify this?

Ask the maintainer. Or simply try.
 
 - If you are not yet experienced with mercurial, it would probably be 
 better to 
   push to a codereview first. There you and others can control, if the 
 commit 
   will be ok. 

 
 Fine. Is this the Rietveld mentioned on 
 http://code.google.com/p/tryton/wiki/HowtoContribute ? OK, will try...

Yes. 

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Submitting change via mercurial

[Mathias Behrle]

* coogorsail...@gmail.com:  [tryton-dev] Submitting change via
  mercurial (Fri, 27 Sep 2013 01:46:13 -0700 (PDT)):

 I tried (first time use of mercurial...) to submit a change to the Tryton 
 website using the way described here: 
 
 http://code.google.com/p/tryton/wiki/HowtoContribute#How_to_submit_your_patches/contributions
 
 So, I used the hg export with the created patch, but find that it did not 
 show up for http://hg.tryton.org/www.tryton.org/
 What did I do wrong?

Several points to observe:

- First you need push access to tryton.org
  As translator for Germany you should get it for this repository.
- If you are not yet experienced with mercurial, it would probably be better to
  push to a codereview first. There you and others can control, if the commit
  will be ok.
- Finally, if you got a LGTM on the review, go ahead and do a 'hg push' (after
  preferably having done 'hg pull -u' to update to latest tip.)

HTH


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Fw: [tryton-commit] changeset in trytond: Fix crash in login with incorrect password...

[Mathias Behrle]

* Cédric Krier:  [tryton-dev] Fw: [tryton-commit] changeset in trytond: Fix
  crash in login with incorrect password... (Fri, 30 Aug 2013 11:34:54 +0200):


 This fix affect 2.8 but I don't see how to backport it on 2.8 because in
 some way, it changes the API (which is against the rules).
 But on the other hands, the API is broken in 2.8.

As long as an issue doesn't cause serious damage in a stable release, I
wouldn't backport API changes.

 Any ideas?

If you feel, that you want to offer a version with API breakage, you could do
so by creating a separate branch like
http://hg.tryton.org/proposed-updates/2.8/.
But I doubt that it will justify the time and effort.

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] python-sql

[Mathias Behrle]

* Nicolas Évrard:  Re: [tryton-dev] python-sql (Thu, 29 Aug 2013 07:32:03
  +0200):

 * Mathias Behrle  [2013-08-28 23:41 +0200]: 
* Cédric Krier:  Re: [tryton-dev] python-sql (Wed, 28 Aug 2013 22:20:40
 
 It is different from sqlalchemy in that
 - it is not based on declared tables
 - it is not database dependent
 - it allows to manipulate the queries

 I don't think it is good to explain a library by comparison with an
 other one.

This will be needed as explanation, which will be the advantage and
usfulness of this library, compared to packages (like sqlalchemy)
already in Debian. This question will arise almost for sure...

But it could be phrased positively:

It is database independent, doesn't require the declaration of tables
and allows to manipulate the generated queries.
 
 I find it's better to write it that way because SQLAlchemy can
 manipulate queries and is also database independent.
 
 You could also say that python-sql relies only on the python standard
 library, some users may find this information useful.

Ok.
 
 Also, in 'Suggest:', I would put database connectors because without
 them python-sql is almost useless.

Wouldn't this then be worth being mentioned in README, if not as extra_requires
in setup.py?

BTW:
http://code.google.com/p/python-sql/issues/detail?id=9

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] python-sql

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] python-sql (Wed, 28 Aug 2013 18:56:56
  +0200):

 On 04/08/13 21:00 +0200, Cédric Krier wrote:
 On 04/08/13 14:26 +0200, Mathias Behrle wrote:
  I reserved python-sql
  
  http://pypi.python.org/pypi/python-sql/
  
  Is it really reserved? I just get Not Found () with this URL.
  Are there any plans for the upload to pypi?
 
 On the first release.
 
 First release of python-sql is out:
 https://pypi.python.org/pypi/python-sql/0.1

Ok. Will then start the ITP for Debian.

Could you please confirm as description:


python-sql is a library to write SQL queries in a pythonic way.

It is different from sqlalchemy in that
- it is not based on declared tables
- it is not database dependent
- it allows to manipulate the queries

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] python-sql

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] python-sql (Wed, 28 Aug 2013 22:20:40
  +0200):

 On 28/08/13 20:55 +0200, Mathias Behrle wrote:
 * Cédric Krier:  Re: [tryton-dev] python-sql (Wed, 28 Aug 2013 18:56:56
   +0200):
 
  On 04/08/13 21:00 +0200, Cédric Krier wrote:
  On 04/08/13 14:26 +0200, Mathias Behrle wrote:
  I reserved python-sql
  
  http://pypi.python.org/pypi/python-sql/
  
  Is it really reserved? I just get Not Found () with this URL.
  Are there any plans for the upload to pypi?
  
  On the first release.
  
  First release of python-sql is out:
  https://pypi.python.org/pypi/python-sql/0.1
 
 Ok. Will then start the ITP for Debian.
 
 Could you please confirm as description:
 
 
 python-sql is a library to write SQL queries in a pythonic way.
 
 Ok.

This one-liner is a little bit short to give an overview of the abilities of
the package.
 
 It is different from sqlalchemy in that
 - it is not based on declared tables
 - it is not database dependent
 - it allows to manipulate the queries
 
 I don't think it is good to explain a library by comparison with an
 other one.

This will be needed as explanation, which will be the advantage and usfulness of
this library, compared to packages (like sqlalchemy) already in Debian. This
question will arise almost for sure...

But it could be phrased positively:

It is database independent, doesn't require the declaration of tables and
allows to manipulate the generated queries.

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Poll about new instance method on Uom

[Mathias Behrle]

* Cédric Krier:  [tryton-dev] Poll about new instance method on Uom (Mon, 15
  Jul 2013 00:20:17 +0200):

 Hi,
 
 I would like to submit this poll for this change:
 
 http://codereview.tryton.org/969002/#msg9
 
 
 kg.convert(1000, gr) == 1
 
 gr.convert(1000, kg) == 1
 
 
 Which one is more logical/easy/right?

For me both are not very intuitive. If any of the above, then
 gr.convert(1000, kg) == 1

I would prefer something like 

uomconvert(units, from_uom, to_uom)


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Git[hub] mirror of Tryton repositories

[Mathias Behrle]

* Sharoon Thomas:  Re: [tryton-dev] Git[hub] mirror of Tryton
  repositories (Wed, 22 May 2013 22:31:31 +0530):

 On Sun 19 May 20 16:54, Mathias Behrle wrote:
 
 Are you planing to add also tryton and proteus?
 
 
 Thanks for the feedback. I have added tryton [1], proteus [2] and sao
 [3] to the list of repositories.
 
 They should be fully mirrored by tomorrow.
 
 [1] https://github.com/tryton/tryton
 [2] https://github.com/tryton/proteus
 [3] https://github.com/tryton/sao

Thanks a lot.

There are some small inconsistencies:

1)
HEAD in tryton is set to 1.4 instead of develop

2)
trytond top branch is still master instead of develop.

Cheers

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] wiki: New proposal for payment (issue 923002)

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] wiki: New proposal for payment (issue
  923002) (Fri, 7 Jun 2013 19:22:51 +0200):

 On 07/06/13 15:16 +, cedric.kr...@b2ck.com wrote:
 Please review this at http://codereview.tryton.org/923002/
 
 Affected files:
   M PaymentOrder.wiki
 
 I think this is a more flexible and simple design for payment.
 Especially because it deals with a one to one relation between
 accounting lines and payment instead of grouping lines.
 Also it takes care of the succes or not of the payment, and in some way
 it will allow to have a kind of forecast about liquidity in the future.
 
 I think I sum up all the comments, please tell me if not.
 

Commented on the review.

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Adding a sequence to periods

[Mathias Behrle]

* Albert Cervera i Areny:  Re: [tryton-dev] Adding a sequence to
  periods (Sat, 8 Jun 2013 10:22:15 +0200):

 This is weird.  
 
 This is Spain ;-)

Don't know if this is only Spain. I think, this will be or become EU.
At least it is very common behavior to have those extra periods in Germany, too.


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Git[hub] mirror of Tryton repositories

[Mathias Behrle]

* Sharoon Thomas:  [tryton-dev] Git[hub] mirror of Tryton repositories (Sun,
  19 May 2013 16:33:50 +0530):

 We have setup a github mirror [1] for the tryton repositories.

Nice.

 The mirror is updated once everyday between 01:00 UTC and 02:00 UTC.
 
 The mirror uses the branching capability of Git [2] to keep the
 different versions of the code (tryton's repository hosting has
 different repositories for different versions). For example to checkout
 to the 2.6 version of sale module you could do:
 
 $ git clone g...@github.com:tryton/sale.git

JFTR: Needs ssh key added to own account. Otherwise use https://...

Facility to clone them all:

for package in `wget -q http://downloads.tryton.org/2.8/modules.txt -O -`; do
  git clone g...@github.com:tryton/$package.git
done

Are you planing to add also tryton and proteus?

Regards,
Mathias


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Un-assigned Tryton issue tracker requests

[Mathias Behrle]

* Tryton issue tracker:  [tryton-dev] Un-assigned Tryton issue tracker
  requests (Fri,  3 May 2013 08:00:26 +0200 (CEST)):

Could  the initiator of this daily unsolicited mails on tryton-dev please stop?

This could be made instead a configurable option on the tracker for those who
want to get this mail. And fix the double MIME header.

Thanks,
Mathias

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Un-assigned Tryton issue tracker requests

[Mathias Behrle]

* Cédric Krier:  Re: [tryton-dev] Un-assigned Tryton issue tracker
  requests (Fri, 3 May 2013 13:01:17 +0200):

 On 03/05/13 12:33 +0200, Mathias Behrle wrote:
  * Tryton issue tracker:  [tryton-dev] Un-assigned Tryton issue tracker
requests (Fri,  3 May 2013 08:00:26 +0200 (CEST)):
  
  Could  the initiator of this daily unsolicited mails on tryton-dev please
  stop?
 
 Easy we just have to fix those issues.

Mail filter adjusted...

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Freeze of repositories

[Mathias Behrle]

* Betr.:  Re: [tryton-dev] Freeze of repositories (Thu, 18 Apr 2013 11:32:10
  +0200):

 On 18/04/13 11:27 +0200, Mathias Behrle wrote:
  * Betr.:  Re: [tryton-dev] Freeze of repositories (Thu, 18 Apr 2013
  10:54:01 +0200):
  
   On 18/04/13 10:52 +0200, Mathias Behrle wrote:
* Betr.:  Re: [tryton-dev] Freeze of repositories (Thu, 18 Apr 2013
10:50:57 +0200):

 On 18/04/13 10:45 +0200, Mathias Behrle wrote:
  * Betr.:  Re: [tryton-dev] Freeze of repositories (Thu, 18 Apr
  2013 10:37:05 +0200):
  
   On 18/04/13 10:30 +0200, Mathias Behrle wrote:
* Betr.:  Re: [tryton-dev] Freeze of repositories (Sun, 24 Mar
2013 15:05:41 +0100):
 * Betr.:  Re: [tryton-dev] Freeze of repositories (Sun, 24
 Mar 2013 13:41:32 +0100):
 I herewith resign from leadership of the German translation.
 Wiki updated accordingly.

Yesterday I tried to push the german translation. It seems you
silently removed push access for me. Do you prefer patches on
the bug tracker?
   
   But you resigned.
  
  I resigned as leader, not as translator of the application. As
  already told you can read it at 
 
 That's make nonsense.
 
 Anyway, just ask to the leader of your translation team to manage it.

There is none. Again: do you prefer patches on the bug tracker?
   
   No, I prefer a leader who will be responsible.
  
  Sigh. Ok, I will provide the patches via the bug tracker.
 
 I will not spend my time on merging them.
 I do only for new translators that want to become leader and take
 responsibilities but if there is no will in the way, I don't.

As a contributor since version 1.0.0 and contributions since 2008 I don't have
to take the reproach of reluctance or irresponsibility. It is your choice to
accept or not 4-5 days effort of reviewed work.

Patches attached to https://bugs.tryton.org/issue3168

Let me know, if I should push instead.


Related links:

Reviews:
Client: https://codereview.appspot.com/8736047/
Server and Modules: https://codereview.appspot.com/8178045/

Downloadable po files:
https://bitbucket.org/yangoon/tryton_translation_de_2.8

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Freeze of repositories

[Mathias Behrle]

* Betr.:  Re: [tryton-dev] Freeze of repositories (Fri, 19 Apr 2013 19:08:27
  +0200):

 On 19/04/13 18:48 +0200, Mathias Behrle wrote:
Sigh. Ok, I will provide the patches via the bug tracker.
   
   I will not spend my time on merging them.
   I do only for new translators that want to become leader and take
   responsibilities but if there is no will in the way, I don't.
  
  As a contributor since version 1.0.0 and contributions since 2008 I don't
  have to take the reproach of reluctance or irresponsibility. It is your
  choice to accept or not 4-5 days effort of reviewed work.
  
  Patches attached to https://bugs.tryton.org/issue3168
  
  Let me know, if I should push instead.
 
 I don't understand your way of thinking.
 
 First, you did not want to be anymore the translator for German, that's
 fine we don't expect people stay forever.

It is dead simple. As noted exactly in the wiki, I never talked about
resigning from the translation of the application, but I resigned from
leadership. I do not have the time nor am I willing to take care of
translating the website, the news and the documentation. Also I won't be in
charge of searching or coordinating translators for those tasks. I am just a
simple application translator doing his job like he did for five years, but
anything more.

So the answer to 

* Cédric Krier cedric.kr...@b2ck.com:  Re: [tryton-dev] Freeze of
  repositories (Sun, 24 Mar 2013 13:41:32  +0100):
 But if for
 some reason he can not, of course he is free to delegate, resign etc. We
 just consider people are responsible to take action on time.

was to take action in time and resign from the tasks I am not able to fulfil,
in this case the leadership, as requested by you.

 And 1 day before the end of translation window, you come requesting to
 push your translations. This is completly irrational.

It is again exactly what you required translators to do. Begin translation, but
push at the end. Check the date of the codereview [1] to see, when it was
pushed. Tell me what is irrational to push at the end, even earlier than other
translators, that are pushing today?

[1] https://codereview.appspot.com/8178045/

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Freeze of repositories

[Mathias Behrle]

* Betr.:  Re: [tryton-dev] Freeze of repositories (Fri, 19 Apr 2013 20:35:11
  +0200):

 On 19/04/13 20:19 +0200, Mathias Behrle wrote:
  * Betr.:  Re: [tryton-dev] Freeze of repositories (Fri, 19 Apr 2013
  19:08:27 +0200):
  
   On 19/04/13 18:48 +0200, Mathias Behrle wrote:
  Sigh. Ok, I will provide the patches via the bug tracker.
 
 I will not spend my time on merging them.
 I do only for new translators that want to become leader and take
 responsibilities but if there is no will in the way, I don't.

As a contributor since version 1.0.0 and contributions since 2008 I
don't have to take the reproach of reluctance or irresponsibility. It
is your choice to accept or not 4-5 days effort of reviewed work.

Patches attached to https://bugs.tryton.org/issue3168

Let me know, if I should push instead.
   
   I don't understand your way of thinking.
   
   First, you did not want to be anymore the translator for German, that's
   fine we don't expect people stay forever.
  
  It is dead simple. As noted exactly in the wiki, I never talked about
  resigning from the translation of the application, but I resigned from
  leadership. I do not have the time nor am I willing to take care of
  translating the website, the news and the documentation. Also I won't be in
  charge of searching or coordinating translators for those tasks. I am just a
  simple application translator doing his job like he did for five years, but
  anything more.
 
 This is not possible, you can not have a delegate for a task if there is
 no one upstream. Nobody blames the translators to not be able to fulfill
 all tasks his is in charge, but at least we need someone to organize the
 work. If there is nobody, it is not possible to have a collaborative
 work. Also I need to have first level delegate at the global language
 level, I can not manage an infinite level of granularity on this topic.

This is contradictory in itself. And you managed already an infinite level of
granularity with respect to yourself, easily to see with commits like [1].
AFAIR there never was a leader for French...
 
 So it is dead simple, there is a leader then there is translation, there
 is no leader then there is no translation.

Wrong ;). There is translation without leader, see [2][3][4][5].
There seems only to be removed push access for the same work as years ago and
for not being maintainer.

Since you are sticking to those 6 chars and it seems to make you happy:
I retake leadership for the german translation.


[1] http://hg.tryton.org/modules/product/rev/8e16d526254d
[2] https://bugs.tryton.org/issue3168
[3] https://codereview.appspot.com/8736047/
[4] https://codereview.appspot.com/8178045/
[5] https://bitbucket.org/yangoon/tryton_translation_de_2.8

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Freeze of repositories

[Mathias Behrle]

* Betr.:  Re: [tryton-dev] Freeze of repositories (Sun, 24 Mar 2013 15:05:41
  +0100):

 * Betr.:  Re: [tryton-dev] Freeze of repositories (Sun, 24 Mar 2013 13:41:32
   +0100):
 
  On 24/03/13 12:53 +0100, Mathias Behrle wrote:
  Release dates are fixed since the begining and thus the translation
  window. When accepting the charge of translating, the translator knew
  about it so he can schedule the job for years in advance. But if for
  some reason he can not, of course he is free to delegate, resign etc. We
  just consider people are responsible to take action on time.
 
 Done.
 
 I herewith resign from leadership of the German translation. Wiki updated
 accordingly.

Yesterday I tried to push the german translation. It seems you silently removed
push access for me. Do you prefer patches on the bug tracker?

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Freeze of repositories

[Mathias Behrle]

* Betr.:  Re: [tryton-dev] Freeze of repositories (Thu, 18 Apr 2013 10:37:05
  +0200):

 On 18/04/13 10:30 +0200, Mathias Behrle wrote:
  * Betr.:  Re: [tryton-dev] Freeze of repositories (Sun, 24 Mar 2013
  15:05:41 +0100):
   * Betr.:  Re: [tryton-dev] Freeze of repositories (Sun, 24 Mar 2013
   13:41:32 +0100):
   I herewith resign from leadership of the German translation. Wiki updated
   accordingly.
  
  Yesterday I tried to push the german translation. It seems you silently
  removed push access for me. Do you prefer patches on the bug tracker?
 
 But you resigned.

I resigned as leader, not as translator of the application. As already told you
can read it at 

http://code.google.com/p/tryton/wiki/ProjectOrganization


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Freeze of repositories

[Mathias Behrle]

* Betr.:  Re: [tryton-dev] Freeze of repositories (Thu, 18 Apr 2013 10:50:57
  +0200):

 On 18/04/13 10:45 +0200, Mathias Behrle wrote:
  * Betr.:  Re: [tryton-dev] Freeze of repositories (Thu, 18 Apr 2013
  10:37:05 +0200):
  
   On 18/04/13 10:30 +0200, Mathias Behrle wrote:
* Betr.:  Re: [tryton-dev] Freeze of repositories (Sun, 24 Mar 2013
15:05:41 +0100):
 * Betr.:  Re: [tryton-dev] Freeze of repositories (Sun, 24 Mar 2013
 13:41:32 +0100):
 I herewith resign from leadership of the German translation. Wiki
 updated accordingly.

Yesterday I tried to push the german translation. It seems you silently
removed push access for me. Do you prefer patches on the bug tracker?
   
   But you resigned.
  
  I resigned as leader, not as translator of the application. As already told
  you can read it at 
 
 That's make nonsense.
 
 Anyway, just ask to the leader of your translation team to manage it.

There is none. Again: do you prefer patches on the bug tracker?

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Freeze of repositories

[Mathias Behrle]

* Betr.:  Re: [tryton-dev] Freeze of repositories (Thu, 18 Apr 2013 10:54:01
  +0200):

 On 18/04/13 10:52 +0200, Mathias Behrle wrote:
  * Betr.:  Re: [tryton-dev] Freeze of repositories (Thu, 18 Apr 2013
  10:50:57 +0200):
  
   On 18/04/13 10:45 +0200, Mathias Behrle wrote:
* Betr.:  Re: [tryton-dev] Freeze of repositories (Thu, 18 Apr 2013
10:37:05 +0200):

 On 18/04/13 10:30 +0200, Mathias Behrle wrote:
  * Betr.:  Re: [tryton-dev] Freeze of repositories (Sun, 24 Mar
  2013 15:05:41 +0100):
   * Betr.:  Re: [tryton-dev] Freeze of repositories (Sun, 24 Mar
   2013 13:41:32 +0100):
   I herewith resign from leadership of the German translation. Wiki
   updated accordingly.
  
  Yesterday I tried to push the german translation. It seems you
  silently removed push access for me. Do you prefer patches on the
  bug tracker?
 
 But you resigned.

I resigned as leader, not as translator of the application. As already
told you can read it at 
   
   That's make nonsense.
   
   Anyway, just ask to the leader of your translation team to manage it.
  
  There is none. Again: do you prefer patches on the bug tracker?
 
 No, I prefer a leader who will be responsible.

Sigh. Ok, I will provide the patches via the bug tracker.

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] Tired of fixing inherits

[Mathias Behrle]

* Betr.:  Re: [tryton-dev] Tired of fixing inherits (Fri, 8 Feb 2013 10:27:27
  +0100):

 Maybe we should try to have better names than
 Product Template and Product:
 Product and Variant ?

+1

-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature

Re: [tryton-dev] tryton: Remove safe_eval (issue 616002)

[Mathias Behrle]

* Betr.:  [tryton-dev] tryton: Remove safe_eval (issue 616002) (Sun, 16 Dec
  2012 15:23:43 +):

 Reviewers: ,
 
 
 
 Please review this at http://codereview.tryton.org/616002/
 
 Affected files:
M tryton/common/common.py
M tryton/gui/window/view_form/view/graph_gtk/line.py
M tryton/gui/window/view_form/view/graph_gtk/pie.py

Could you please elaborate?

[1] says ...almost no more required... and superseeder [2] is not yet done. 
Also superseeder [3] is not yet committed (btw. the tracker is missing an
adequate issue for superseeder [4] being closed as invalid).


[1] https://bugs.tryton.org/issue2268
[2] https://bugs.tryton.org/issue2271
[3] http://codereview.tryton.org/599002/
[4] https://bugs.tryton.org/issue2270


-- 

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6


signature.asc
Description: PGP signature