Re: [tryton-de] Schweizer Kontenrahmem (Kontenplan)
* Señor Ciego: " [tryton-de] Schweizer Kontenrahmem (Kontenplan)" (Sun, 24 Feb 2019 03:06:47 -0800 (PST)): > Wir suchen jemand der das schweizer Kontenrahmen Modul erstellen kann. Gerne > auch Angebote gegen bezahlung. Wir möchten dieses Modul danach Open Source in > allen drei Sprachen zur Verfügung stellen. Wir hatten schon mal den Kontenrahmen nach Sterchi, finde ihn nur gerade nicht. Gab es dann auch hier https://bitbucket.org/loss/trytond_account_ch/src/default/ Ich weiß ad hoc nicht, wie vollständig der ist. Der müsste jedenfalls für die von euch eingesetzte Version aufbereitet und übersetzt werden. Evtl. ist aber eine völlig neues Parsen aus den Quellen von banana.ch günstiger. Wir können das gerne für euch übernehmen. Alle weitere bei Interesse gerne per PM. Viele Grüße Mathias Behrle -- 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 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "tryton-de" sind. Weitere Optionen: https://groups.google.com/d/optout pgpPPrsIozai7.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton] Trying out Tryton via Docker
* 'Cédric Krier' via tryton: " Re: [tryton] Trying out Tryton via Docker" (Thu, 9 Aug 2018 09:19:56 +0200): > On 2018-08-08 10:38, Sergi Almacellas Abellana wrote: > > El 08/08/18 a les 05:56, RisP ha escrit: > > > Hi, > > > > > > I would like to try out Tryton, and decided to use Docker. > > > > > > The instructions seem to be ok, but the latest version didn't work. > > > > What does not work? > > If you have activated the ldap_authentication module, you may have this > problem https://bugs.tryton.org/issue7611 There seems to be a problem with the image. I guess that it installs the PyPi package which it shouldnt't. S. my answer at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905757#10 -- 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" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/20180809113228.008455c2%40monsterix.mbehrle.de. pgpXWkT9IXqPl.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-dev] Debian link broken
* 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
* 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-de] Re: Tryton Installieren
* 'Martin Fay' via tryton-de: " Re: [tryton-de] Re: Tryton Installieren" (Tue, 15 May 2018 13:25:04 -0700 (PDT)): > Am Dienstag, 15. Mai 2018 18:40:58 UTC+2 schrieb Mathias Behrle: > > > > * 'Martin Fay' via tryton-de: " Re: [tryton-de] Re: Tryton Installieren" > > (Tue, > > 15 May 2018 08:50:38 -0700 (PDT)): > > > > > Dankeschön! :) > > > > > > im Moment hänge ich noch am triton-server fest das triton-server > > > Passwort funktioniert noch nicht und ich weis noch nicht woran das > > liegt. > > > (Wie immer sitzt das Problem vor dem Monitor ;) ) > > > > > > Ich vermute das die triton.conf noch nicht stimmt. > > > > y != i > > > > Das ist die trytond.conf vermutlich. > > > > > > > > [database] > > > # Database related settings > > > > > > # The URI to connect to the SQL database (following RFC-3986) > > > # uri = database://username:password@host:port/ > > > # (Internal default: sqlite:// (i.e. a local SQLite database)) > > > # > > > # PostgreSQL via Unix domain sockets > > > # (e.g. PostgreSQL database running on the same machine (localhost)) > > > uri = postgresql://tryton:meinpasswort@/ > > > > Das ist das Zugangspasswort des PostgreSQL-Nutzers. Das vergibst du auch > > in der > > PostgreSQL. > > > > Wenn die Postgres auf derselben Maschine läuft, kannst du einfach > > uri = postgresql:/// > > eingeben. > > > > Die Datenbank musst du dann als der Nutzer erstellen, als der du > > angemeldet > > bist. > > > > > # PostgreSQL via TCP/IP > > > # (e.g. connecting to a PostgreSQL database running on a remote machine > > or > > > # by means of md5 authentication. Needs PostgreSQL to be configured to > > > accept > > > # those connections (pg_hba.conf).) > > > # uri = postgresql://tryton:triton@localhost:5432/ > > > > > > # The path to the directory where the Tryton Server stores files. > > > # The server must have write permissions to this directory. > > > # (Internal default: /var/lib/trytond) > > > path = /var/lib/tryton > > > > > > # Shall available databases be listed in the client? > > > #list = True > > > > > > # The number of retries of the Tryton Server when there are errors > > > # in a request to the database > > > #retry = 5 > > > > > > # The primary language, that is used to store entries in translatable > > > # fields into the database. > > > #language = en_US > > > > > > Das mit der integration vom Shop ist für mich absolut wichtig das muss > > > laufen. > > > Und dafür schon mal vielen Dank! > > > > Wenn du da weitergehend Hilfe brauchst, gerne, das machen wir dann aber > > per PM. > > > > > Mach ich dann ... > > > > > Habe aber noch etwas gefunden was vielleicht mehr von Allgemeinem Interesse > sein könnte. > > sudo service tryton-server status gibt folgendes Zurück: > > ● tryton-server.service - Tryton Application Platform Server >Loaded: loaded (/lib/systemd/system/tryton-server.service; enabled; > vendor preset: enabled) >Active: inactive (dead) (Result: exit-code) since Di 2018-05-15 22:18:18 > CEST; 2s ago > Process: 5338 ExecStart=/usr/bin/trytond --config > /etc/tryton/trytond.conf --logconf /etc/tryton/trytond_log.conf --cron > (code=exited, status=1/FAILURE) > Main PID: 5338 (code=exited, status=1/FAILURE) > > Mai 15 22:18:18 AMD5K systemd[1]: tryton-server.service: Unit entered > failed state. > Mai 15 22:18:18 AMD5K systemd[1]: tryton-server.service: Failed with result > 'exit-code'. > Mai 15 22:18:18 AMD5K systemd[1]: tryton-server.service: Service hold-off > time over, scheduling restart. > Mai 15 22:18:18 AMD5K systemd[1]: Stopped Tryton Application Platform > Server. > Mai 15 22:18:18 AMD5K systemd[1]: tryton-server.service: Start request > repeated too quickly. > Mai 15 22:18:18 AMD5K systemd[1]: Failed to start Tryton Application > Platform Server. > > Das heisst doch das der Server nicht läuft und die Passwort Verifizierung > hier zu gehen scheint ? Nein, der Srver lässt sich zumindest von systemd nicht starten, vermutlich wegen demselben Problem: ein Prozess lauscht bereits auf dem konfigurierten Port. Was da zu tun ist, hatte ich ja schon geschrieben. -- 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 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "tryton-de" sind. Weitere Optionen: https://groups.google.com/d/optout pgp6DQf5oCGy6.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-de] Re: Tryton Installieren
* 'Martin Fay' via tryton-de: " Re: [tryton-de] Re: Tryton Installieren" (Tue, 15 May 2018 08:50:38 -0700 (PDT)): > Dankeschön! :) > > im Moment hänge ich noch am triton-server fest das triton-server > Passwort funktioniert noch nicht und ich weis noch nicht woran das liegt. > (Wie immer sitzt das Problem vor dem Monitor ;) ) > > Ich vermute das die triton.conf noch nicht stimmt. y != i Das ist die trytond.conf vermutlich. > > [database] > # Database related settings > > # The URI to connect to the SQL database (following RFC-3986) > # uri = database://username:password@host:port/ > # (Internal default: sqlite:// (i.e. a local SQLite database)) > # > # PostgreSQL via Unix domain sockets > # (e.g. PostgreSQL database running on the same machine (localhost)) > uri = postgresql://tryton:meinpasswort@/ Das ist das Zugangspasswort des PostgreSQL-Nutzers. Das vergibst du auch in der PostgreSQL. Wenn die Postgres auf derselben Maschine läuft, kannst du einfach uri = postgresql:/// eingeben. Die Datenbank musst du dann als der Nutzer erstellen, als der du angemeldet bist. > # PostgreSQL via TCP/IP > # (e.g. connecting to a PostgreSQL database running on a remote machine or > # by means of md5 authentication. Needs PostgreSQL to be configured to > accept > # those connections (pg_hba.conf).) > # uri = postgresql://tryton:triton@localhost:5432/ > > # The path to the directory where the Tryton Server stores files. > # The server must have write permissions to this directory. > # (Internal default: /var/lib/trytond) > path = /var/lib/tryton > > # Shall available databases be listed in the client? > #list = True > > # The number of retries of the Tryton Server when there are errors > # in a request to the database > #retry = 5 > > # The primary language, that is used to store entries in translatable > # fields into the database. > #language = en_US > > Das mit der integration vom Shop ist für mich absolut wichtig das muss > laufen. > Und dafür schon mal vielen Dank! Wenn du da weitergehend Hilfe brauchst, gerne, das machen wir dann aber per PM. -- 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 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "tryton-de" sind. Weitere Optionen: https://groups.google.com/d/optout pgpUEYsaVj_42.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-de] Re: Tryton Installieren
* 'Martin Fay' via tryton-de: " Re: [tryton-de] Re: Tryton Installieren" (Tue, 15 May 2018 07:33:13 -0700 (PDT)): > Super ! > > da geh ich gleich mal ran... > > BTW: weist du wie ich den Prestashop mit tryton verbinden kann oder pushe > ich da mein Glück schon etwas zu viel? ;) Wir hatten hier für die 3.4 mal eine Integration laufen. Die dürfte etwas angestaubt sein und müsste aufpoliert werden. Außerdem gibt es von zikzakmedia eine Integration, die auf ihren esale Modulen basiert. Ich habe keine Erfahrung damit: https://bitbucket.org/zikzakmedia/trytond-prestashop > Vielen Dank für die unproblematische Hilfe! :) Gerne. -- 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 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "tryton-de" sind. Weitere Optionen: https://groups.google.com/d/optout pgp0ftcRe_n29.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-de] Re: Tryton Installieren
* 'Martin Fay' via tryton-de: " Re: [tryton-de] Re: Tryton Installieren" (Tue, 15 May 2018 06:53:48 -0700 (PDT)): > Nachtrag: > > Tryton-Server deinstalliert. > > Nun lauscht keiner mehr auf p:8000. > > Wenn ich den Server wieder installiere wird die einrichtung der Datenbank > aber nicht angestoßen. > > apt-get install tryton-server > Paketlisten werden gelesen... Fertig > Abhängigkeitsbaum wird aufgebaut. > Statusinformationen werden eingelesen Fertig > Die folgenden zusätzlichen Pakete werden Installiert > python-genshi python-polib python-relatorio python-sql > Vorgeschlagene Pakete: > python-genshi-doc python-polib-doc python-pycha python-yaml > python-mysqldb python-psycopg2 python-pysqlite2 | python-apsw python-sphinx > tryton-modules-all tryton-server-doc > Empfohlene Pakete: > postgresql postgresql-client python-bcrypt python-levenshtein > python-psycopg2 python-pydot python-webdav unoconv > Die folgenden NEUEN Pakete werden installiert: > python-genshi python-polib python-relatorio python-sql tryton-server > 0 aktualisiert, 5 neu installiert, 0 zu entfernen und 1 nicht aktualisiert. > Es müssen noch 0 B von 745 kB an Archiven heruntergeladen werden. > Nach dieser Operation werden 5.588 kB Plattenplatz zusätzlich benutzt. > Möchten Sie fortfahren? [J/n] J > Vormals nicht ausgewähltes Paket python-genshi wird gewählt. > (Lese Datenbank ... 565001 Dateien und Verzeichnisse sind derzeit > installiert.) > Vorbereitung zum Entpacken von .../python-genshi_0.7-5_amd64.deb ... > Entpacken von python-genshi (0.7-5) ... > Vormals nicht ausgewähltes Paket python-polib wird gewählt. > Vorbereitung zum Entpacken von .../python-polib_1.0.7-1_all.deb ... > Entpacken von python-polib (1.0.7-1) ... > Vormals nicht ausgewähltes Paket python-relatorio wird gewählt. > Vorbereitung zum Entpacken von .../python-relatorio_0.6.2-1_all.deb ... > Entpacken von python-relatorio (0.6.2-1) ... > Vormals nicht ausgewähltes Paket python-sql wird gewählt. > Vorbereitung zum Entpacken von .../python-sql_0.8-1_all.deb ... > Entpacken von python-sql (0.8-1) ... > Vormals nicht ausgewähltes Paket tryton-server wird gewählt. > Vorbereitung zum Entpacken von .../tryton-server_3.8.3-1_all.deb ... > Entpacken von tryton-server (3.8.3-1) ... > Trigger für systemd (229-4ubuntu21.2) werden verarbeitet ... > Trigger für ureadahead (0.100.0-19) werden verarbeitet ... > Trigger für man-db (2.7.5-1) werden verarbeitet ... > python-genshi (0.7-5) wird eingerichtet ... > python-polib (1.0.7-1) wird eingerichtet ... > python-relatorio (0.6.2-1) wird eingerichtet ... > python-sql (0.8-1) wird eingerichtet ... > tryton-server (3.8.3-1) wird eingerichtet ... > Benutzer tryton wird zur Gruppe ssl-cert hinzugefügt. > Trigger für systemd (229-4ubuntu21.2) werden verarbeitet ... > Trigger für ureadahead (0.100.0-19) werden verarbeitet ... > > Hier findest du Einrichtungshinweise für die 3.8 und wie du deine Datenbank erstellen kannst: https://salsa.debian.org/tryton-team/tryton-server/blob/debian-stretch-3.8/debian/tryton-server.README.Debian -- 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 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "tryton-de" sind. Weitere Optionen: https://groups.google.com/d/optout pgpsvEatcDz7S.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-de] Re: Tryton Installieren
* 'Martin Fay' via tryton-de: " [tryton-de] Re: Tryton Installieren" (Tue, 15 May 2018 03:54:35 -0700 (PDT)): > Am Dienstag, 15. Mai 2018 12:08:52 UTC+2 schrieb Martin Fay: > > > > Hallo, > > > > > > System Linux Mint 18.3 > > > > ich habe tryton-neso installiert gehabt und dieses per Softwarecenter > > entfernt. > > Gelöscht wurde mit purge und autoremove... > > > > Nun versuche ich Tryton-Server und Client zu installieren Mit sehr > > begrenztem Erfolg. > > > > Client und Sever werden zwar installiert und sind aus dem gleichen > > Versionszweig, aber der tryton*d* meldet eine ältere Version. > > Das Harmoniert natürlich nicht. > > > > Also habe ich wieder alles runter geworfen und gesehen das unter > > /usr/share/Pyton Verzeichniss noch Konfigurationsdateien von Tryton > > verblieben sind .. :/ > > > > (Den dortigen Tryton Ordner hab ich (voreilig)gelöscht) > > > > und nun versuche ich tryton gerade per pip zu installieren... > > > > sudo pip install trytond > > > > das gibt mir aber folgenden Fehler zurück. > > > > pip install trytond > > Traceback (most recent call last): > > File "/usr/bin/pip", line 9, in > > from pip import main > > ImportError: cannot import name main > > > > > > Und da ich von pyton viel zu wenig Ahnung habe erhoffe ich mir nun hier > > etwas Hilfe :) > > > > Grüße > > Martin > > > > > Ich habe eben noch mal aus den Mint repos installiert. > > Nun bekomme ich den Dialog zur Datenbank erstellung und die Passwort abfage > diese funktioniert, aber mein Passwort zur Erstellung > einer neuen Datenbank funktioniert nicht. > Wo ist dieses abgelegt? > > Grüße > Martin > Welche Tryton Version ist das? Und was hast du genau gemacht zur Datenbank*erstellung*? Grüße, 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 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "tryton-de" sind. Weitere Optionen: https://groups.google.com/d/optout pgpNfuMQdRJk3.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton] Tryton Debian packages
* Mathias Behrle: " [tryton] Tryton Debian packages" (Thu, 5 Apr 2018 11:45:17 +0200): Dear all, here comes a short update of the current situation. Thanks to the initiative of Freexian [1] together with sponsoring of Entr'ouvert [2] the packaging of the Tryton LTS version 5.0 is secured. This will just be in time for the inclusion in the next Debian stable release (Buster) and those packages will also be part and maintained as usual as backports on debian.tryton.org [3]. With best thanks to both companies, Mathias Behrle [1] https://www.freexian.com/ [2] http://www.entrouvert.com/en/ [3] https://tryton-team.pages.debian.net/ > Dear Tryton users, > > this mail is to let you know, that the continued maintenance of the Tryton > packages for Debian in my free time is currently out-of-scope. > > I will continue to maintain the backports at debian.tryton.org for the > lifetime of the currently supported series, but there will be no new series > packaged out-of-the-box. > > If you depend or if you want to sponsor in some way a future Tryton version > in Debian or at debian.tryton.org, please let me know and I will be glad to > find a solution. > > Regards, > Mathias Behrle > -- 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" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/20180502122256.0d8ee669%40monsterix.mbehrle.de. pgp5GXRLGRzxs.pgp Description: Digitale Signatur von OpenPGP
[tryton] Tryton Debian packages
Dear Tryton users, this mail is to let you know, that the continued maintenance of the Tryton packages for Debian in my free time is currently out-of-scope. I will continue to maintain the backports at debian.tryton.org for the lifetime of the currently supported series, but there will be no new series packaged out-of-the-box. If you depend or if you want to sponsor in some way a future Tryton version in Debian or at debian.tryton.org, please let me know and I will be glad to find a solution. Regards, Mathias Behrle -- 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" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/20180405114517.65f726f9%40monsterix.mbehrle.de. pgpFsKVgOoL88.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-dev] Impact mitigation for DDoS attack
* 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
* 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] Proteus
* Cato Nano: " Re: [tryton] Proteus" (Fri, 12 Jan 2018 11:23:19 -0800 (PST)): > So I bothered Mathias > > Oh well :-/ Not a problem, be welcome. Have fun, 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" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/20180113011252.4bf0d7d7%40privatix.mbehrle.de. pgpPMh9FNIHlP.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton] Proteus
* Cédric Krier: " Re: [tryton] Proteus" (Thu, 11 Jan 2018 01:07:32 +0100): > On 2018-01-10 11:52, Cato Nano wrote: > > When called from within a python3 prompt, Proteus gets found > > > > But this time xmlrpclib is missing > > > > Also, xmlrpclib is not declared as a dependency in the Proteus setup.py > > file > > xmlrpclib is a standard library of Python so it should not be declared > as dependency. > But indeed xmlrpclib is the name for Python2, in Python3 it should be > xmlrpc. > Normally, when installing proteus with Python3, the code is transformed > and xmlrpclib is changed for xmlrpc. So it seems the installation is > wrong. I guess it should be reported to the distribution you are using. Wrong guess. JFTR: It was explained on the Debian mailing list to Cato Nano that he has to take care himself for 2to3 conversion when not using distribution packages and running instead from a downloaded package. -- 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" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/2018033847.19cfc542%40monsterix.mbehrle.de. pgpaxZT9Gz3AW.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-de] tryton startet nicht richtig
* porrie...@gmail.com: " [tryton-de] tryton startet nicht richtig" (Sat, 23 Dec 2017 07:47:37 -0800 (PST)): > Hallo! > > Wollte tryton testen mittels Aufruf der nicht installierten Version > tryton-4.6.0, > bekomme beim Start aber den Fehler: > > ImportError: No module named chardet > > pip insall chardet habe ich ausgeführt. > > Hat hier jemand einen Tip? > > Grüße > > Andreas > Kannst du uns noch Infos dazu geben, auf welchem Betriebssystem du was wie installiert hast? Viele Grüße, 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 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "tryton-de" sind. Weitere Optionen: https://groups.google.com/d/optout pgp2Qs2yNHK7V.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-de] Re: Deutsche Übersetzung (Leader)
* Mathias Behrle: " Re: [tryton-de] Re: Deutsche Übersetzung (Leader)" (Fri, 24 Feb 2017 12:28:56 +0100): Hallo Clemens, [...] > > Insofern warte ich noch etwas auf Resonanz und komme beizeiten gerne auf > > dein Angebot zurück. Für die gegenwärtige stable (4.6) wurde offenbar nichts an der deutschen Übersetzung gemacht. Gibt es irgendwelche Neuigkeiten, wie es dazu gekommen ist? Wirst du dich künftig um die Übersetzung kümmern? Viele Grüße, 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 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "tryton-de" sind. Weitere Optionen: https://groups.google.com/d/optout pgpAO5fZq6dZU.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton] login problems
X-Post and Follow_up to General GNU Health discussion and help <hea...@gnu.org> * Thilo Gesche: " [tryton] Aw: You have joined the group tryton@googlegroups.com" (Thu, 14 Sep 2017 08:32:15 +0200): Hi Thilo, > Hello, > > I am unable to connect to any google site from within China (without a VPN I > usually do not need), so I am hoping anyone is able to help me with the > problem described below. I installed trytond 4.2.6, tryton 4.2.6 and > dependencies on opensuse leap 42.3 plus gnuhealth but did not manage to login > to the database. For the installation I followed the opensuse documentation. Could you provide us the exact URL? > I get stuck at the point where the tryton client asks for the password (for > the user tryton and the database I have just created and initialized - see > commands below). Using the same password I entered when initializing the > database did not work as expected. I can enter the psql database via command > lien or pgadmin. By now I have tried the installation on two different > computers which probably means I unknowingly repeat an error during the setup > or there is a authentification probem within. Maybe related to the timezone > or the encoding? The only change in trytond.conf was uncommenting #super_pwd > =. (Leaving as it is does not make a difference). super_pwd is gone in trytond 4.2 [1], so this one is at least some cruft in the configuration. It also doesn't exist in the vanilla gnuhealth configuration in the development repository [2]. What I am missing in the native gnuhealth installation script is the dependency for bcrypt. Anyway it would be easier to help if you could provide some verbose log. For that you can start trytond-admin with the -v switch. [1] http://doc.tryton.org/4.2/trytond/doc/topics/configuration.html [2] http://hg.savannah.gnu.org/hgweb/health/ Cheers, Mathias > Any help sorting out the > issue is highly appreciated. Kind regards Thilo, Chengdu, China tryton client > error message (process:7395): Gtk-WARNING **: Locale not supported by C > library. Using the fallback 'C' locale. database commands # su - postgres -c > "createdb mydb --encoding='UTF-8' --owner=tryton" # sudo su tryton > -s /bin/bash # /usr/bin/trytond-admin -c /etc/tryton/trytond.conf --all -d > mydb tryton log entry Wed Sep 13 02:22:38 2017] > INFO:trytond.protocols.dispatcher:bad login or password 'tryton' from > 127.0.0.1 using http on database 'mydb' Gesendet: Donnerstag, 14. September > 2017 um 13:38 Uhr Von: tryton <tryton+subconf...@googlegroups.com> An: > t_ges...@web.de Betreff: You have joined the group tryton@googlegroups.com > > You are now a member of the tryton group. > > > Visit This Group > > Start your own group, visit the help center, or report abuse. > > -- > You received this message because you are subscribed to the Google Groups > "tryton" group. To view this discussion on the web visit > https://groups.google.com/d/msgid/tryton/trinity-5cc816f7-ba8d-4970-94a1-d4fd6cc7b783-1505370735838%403c-app-webde-bs43. -- 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" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/20170914112810.39683875%40monsterix.mbehrle.de. pgpjr9J5d9QIm.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-dev] Translations updated for 4.4
* 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] Back-order limitation
* Cédric Krier: " [tryton] Back-order limitation" (Tue, 28 Mar 2017 10:54:10 +0200): > Hi, > > I have a requirement to not create back-orders for a sale if the > quantity shipped is closed enough of the ordered quantity. > For example, if the customer ordered 10Kg and the company ships only > 9.9Kg, no back-order should be created because it is below 10%. > > I'm wondering if you have already encounter such requirements and if > there were no other kind of rules? > > I'm thinking about proposing a standard module for this if it is a > common enough practice. Another requirement (use case) is to not create backorders at all (i.e. the missing quantity is handled by the customer with the next purchase. -- 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" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/20170328111255.0bdb6297%40monsterix.mbehrle.de. pgpoMjswqtco9.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-de] Re: Deutsche Übersetzung (Leader)
* Clemens Hupka: " [tryton-de] Re: Deutsche Übersetzung (Leader)" (Wed, 4 Jan 2017 06:34:56 -0800 (PST)): Hallo Clemens, > Hallo Mathias, > > Zuerst mal ein frohes neues Jahr und ein Dankeschön für all die Arbeit die > Du in dieses Projekt schon investiert hast. Danke. > Am Donnerstag, 15. Dezember 2016 18:02:12 UTC+1 schrieb Mathias Behrle: > > > > Hallo zusammen, > > > > nach dem Release ist vor dem Release und ich nehme diesen frühen Zeitpunkt > > im nächsten Releasezyklus als Anlass schon einmal an die nächste > > Übersetzung zu > > denken. > > > > Ich mache die deutsche Übersetzung als sog. Translation Leader für Tryton > > seit > > nunmehr 8 Jahren und denke, dass es an der Zeit ist, diese in andere Hände > > abzugeben. Die weiteren Aufgaben wie die Pflege der Debian-Pakete inkl. > > Upstream Security Support und Backports für Tryton und GNU Health sowie > > der > > diversen Dockerimages verschlingen eine Menge Zeit, so dass eine > > Verteilung der > > Arbeit auf mehrere (bzw. andere) Schultern angebracht erscheint. > > > > Ich habe die deutsche Übersetzung auf dem pootle-Server nochmals auf den > > letzten > > Stand gebracht (will heißen: einige Fehler korrigiert, die mir in der 4.2 > > aufgefallen sind bzw. durch letzte String Fixes nach Ende der > > Übersetzungsperiode verursacht wurden). Mein Nachfolger findet also ein > > wohlbestelltes Haus vor. > > > > Interessenten mögen sich bitte hier melden. Ich kann dann meinen > > Nachfolger > > direkt als Admin für Deutschland auf dem pootle Server eintragen. > > > > Nachdem sich bisher niemand gemeldet hat, und ich Dich nicht unbedingt im > Regen stehen lassen will, melde ich mich einmal mit etwas Vorbehalt. Ich würde es aus meiner Perspektive anders formulieren. Ich bleibe da nicht im Regen stehen, es gibt halt schlicht keine gepflegte deutsche Übersetzung für das nächste Release, wenn sich niemand meldet. > Ich arbeite seit ca. 2 Jahren mit tryton und konkret seit 1,5 Jahren an der > Umsetzung für ein Unternehmen in der Textilbranche. Die heiße Phase beginnt > gerade, daher mein Vorbehalt, da ich in den nächsten Monate nicht übermäßig > viel Zeit haben werde. Die heiße Phase für Übersetzungen ist definitiv 1-2 Wochen vor Release. Da sollte man anwesend sein. Selbstverständlich kann man aber auch vorarbeiten (und muss dann 'nur' nacharbeiten, was an späten Stringfixes noch committet wird, der Verlust von bereits vorbereiteten Übersetzungen wie beim letzten Release war hoffentlich ein einmaliger Vorgang). > Andererseits stehe ich mitten drin, wir nutzen ca. > 70% der Standard-Module, sprich korrekte Übersetzungen sind unbedingt > nötig. Bin übrigens zweisprachig aufgewachsen (Deutsch/Französisch), was > beim Übersetzung sicher auch kein Nachteil ist. Das sind eigentlich beste Voraussetzungen. Wir selbst setzen eher auf einen eigenen Modulstack und nutzen sicher keine 70% der Standard-Module, also von daher...;) Die größten Herausforderungen bei der Übersetzung sind: - applikationsweit (also über alle Module) die Übersetzung kongruent halten - generische Begriffe mit einigermaßen tragbaren und doch korrekten Äquivalenten zu übersetzen > Also wenn sich sonst niemand melden sollte, dann können wir darüber > sprechen. Bisher habe ich mich auf pootle noch nahezu gar nicht eingebracht. > > Meine pootle-Erfahrung hält sich in Grenzen, aber ich nutze seit einiger > Zeit WebLate und wenn mich nicht alles täuscht, dann ist das sowieso ein > pootle-Fork, also wahrscheinlich sehr ähnlich. Fork eigentlich nicht, nutzt halt auch translate-toolkit und django. Du wirst dich auf jeden Fall zurecht finden, wenn du schon mit solchen Oberflächen gearbeitet hast. > Wenn Du jemanden anderen bei der Hand hast, umso besser! > > Bezüglich AT/DE, viele Unterschiede gibt es da ja bestimmt nicht, oder? Ich > selber bin nämlich in Österreich tätig... Viele nicht, einige schon:) Wenn du Zweifel hast, kannst du ja z.B. hier nachfragen. Letzten Endes gilt: Man kann schlicht froh und dankbar sein, wenn es jemand macht, vor allem wenn man selbst nicht bereit ist etwas beizusteuern. Es gibt genug deutsche bzw. deutschsprachige Unternehmen, die Tryton einsetzen und sich hier nicht gerade mit Ruhm bekleckern. Insofern warte ich noch etwas auf Resonanz und komme beizeiten gerne auf dein Angebot zurück. > Liebe Grüße aus dem verwehten Wien, Besten Dank für deine Rückmeldung, 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 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "tryton-de" sind. Weitere Optionen: https://groups.google.com/d/optout pgpLZhzVUhQtH.pgp Description: Digitale Signatur von OpenPGP
[tryton-de] Deutsche Übersetzung (Leader)
Hallo zusammen, nach dem Release ist vor dem Release und ich nehme diesen frühen Zeitpunkt im nächsten Releasezyklus als Anlass schon einmal an die nächste Übersetzung zu denken. Ich mache die deutsche Übersetzung als sog. Translation Leader für Tryton seit nunmehr 8 Jahren und denke, dass es an der Zeit ist, diese in andere Hände abzugeben. Die weiteren Aufgaben wie die Pflege der Debian-Pakete inkl. Upstream Security Support und Backports für Tryton und GNU Health sowie der diversen Dockerimages verschlingen eine Menge Zeit, so dass eine Verteilung der Arbeit auf mehrere (bzw. andere) Schultern angebracht erscheint. Ich habe die deutsche Übersetzung auf dem pootle-Server nochmals auf den letzten Stand gebracht (will heißen: einige Fehler korrigiert, die mir in der 4.2 aufgefallen sind bzw. durch letzte String Fixes nach Ende der Übersetzungsperiode verursacht wurden). Mein Nachfolger findet also ein wohlbestelltes Haus vor. Interessenten mögen sich bitte hier melden. Ich kann dann meinen Nachfolger direkt als Admin für Deutschland auf dem pootle Server eintragen. Viele Grüße und eine geruhsame Weihnachtszeit, 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 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "tryton-de" sind. Weitere Optionen: https://groups.google.com/d/optout pgpQQSw8umSb6.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton] version du serveur incompatble - server version not compatible
* Armand Mpassy-Nzoumba: " Re: [tryton] version du serveur incompatble - server version not compatible" (Tue, 4 Oct 2016 00:51:32 +0100): Hi Armand, > Hi Axel > > On Mon, Oct 3, 2016 at 6:35 PM, Axel Braun <axel.br...@gmx.de> wrote: > > > Hi Armand, > > > > > > Can you connect via Web-Frontend from the sdame computer? Then it may be an > > issue with the firewall. > > For the rest, the only thing to be done is to set the correct path in > > [jsonrpc]. If you install from the package: > > > > # The root path to retrieve data for GET requests > > data = /usr/lib/node_modules/tryton-sao > > > > ..otherwise there, where the sao-files are installed > > > > I can't connect from the localhost. I still get the following error message: > > Internal Server Error > > The server encountered an internal error and was unable to complete your > request. Either the server is overloaded or there is an error in the > application. > > Here is my config related to tryton-sao. I also recall that the [jsonrpc] > is no longer valid under tryton 4.0. > > [web] > listen = [::]:8000 > root = /usr/lib/node_modules/tryton-sao/ > > I am not an expert of tryton yet. However I came across the link of the > tryton-sao ftp directory under debian: > https://ftp-master.debian.org/new/tryton-sao_4.0.4-1.html That's not a complete source directory, it is the Debian New Queue. For complete sources better look at [0][1]. > When I compare the files to the tryton-sao installation under OpenSuse, it > looks like a few files are missing. For exemple I don't see the index.html > file. sao currently needs jquery2, so tryton-sao runs out of the box on Debian stable (jessie) using [2] with the sources for Distribution jessie-4.0. When running Debian testing/unstable, you have to provide/pin jquery to version 2, because it has already jquery3. Cheers, Mathias NB: The packaging in Debian[1] is substantially different from the OpenSuse packaging[3], as the latter provides bundled bower components, while the Debian packaging uses native packages from Debian main. [0] http://tryton.alioth.debian.org/ [1] https://anonscm.debian.org/cgit/tryton/tryton-sao.git/ [2] http://tryton.alioth.debian.org/mirror.html#how-to [3] https://build.opensuse.org/package/show/Application:ERP:Tryton:4.0/tryton-sao -- 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" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/20161004103442.14139674%40monsterix.mbehrle.de. pgpsSYfNorsaT.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-de] tryton 4.0
* Max Mustermann: " [tryton-de] tryton 4.0" (Thu, 29 Sep 2016 04:19:08 -0700 (PDT)): > Hat jemand eine HowTo wie man trytond-server 4.0 auf ein debian server > installiert ? Z.B. http://tryton.alioth.debian.org/mirror.html > Es ist jämmerlich zuzusehen wie ein paar Entwickler Tryton verkrüppeln. Was ist damit gemeint? -- 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 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "tryton-de" sind. Weitere Optionen: https://groups.google.com/d/optout pgpK3p0iNtlSu.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-dev] How to write tooltips
* '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] Netiquette
* Jean Cavallo: " Re: [tryton] Netiquette: (was: Daily Cash Closing/hand over by Cash Clerk at Cash counter)" (Fri, 23 Sep 2016 18:01:15 +0200): > 2016-09-23 17:44 GMT+02:00 Mathias Behrle <mbeh...@m9s.biz>: > > > > But no problem to add it on the mailing list pages. > > > I will do it for English and French one, please administrator of other > > > languages do the same. > > > > You are completely missing the point about "...first be reached a broader > > agreement" and "consensus". > > > The decision was made some time ago, so we should stick with it. > > https://groups.google.com/forum/?hl=en#!topic/tryton/-IA9TLq5qag Still the same thread. I see a (quite limited) discussion, not a broad agreement. This discussion diverges from my initial intention. I am absolute in favor of 'netiquette', but netiquette is about much more than looking at the posting style.[0][1] "Rule 10: Be forgiving of other people's mistakes Everyone was a network newbie once. And not everyone has had the benefit of reading this book. So when someone makes a mistake -- whether it's a spelling error or a spelling flame, a stupid question or an unnecessarily long answer -- be kind about it. If it's a minor error, you may not need to say anything. Even if you feel strongly about it, think twice before reacting. Having good manners yourself doesn't give you license to correct everyone else. If you do decide to inform someone of a mistake, point it out politely, and preferably by private email rather than in public. Give people the benefit of the doubt; assume they just don't know any better. And never be arrogant or self-righteous about it. Just as it's a law of nature that spelling flames always contain spelling errors, notes pointing out Netiquette violations are often examples of poor Netiquette."[2] Please have a look especially at the last sentence, that explains much better the actual case than I could do. So I propose to use *and* apply to a real 'netiquette' document instead of the quite short discussion thread as the pointer for Tryton discussion groups. I am very much in favor of [1], as [3] is contradictory in itself (using capitals and multiple exclamation marks for e.g. "DO NOT TOP-POST and DO trim your replies!!!" while saying in the very same document "Don't SHOUT! While it might look clearer to you if everything is in capitals in your message, it is considered SHOUTING, and therefore very rude.") [0] https://en.wikipedia.org/wiki/Posting_style [1] http://www.albion.com/netiquette/book/index.html [2] http://www.albion.com/netiquette/book/0963702513p45.html [3] http://linux.sgms-centre.com/misc/netiquette.php -- 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" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/20160924114333.15161afe%40monsterix.mbehrle.de. pgpYKFTOgT1XS.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton] Re: Some questions regarding Payments
* Khurram Shahzad: " [tryton] Re: Some questions regarding Payments" (Mon, 29 Aug 2016 21:52:21 -0700 (PDT)): > In fact, I have to use GNU Health which supports Tryton 3.8. Is there any > way or any arrangement that I can use Tryton 4.0 modules along with GNU > Health? Of course you can backport the module to 3.8. Roughly spoken this will at least need to revert/adapt the procedures in https://discuss.tryton.org/t/migration-from-3-8-to-4-0 so that the module can work with version 3.8. Best, Mathias > > On Monday, August 29, 2016 at 11:40:04 AM UTC+5, Khurram Shahzad wrote: > > > > Dear Community, > > > > When a patient is admitted to the hospital, he deposits some amount as > > advance. Similarly, often some advance payment is made to Suppliers with > > purchase order BEFORE the generation of invoice. How can these payments be > > managed in Tryton? > > > > Moreover, when a payment on cheque is made/received, how can we record the > > cheque details like cheque number, bank, date, account details etc? > > > > Using Payment module of Tryton, payments are processed in groups and can > > be marked with "Success" or "Fail". This status can be changed anytime; is > > there anyway that we can make the payment read only so that its "Success" > > or "Fail" status can't be changed? > > > > Thanking you in anticipation. > > > > Regards, > > Khurram. > > > -- 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" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/20160830110749.6ea036d6%40monsterix.mbehrle.de. pgpNcPtmjpOZB.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-dev] New __init__ style
* 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] Error starting trytond
* Marko Randjelovic: " Re: [tryton] Error starting trytond" (Thu, 28 Jul 2016 01:46:31 -0700 (PDT)): > On Thursday, July 28, 2016 at 9:20:21 AM UTC+2, Sergi Almacellas Abellana > wrote: > > > > El 27/07/16 a les 21:50, Marko Randjelovic ha escrit: > > > When starting trytond ver 4.1.0, I get this error: > > > > > > (trytond) mr@abc24:~/training/trytond4$ bin/trytond -c ../trytond4p.conf > > > -d test > > > Traceback (most recent call last): > > > File "bin/trytond", line 24, in > > > from trytond.application import app > > > File "/home/mr/training/trytond4/trytond/application.py", line 8, in > > > > > > Pool.start() > > > File "/home/mr/training/trytond4/trytond/pool.py", line 97, in start > > > register_classes() > > > File "/home/mr/training/trytond4/trytond/modules/__init__.py", line > > > 362, in register_classes > > > mod_file, pathname, description) > > > File "/home/mr/training/trytond4/trytond/modules/account/__init__.py", > > > line 6, in > > > from .account import * > > > File "/home/mr/training/trytond4/trytond/modules/account/account.py", > > > line 8, in > > > from sql import Column, Null, Window, Literal > > > ImportError: cannot import name Window > > > > account module at least version 0.7 of python-sql [1] and you seem to > > have and older version. Please upgrade you python-sql to a more recent > > version. > > > > (trytond) mr@abc24:~/training$ pip install python-sql --upgrade > Collecting python-sql > Installing collected packages: python-sql > Found existing installation: python-sql 0.4 > Not uninstalling python-sql at /usr/lib/python2.7/dist-packages, > outside environment /home/mr/training/.venv/trytond You seem to have python-sql installed via your package manager and eventually your virtualenv is set up with global-site-packages enabled. What is the OS you are running? So either update the first one with a recent version or change your virtualenv to not use site-packages (in which case pip will install python-sql into the virtualenv). Regards, Mathias > Successfully installed python-sql-0.4 > > For some reason pip installs again the same version. In repo available is > 0.8. > > (trytond) mr@abc24:~/training$ pip search sql | grep "^python-sql" > python-sql-abstraction (0.0.1) - SQL Abstraction > layer written in Python 3.2 for use in lower level applications, such as > tkinter. > python-sql (0.8) - Library to write > SQL queries > > > > > [1] http://hg.tryton.org/modules/account/file/5d2be5235e04/setup.py#l50 > > <http://www.google.com/url?q=http%3A%2F%2Fhg.tryton.org%2Fmodules%2Faccount%2Ffile%2F5d2be5235e04%2Fsetup.py%23l50=D=1=AFQjCNGP6z8lHoJAm3DPcs_AvcMccvQHgA> > > > > > > -- > > Sergi Almacellas Abellana > > www.koolpi.com > > Twitter: @pokoli_srk > > > -- 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 -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/20160728111745.00439043%40monsterix.mbehrle.de. pgpjyL2ZvHo8M.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-de] Installation tryton 3.6 auf Client-Server Umgebung
* Waltix: " Re: [tryton-de] Installation tryton 3.6 auf Client-Server Umgebung" (Tue, 5 Jul 2016 04:27:10 -0700 (PDT)): > Ja, tatsächlich das geht wirklich so : (wer lesen kann ist glatt im > Vorteil) : > > Also : > - mit der crypt-Routine das PW erstellen > - ermittelten Wert in die trytond. conf eintragen : super_pwd = ermittelter > wert > - conf-Datei speichern > - tryton-Server restarten > > und alles ist gut :) > > gruß > > Walter > > > Ja, genau so gehts. Viel Spaß mit Tryton, 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: 0x8405BBF6 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "tryton-de" sind. Weitere Optionen: https://groups.google.com/d/optout pgpvxrGolEmPV.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-de] Installation tryton 3.6 auf Client-Server Umgebung
* Waltix: " [tryton-de] Installation tryton 3.6 auf Client-Server Umgebung" (Tue, 5 Jul 2016 02:25:19 -0700 (PDT)): > Hallo Leute, > > brauche mal Eure Hilfe bei der Installation von Tryton ! > Server : Ubuntu V. 12.04 - Zugriff über ssh > Tryton Server : V. 3.6 (aus den Ubuntu-Quellen installiert - auch alle > Module) > Tryton Client : V. 3.6.2 auf Linux-Mint 17 > > Ich habe alles installiert - soweit alles ok > Hab noch keine Postgresql-DB aktiviert ... sollte erst mal mit Sqlite > laufen, so zum Testen. > Der Tryton Server läuft ... Port in der trytond.conf angepaßt. > Der Client meldet sich auch akkurat auf dem Server an und fordert auf eine > neue DB zu erstellen. > Hierzu muß man nun u.a. das Paßwort des Tryton-Servers angeben. > > Und hier liegt mein Problem ... welches PW ? ... wo steht das ... "admin" > ist es nicht !! > > Fehlermeldung : *Zugang verweigert!* Das für den Tryton Server eingegebene > Passwort scheint falsch zu sein. Bitte nochmals eingeben. > > Hab ich irgend etwas überlesen ? Oder muß ich dieses PW erst kreieren ? Dieses Passwort muss in der Konfigurationsdatei für den Server konfiguriert werden. Eine kommentierte Version für die 3.6 findest du z.B hier: https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=tryton/tryton-server.git;a=blob_plain;f=debian/trytond.conf;hb=refs/heads/debian-stretch-3.6 Viele Grüße, 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: 0x8405BBF6 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "tryton-de" sind. Weitere Optionen: https://groups.google.com/d/optout pgp1EE93VDbZd.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-de] Re: Installationsprobleme
* Hans Normann: " Re: [tryton-de] Re: Installationsprobleme" (Thu, 12 May 2016 04:15:38 -0700 (PDT)): > Fedora scheint ja nicht gerade auf dem Laufenden zu sein Die 2.6 ist in der Tat einigermaßen betagt und mittlerweile aus den unterstützten Serien herausgefallen. Gibt es vielleicht irgendwelche Backports? > [root@localhost etc]# dnf info tryton > Letzte Prüfung auf abgelaufene Metadaten: vor 0:28:31 am Thu May 12 > 12:23:32 2016. > Installierte Pakete > Name: tryton > Arch: noarch > Epoch : 0 > Version : 2.6.1 > Release : 6.fc23 > Größe : 4.0 M > Paketquelle : @System > Aus Paketqu : fedora > > > [root@localhost etc]# dnf info trytond > Letzte Prüfung auf abgelaufene Metadaten: vor 0:38:22 am Thu May 12 > 12:23:32 2016. > Installierte Pakete > Name: trytond > Arch: noarch > Epoch : 0 > Version : 2.6.2 > Release : 5.fc23 > Größe : 4.6 M > Paketquelle : @System > Aus Paketqu : fedora > Zusammenfas : Server for the Tryton application framework > URL : http://www.tryton.org > > > Bin zumindest jetzt soweit gekommen, dass die Datenbank angelegt wurde (ir* > und res* Tabellen und Sequenzen sind installiert). Jetzt kämpfe ich weiter > mit dem Login. Das System akzeptiert weder admin noch tryton als Login. Du solltest dich mit admin und dem bei Erstellung der Datenbank vergebenen Passwort anmelden können. Evtl. musst du den Client beenden, die known_hosts unter ~/.config/tryton/2.6 löschen, den Client neu starten, wenn sich die Verbindungseinstellungen bzgl. SSL geändert haben. > Und hier noch die /etc/trytond.conf > > #This file is part of Tryton. The COPYRIGHT file at the top level of > #this repository contains the full copyright notices and license terms. > [options] > > # Activate the json-rpc protocol > jsonrpc = [::]:8000 > #ssl_jsonrpc = False > > # This is the hostname used when generating tryton URI > #hostname_jsonrpc = > > # Configure the path of json-rpc data > #jsondata_path = /var/www/localhost/tryton > > # Activate the xml-rpc protocol > #xmlrpc = *:8069 > #ssl_xmlrpc = False > > # Activate the webdav protocol > #webdav = *:8080 > #ssl_webdav = False > > # This is the hostname used when generating WebDAV URI > #hostname_webdav = > > # Configure the database type > # allowed values are postgresql, sqlite, mysql > db_type = postgresql > > # Configure the database connection > ## Note: Only databases owned by db_user will be displayed in the > connection dialog > ## of the Tryton client. db_user must have create permission for new > databases > ## to be able to use automatic database creation with the Tryton client. > db_host = localhost > db_port = 8000 > #db_user = False > db_user = tryton > db_password = XX > #db_password = False > #db_minconn = 1 > #db_maxconn = 64 > > # Configure the postgresql path for the executable > #pg_path = None > > # Configure the Tryton server password > #admin_passwd = admin > > # Configure the path of the files for the pid and the logs > #pidfile = False > #logfile = False > > #privatekey = server.pem > #certificate = server.pem > > # Configure the SMTP connection > #smtp_server = localhost > #smtp_port = 25 > #smtp_ssl = False > #smtp_tls = False > #smtp_password = False > #smtp_user = False > > # Configure the path to store attachments and sqlite database > #data_path = /var/lib/trytond > > # Allow to run more than one instance of trytond > #multi_server = False > > # Configure the session timeout (inactivity of the client in sec) > #session_timeout = 600 > > # Enable auto-reload of modules if changed > #auto_reload = True > > # Prevent database listing > #prevent_dblist = False > > # Enable cron > # cron = True > > # unoconv connection > #unoconv = pipe,name=trytond;urp;StarOffice.ComponentContext > > # Number of retries on database operational error > # retry = 5 > > # Default database language code > # language = en_US > > # Timezone of the server > # timezone = False > > > -- 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 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "tryton-de" sind. Weitere Optionen: https://groups.google.com/d/optout pgpVyUpnQ0Z0s.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-de] Re: Installationsprobleme
* Hans Normann: " [tryton-de] Re: Installationsprobleme" (Thu, 12 May 2016 03:20:41 -0700 (PDT)): > OK, habe ich ja schneller gefunden als ich dachte. Der Wert für jsonrpc war > falsch. > > Und schon kommt das nächste Problem. Ich rufe den Client auf, will ein > neues Profile erstellen und werde aufgefordert eine neue Datenbank zu > erstellen. Ich kann mich auf den Kopf stellen, aber das Serverpasswort > (sollte doch das gleiche sein wie das in der /etc/trytond.conf hinterlegte, > oder?) wird nicht akzeptiert. Ich werde aufgefordert ein neues Passwort > einzugeben, aber das Fenster "Datenbank erstellen" verweigert jeden Dienst. > Ich kann weder irgendeinen Knopf bedienen noch ein neues Passwort eingeben. > Da hilft nur noch ein kill -9 . Du musst vermutlich die Servereinstellungen für die Datenbank konfigurieren. Ohne Kenntnis deines Systems, deiner Einstellungen und der Fehlermeldungen lässt sich hierzu leider nur vermuten... Poste doch einige zusätzliche Infos. -- 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 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "tryton-de" sind. Weitere Optionen: https://groups.google.com/d/optout pgpNyS9nzKDiX.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-de] Installationsprobleme
* Hans Normann: " [tryton-de] Installationsprobleme" (Thu, 12 May 2016 02:21:37 -0700 (PDT)): > Versuche gerade Tryton zum installieren, mit mäßigem Erfolg. Aktuell hänge > ich bein Starten des trytond Deamons. Hier das Startprotokoll > > Mai 12 11:02:37 localhost.localdomain trytond[4576]: [Thu May 12 11:02:37 > 2016] INFO:server:using /etc/trytond.conf as configuration file > Mai 12 11:02:37 localhost.localdomain trytond[4576]: [Thu May 12 11:02:37 > 2016] INFO:server:initialising distributed objects services > Mai 12 11:02:37 localhost.localdomain trytond[4576]: Traceback (most recent > call last): > Mai 12 11:02:37 localhost.localdomain trytond[4576]: File > "/usr/bin/trytond", line 109, in > Mai 12 11:02:37 localhost.localdomain trytond[4576]: > trytond.server.TrytonServer(options).run() > Mai 12 11:02:37 localhost.localdomain trytond[4576]: File > "/usr/lib/python2.7/site-packages/trytond/server.py", line 102, in run > Mai 12 11:02:37 localhost.localdomain trytond[4576]: self.start_servers() > Mai 12 11:02:37 localhost.localdomain trytond[4576]: File > "/usr/lib/python2.7/site-packages/trytond/server.py", line 224, in > start_servers > Mai 12 11:02:37 localhost.localdomain trytond[4576]: CONFIG['ssl_jsonrpc'])) > Mai 12 11:02:37 localhost.localdomain trytond[4576]: File > "/usr/lib/python2.7/site-packages/trytond/protocols/jsonrpc.py", line 359, > in __init__ > Mai 12 11:02:37 localhost.localdomain trytond[4576]: daemon.__init__(self, > interface, port, secure, name='JSONRPCDaemon') > Mai 12 11:02:37 localhost.localdomain trytond[4576]: File > "/usr/lib/python2.7/site-packages/trytond/protocols/common.py", line 32, in > __init__ > Mai 12 11:02:37 localhost.localdomain trytond[4576]: socket.AF_UNSPEC, > socket.SOCK_STREAM): > Mai 12 11:02:37 localhost.localdomain trytond[4576]: socket.gaierror: > [Errno -5] No address associated with hostname > > Wo in aller Welt habe ich den Fehler zu suchen? In der Konfiguration (/etc/trytond.conf) vermutlich. Du verwendest anscheinend eine Version < 3.4. Für diese Version sollte etwas in der Art [options] # Activate the json-rpc protocol jsonrpc = localhost:8000 #ssl_jsonrpc = False eingetragen sein. Viele Grüße, 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: 0x8405BBF6 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "tryton-de" sind. Weitere Optionen: https://groups.google.com/d/optout pgpUeQNdQaiyT.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-de] Rechnungen mit Skonto - Rechnungseingang
* TPH: " [tryton-de] Rechnungen mit Skonto - Rechnungseingang" (Thu, 14 Apr 2016 07:27:53 -0700 (PDT)): > Ich nutze Tryton 3.2 und habe nun angefangen auch alle Eingangsrechnungen > ein zu pflegen. Nun frage ich mich wie ich am besten mit dem Skonto umgehe. > > Beispiel: > Rechnung Gesamtsumme 80,25 EUR > Skonto 3% > Zahlbetrag 77,84 EUR > > Mein bisheriges Vorgehen: > Rechnung mit Gesamtsumme und ohne Skonto eingeben (80,25 EUR). > Rechnung zahlen mit Teilzahlung (77,84 EUR) auf Konto "Bank". > Restbetrag zahlen auf Konto "Skonto" Das kann man im Prinzip so machen, dieses Vorgehen korrigiert m.W. allerdings nicht die USt/VSt. Das müsste separat noch in der Buchhaltung erledigt werden. > Wie geht ihr damit um? Im Prinzip so: https://gitlab.com/m9s/account_invoice_cash_discount gibt es für 3.4, sollte sich aber evtl. mit leichten Anpassungen auch noch für die 3.2 einsetzen lassen. -- 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 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "tryton-de" sind. Weitere Optionen: https://groups.google.com/d/optout pgpgxbZXhMG_E.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton] How to translate
* Sergi Almacellas Abellana: " Re: [tryton] How to translate" (Wed, 30 Mar 2016 21:37:11 +0200): Thanks, Sergi, for your initiative. I will post some minor issues to the review when it is clear, if it will be merged, otherwise it is wasted time. > El 30/03/16 a les 19:05, Cédric Krier ha escrit: > > On 2016-03-30 18:36, Sergi Almacellas Abellana wrote: > >> El 30/03/16 a les 17:58, Cédric Krier ha escrit: > >>> On 2016-03-30 17:33, Sergi Almacellas Abellana wrote: > >>>>> Hi, > >>>>> > >>>>> I just added the how to translate section from the old wiki to the > >>>>> website. So please review the changes here: > >>>>> > >>>>> https://codereview.tryton.org/24091002/ > >>>>> > >>>>> Any comments will be much apreciated. > >>> This process is deprecated, we use Pootle now. > >> That's what i explain in the page. How to translate with pootle. > >> > >> I picked the notes (about pootle) from the old wiki and improved it a > >> little bit. > > > > Indeed I don't think we need any kind of pages. We have a link to the > > pootle server in community page. And people can contact us from Pootle > > to request the language creation. > > But it's not clear that Pootle means translations. I think we should > clarify the translation process, so newcomers can easly contribute on > translations. It is a common wide spread error, that newcomers will provide just about good translations. In my experience those attempts often just put an additional burden on the language maintainer to correct/explain the errors. That doesn't change the fact, that I appreciate your effort to make things more clear. > > About the time frame, I think it is no more accurate, we switched to > > Pootle to allow among others to have continuous translation. > > So maybe we should remove this paragraph and mention the translation > process on the first steps of the contribute page. While of course it is possible to translate continously, finally a consistent translation and all checks make most, if not only sense in the string freeze. So of course the time frames are quite important. > > Also I found that until now (when we still have the wiki) nobody > > followed the procedure and they just asked somewhere on ML or IRC etc. > > So I think it is too much to have a procedure for something that happens > > very rarely. > > I just write it down to have some reference as somebody asked it on the > spanish mailing list, so when asking on the mailing list we can easly > answer with a link to the how to translate (or contribute page). When users are asking on IRC or mailing lists this could also be, because they didn't find intuitively the information. -- 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 -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/20160330234831.532a7254%40privatix.mbehrle.de. pgprHizE1dFjt.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-de] tryton-client, Demo-Zugang antwortet in russischer Sprache
* Helmut Welsch: " Aw: Re: [tryton-de] tryton-client, Demo-Zugang antwortet in russischer Sprache" (Tue, 22 Mar 2016 08:30:17 +0100): Hallo Helmut, prima, dass es geklappt hat! Jetzt hast du allerdings (wahrscheinlich?) den gleichen Fehler wie dein Vorgänger gemacht, indem du den admin Account lokalisiert hast (auf deutsch anstatt Ursprungssprache englisch gesetzt). Das kann man natürlich für die Zeit einer Sitzung machen, sollte aber daran denken, vor dem Logout die Sprache wieder zurückzusetzen auf Englisch. Sonst steht nämlich dein Nachfolger vor dem gleichen Problem wie du. Als prinzipiell lokalisierte Zugänge sind die ja demo_de, demo_xx, ... angelegt. Viele Grüße, Mathias > Hallo Matthias, > vielen Dank für die Hilfe. Ich habs geschafft! Der admin-Zugang war letztlich > das Stichwort. Helmut Welsch. > > Zur Doku/Info: > 1. Mit firefox schliessen und nach Browser Cache löschen konnte ich den > Logout aus dem demo-Zugang in der russischen Oberfläche erreichen. 2. Die > "russische" Login-Maske konnte ich soweit bedienen um den Zugang mit admin > herzustellen. 3. Im admin-Menue sind nicht alle Texte ins russische > übersetzt. So konnte ich Länder lokalisieren. 4. Die Umstellung auf Germany > hat dann auch die Änderung der Oberflächensprache nach Deutsch bewirkt. > Gesendet: Samstag, 19. März 2016 um 00:42 Uhr Von: "Mathias Behrle" > <mbeh...@m9s.biz> An: tryton-de@googlegroups.com > Betreff: Re: [tryton-de] tryton-client, Demo-Zugang antwortet in russischer > Sprache > * Helmut Welsch: " [tryton-de] tryton-client, Demo-Zugang antwortet in > russischer Sprache" (Fri, 18 Mar 2016 12:56:25 -0700 (PDT)): > > > Hallo! > > Ich habe letztes Wochenende den Client installiert. Ich konnte den > > Demo-Zugang herstellen. Oberflächenprache war Englisch. > > Heute Abend habe ich den Zugang wieder hergestellt. Die Oberfläche ist > > jetzt allerdings in Russischer Sprache. Da bin ich verloren! > > Wie kann ich das änderen/zurückstellen? Ohne die Oberfläche zu verstehen! > > (Auf meinem PC läuft Ubuntu 15.10, der Client ist: Tryton 3.6.2) > > Vielen Dank im voraus für Hilfe. > > Helmut. > > > > Das sind andere User, die sich als admin anmelden und die Spracheinstellung > verändern. Am besten als admin anmelden und wieder zurück auf englisch setzen. > > Grüße, > 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: 0x8405BBF6 > > -- > Sie erhalten diese Nachricht, weil Sie in Google Groups ein Thema der Gruppe > "tryton-de" abonniert haben. Weitere Optionen: > https://groups.google.com/d/optout > > -- > Sie erhalten diese Nachricht, weil Sie in Google Groups E-Mails von der > Gruppe "tryton-de" abonniert haben. Weitere Optionen finden Sie unter > https://groups.google.com/d/optout. -- 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 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "tryton-de" sind. Weitere Optionen: https://groups.google.com/d/optout pgpmiYf8R8xKE.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton] Old wiki Tryton content - API connection to Tryton
* Ralf Peschke: " Re: [tryton] Old wiki Tryton content - API connection to Tryton" (Fri, 18 Mar 2016 19:17:02 +0100): > Am 18.03.2016 um 19:08 schrieb Sergi Almacellas Abellana: > > El 18/03/16 a les 19:06, Axel Braun ha escrit: > >> Am Freitag, 18. März 2016, 18:15:28 schrieb Sergi Almacellas Abellana: > >>> El 18/03/16 a les 18:11, Raimon Esteve ha escrit: > >>>> Hello, > >>>> > >>>> Somebody have access to old wiki.tryton.org content before change to > >>>> discuss.tryton.org ? > >>> > >>> You can find all the wiki in this mercurial repo: > >>> > >>> http://hg.tryton.org/deprecated/tryton.wiki > >> > >> This is a set of changesets...how can one get this into a readable > >> form for > >> end-users? > >> > > > > You can clone the repo or click browse in the web interface to see the > > files. Once you see the files, just open it to see it's content. > > > > AFAIK, the source is the only readable form. > >> /Ax > >> > > > > > The format seems to be identical or similar with moinmoin-wiki format. > You could import it there. I exported the wiki to github at https://github.com/mbehrle/tryton/tree/wiki You can read the content directly from https://github.com/mbehrle/tryton/blob/wiki/TableOfContents.md 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: 0x8405BBF6 -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/20160319003955.789c22cf%40privatix.mbehrle.de. pgpR7AO1aIMyY.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-de] SEPA-Lastschriften und -Überweisungen / HBCI
* Jan Grasnick | ag kommunikation: " Re: [tryton-de] SEPA-Lastschriften und -Überweisungen / HBCI" (Wed, 10 Feb 2016 09:43:03 +0100): Hallo Jan und Britta, > Am 09.02.2016 um 22:55 schrieb Britta: > > Hallo, > Hallo Britta, > > > > > ist es mit Tryton möglich, SEPA-Lastschriften und -Überweisungen > > durchzuführen? > > Mir ist im Moment nichts bekannt. Ich benutze für diese Zwecke Hibiscus > [1]. Das geht super, ist Open Source und es wäre extrem aufwendig das > alles in Tryton nachzuprogammieren. In Tryton will man ja eigentlich nur > die Buchungen in seiner Buchhaltung haben - deshalb sehe ich in der > Verwendung eines anderen Bankingprogramms keine Probleme. Die Generierung von SEPA-Dateien ist mit account_payment_sepa möglich (ab Version 3.2). > > Wird HBCI unterstützt? > > Wenn man dann seine Geldgeschäfte in Hibiscus (oder womit auch immer) > erledigt hat, lade ich mit dem Modul account_statement_hbci [2] alle > Kontovorgänge via HBCI in die Buchhaltung von Tryton. Das Modul ist > Beta, wird von mir aber regelmäßig benutzt. Sollten Probleme mit > bestimmten Banken auftreten, fixe ich die natürlich gern und schnell. > Die HBCI-Schnittstelle braucht eine weitere Bibliothek (aqbanking) [3], > die auf dem Tryton-Server installiert werden muss. Die Webpage sieht > etwas schräg aus - aber aqbanking wird von einigen renommierten > Linuxprogrammen verwendet, so das man da auf der sicheren Seite ist > (oder das zumindest hofft :) Wir hatten das ja seinerzeit diskutiert, Jan, das ist natürlich etwas unschön (wenn wahrscheinlich als Workaround auch tauglich wie du berichtest), zwei HBCI-fähige Programme parallel zu verwenden. Hibiscus verfügt selbst über eine SOAP- und XMLPRC-Schnittstelle. Um diese anzusprechen, muss Hibiscus allerdings laufen, vorzugsweise als Payment-Server. Die Umsetzung dieser Schnittstelle ist nach wie vor auf unserer TODO-Liste, allerdings bedingt durch andere Aufgaben momentan nicht hoch priorisiert. Sobald wir diese Schnittstelle realisieren, landet sie wie üblich in unserem GitLab-Portfolio [0]. Bis dahin ist alternativ zu Hibiscus auch der Einsatz von GnuCash möglich, das für HBCI auch auf aqbanking aufsetzt. Dann hat man mit [2] immerhin nur eine Bibliothek im Einsatz. Ein weiterer Vorteil von GnuCash ist, dass es Distributionspakete dafür gibt (also einfacher installierbar sein sollte) und keine schwere JavaVM-Machine benötigt. Viele Grüße, Mathias [0] https://gitlab.com/u/mbehrle [1] http://repos.grasbauer.com/account_statement_hbci [2] http://gnucash.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: 0x8405BBF6 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "tryton-de" sind. Weitere Optionen: https://groups.google.com/d/optout pgpKlBMZBfzU_.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton] RFC: Invoice sequences
* 'Korbinian Preisler' via tryton: " Re: [tryton] RFC: Invoice sequences" (Thu, 7 Jan 2016 14:54:49 +0100): > On 07.01.2016 14:13, Axel Braun wrote: > > Am Donnerstag, 7. Januar 2016, 13:47:57 schrieb Mathias Behrle: > >>>> According to our knowledge this constraint is definitely wrong for > >>>> Germany: > >>>> > >>>> The accounting date has to be > >>>> - the date of the delivery for imputed taxation > >>> I would say, the date of invoice. You dont always have a delivery (service > >>> charges) > >> In case of service you have to indicate the time of supply. Invoices > >> missing those dates are strictly spoken invalid. > > True from a taxation point of view. But your invoice has not to be on the > > last day of the period (or something like this) > > > >> Either you point to a delivery > >> date (e.g. on a delivery note) or you have to explicitely write on the > >> invoice, that the delivery date is the same as the invoice date. > > As we are just in a go-live in Germany, I have asked our expertsthe > > delivery date has no relation to the invoice date. They are completely > > independent. If you think about collective invoices etc that makes sense. > > > > Invoice date is relevant for accounting, taxation and payment terms. > This is not correct. The accounting_date is relevant for the accounting > and for the taxation. The invoice_date is relevant for the payment term. Seconded. -- 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 -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/20160107150330.3384b7f1%40monsterix.mbehrle.de. pgpWz8NWd7z8t.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton] RFC: Invoice sequences
* Cédric Krier: " Re: [tryton] RFC: Invoice sequences" (Thu, 7 Jan 2016 12:53:30 +0100): > On 2016-01-07 12:28, Mathias Behrle wrote: > > * Cédric Krier: " Re: [tryton] RFC: Invoice sequences" (Sat, 26 Dec 2015 > > 15:10:15 +0100): > > > > > On 2015-12-25 22:26, Jordi Esteve (Zikzakmedia) wrote: > > > > El 24/12/15 a les 15:06, Cédric Krier ha escrit: > > > > >Hi, > > > > > > > > > >Following the previous discussions about the invoice sequence and the > > > > >fiscal year, I have started a feature request to improve the situation > > > > >and manage more cases. > > > > > > > > > >https://bugs.tryton.org/issue5205 > > > > > > > > > >Please comment if the proposal could be in conflict with your local > > > > >usage. > > > > > > > > The new proposal (a check when setting the number on an invoice to > > > > ensure that the invoice date not before any invoice dates numbered with > > > > the same sequence) fits well the Spanish law and practice. > > > > > > > > In fact, the Spanish team maintains a module [1] that implements this > > > > idea with some restrictions because the sequence is not yet stored in > > > > invoices. > > > > > > > > https://bitbucket.org/trytonspain/trytond-account_invoice_consecutive > > > > > > I see you also have a check for invoice_date == accounting_date for out > > > invoices. I'm wondering if we should also include this constraint in the > > > base. > > > > According to our knowledge this constraint is definitely wrong for Germany: > > > > The accounting date has to be > > - the date of the delivery for imputed taxation > > But I guess there are some constraint. You can not put a date that is on > a closed fiscal year for example. Or I think it will be very strange to > have an invoice with a date in year Y (with numbering of year Y) and the > accounting date in Y-1. The important date for accounting is the delivery date. The invoice date is a trigger for payment terms. > > - the date of the payment for actual taxation (cash basis accounting) > > I'm not sure we are talking about the same thing. The accounting date of > the invoice can not depend on the payment as it will happen at a > different time. The cash basis accounting is only about tax report. That's what I have found in German forums. Note: I am not an accountant. -- 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 -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/20160107135317.2c890e4b%40monsterix.mbehrle.de. pgpp8yc5GGko5.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton] RFC: Invoice sequences
* 'Korbinian Preisler' via tryton: " Re: [tryton] RFC: Invoice sequences" (Thu, 7 Jan 2016 14:52:54 +0100): > On 07.01.2016 12:53, Cédric Krier wrote: > > On 2016-01-07 12:28, Mathias Behrle wrote: > >> * Cédric Krier: " Re: [tryton] RFC: Invoice sequences" (Sat, 26 Dec 2015 > >> 15:10:15 +0100): > >> > >>> On 2015-12-25 22:26, Jordi Esteve (Zikzakmedia) wrote: > >>>> El 24/12/15 a les 15:06, Cédric Krier ha escrit: > >>>>> Hi, > >>>>> > >>>>> Following the previous discussions about the invoice sequence and the > >>>>> fiscal year, I have started a feature request to improve the situation > >>>>> and manage more cases. > >>>>> > >>>>> https://bugs.tryton.org/issue5205 > >>>>> > >>>>> Please comment if the proposal could be in conflict with your local > >>>>> usage. > >>>> The new proposal (a check when setting the number on an invoice to ensure > >>>> that the invoice date not before any invoice dates numbered with the same > >>>> sequence) fits well the Spanish law and practice. > >>>> > >>>> In fact, the Spanish team maintains a module [1] that implements this > >>>> idea with some restrictions because the sequence is not yet stored in > >>>> invoices. > >>>> > >>>> https://bitbucket.org/trytonspain/trytond-account_invoice_consecutive > >>> I see you also have a check for invoice_date == accounting_date for out > >>> invoices. I'm wondering if we should also include this constraint in the > >>> base. > >> According to our knowledge this constraint is definitely wrong for Germany: > >> > >> The accounting date has to be > >> - the date of the delivery for imputed taxation > > But I guess there are some constraint. You can not put a date that is on > > a closed fiscal year for example. Or I think it will be very strange to > > have an invoice with a date in year Y (with numbering of year Y) and the > > accounting date in Y-1. > Think of this case which is very common if the delivery and the > invoicing is done separately: > > 1. Delivery on 2015-12-30 -> accounting_date = 2015-12-30 > 2. Invoicing on 2016-01-04 -> invoice_date = 2015-01-04 This should be a minor typo? => 2. Invoicing on 2016-01-04 -> invoice_date = 2016-01-04 > In Germany the rules for invoice numbering are not very strict. I did a > quick research but did not find any rule that the invoice number cannot > be from the 2015 sequence in this case. But i would prefer to have it > from the 2016 sequence. So i would say that at least in Germany the > sequence should be selected depending on the invoice date. > -- 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 -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/20160107150447.0fa17bee%40monsterix.mbehrle.de. pgpM9ExOh8U92.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton] RFC: Invoice sequences
* Axel Braun: " Re: [tryton] RFC: Invoice sequences" (Thu, 07 Jan 2016 13:29:57 +0100): > Am Donnerstag, 7. Januar 2016, 12:28:52 schrieb Mathias Behrle: > > * Cédric Krier: " Re: [tryton] RFC: Invoice sequences" (Sat, 26 Dec 2015 > > > > 15:10:15 +0100): > > > On 2015-12-25 22:26, Jordi Esteve (Zikzakmedia) wrote: > > > > El 24/12/15 a les 15:06, Cédric Krier ha escrit: > > > > >Hi, > > > > > > > > > >Following the previous discussions about the invoice sequence and the > > > > >fiscal year, I have started a feature request to improve the situation > > > > >and manage more cases. > > > > > > > > > >https://bugs.tryton.org/issue5205 > > > > > > > > > >Please comment if the proposal could be in conflict with your local > > > > >usage. > > > > > > > > The new proposal (a check when setting the number on an invoice to > > > > ensure > > > > that the invoice date not before any invoice dates numbered with the > > > > same > > > > sequence) fits well the Spanish law and practice. > > > > > > > > In fact, the Spanish team maintains a module [1] that implements this > > > > idea > > > > with some restrictions because the sequence is not yet stored in > > > > invoices. > > > > > > > > https://bitbucket.org/trytonspain/trytond-account_invoice_consecutive > > > > > > I see you also have a check for invoice_date == accounting_date for out > > > invoices. I'm wondering if we should also include this constraint in the > > > base. > > > > According to our knowledge this constraint is definitely wrong for Germany: > > > > The accounting date has to be > > - the date of the delivery for imputed taxation > > I would say, the date of invoice. You dont always have a delivery (service > charges) In case of service you have to indicate the time of supply. Invoices missing those dates are strictly spoken invalid. Either you point to a delivery date (e.g. on a delivery note) or you have to explicitely write on the invoice, that the delivery date is the same as the invoice date. > > - the date of the payment for actual taxation (cash basis accounting) > > OK > > Cheers > Ax > -- 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 -- You received this message because you are subscribed to the Google Groups "tryton" group. To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/20160107134757.76bd9e6d%40monsterix.mbehrle.de. pgpHQo3ZXSBW9.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-de] sao-Installation
* Axel Braun: " [tryton-de] sao-Installation" (Thu, 17 Dec 2015 05:31:34 -0800 (PST)): > Moin, > > hat jemand irgendwo eine Installationsanleitung für sao gefunden? > Im Paket steht nicht wirklich viel, auf der Webseite gar nichtsund ich > schätze wir brauchen ja einen nginx, Apache oder sonstigen, oder? # npm install # grunt wie in der README hat bei mir ab der releasten Version funktioniert. Nein, du brauchst prinzipiell keinen Proxy oder Webserver: der trytond bedient auf demselben Port, der für json konfiguriert ist. Das heißt, folgende Einstellungen sollten in der tryond.conf konfiguriert sein: [json] port = ... data = path_to_sao # Pfad für die Get requests Bissel was steht noch hier: http://www.tryton.org/posts/new-tryton-release-38.html Grüße, 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: 0x8405BBF6 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "tryton-de" sind. Weitere Optionen: https://groups.google.com/d/optout pgpX3AFyuxugN.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-dev] Translation
* 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-de] Tryton Module Testen mit virtualenv, pip, mercurial und hgnested
* TPH: " [tryton-de] Tryton Module Testen mit virtualenv, pip, mercurial und hgnested" (Wed, 9 Sep 2015 10:49:23 -0700 (PDT)): > Hallo, > > habe gerade diese Anleitung entdeckt: > http://www.tryton.org/papers.html - Writing your first module for tryton > <http://downloads.tryton.org/TUL2014/crash-course.pdf>, Nicolas Évrard > > Das wollte ich gleich mal ausprobieren, schauen wie mein Modul mit Tryton > 3.4 läuft. > > Nun habe ich jedoch gleich zu Beginn das Problem, dass ich hgnested nicht > zum laufen bekomme. Evtl. Entdeckt ja hier jemand meinen Fahler oder kann > mir sein vorgehen verraten. > > > Hier mein Vorgehen: > > 1. Virtuelle Umgebung anlegen und in diese wechseln: > virtualenv $HOME/Projekte/Tryton/ModuleMitVenv > source $HOME/Projekte/Tryton/ModuleMitVenv/bin/activate > > > > 2. mercurial und hgnested installieren > pip install mercurial > pip install hgnested > > > echo -e "[extensions]\nhgnested=" >> ~/.hgrc Wie sieht die ~/.hgrc insgesamt aus? Was gibt 'pip freeze' im venv aus? > 3. trytond installieren: > hg nclone http://hg.tryton.org/trytond -b 3.4 > *** failed to import extension hgnested: No module named hgnested > hg: unbekannter Befehl 'nclone' > Mercurial Distributed SCM > > > Kann mir jemand weiterhelfen? > > Danke > -- 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 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "tryton-de" sind. Weitere Optionen: https://groups.google.com/d/optout pgpMeQ0JALl5u.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-de] Tryton Client mit deutscher Übersetzung
* Manfred Rockel: [tryton-de] Tryton Client mit deutscher Übersetzung (Mon, 20 Jul 2015 05:37:49 -0700 (PDT)): Hallo Manfred, ich antworte dir mal in Bezug auf Debian/Ubuntu/...: wahrscheinlich wird er Client nicht mit der richtigen Lokalisierung gestartet. Wie die Lokalisierung deines Terminals konfiguriert ist, siehst du per $ locale -a Rekonfigurieren kannst du sie mit $ sudo dpkg-reconfigure locales Hier sollte auf jeden Fall de_DE.utf8 aus gewählt sein. Die Lokalisierungsdateien für den Client sind unter /usr/share/locale/de_DE/LC_MESSAGES installiert Grüße, Mathias Tryton Client Rev.: Hallo, seit einiger Zeit sind die Bedienelemente des Clients nur noch Englisch. Der linke Menübaum ist Deutsch. Kann mir da jemand weiterhelfen ? Gruss Manfred -- 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 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe tryton-de sind. Weitere Optionen: https://groups.google.com/d/optout pgpNZANjcl3QI.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-dev] Question regarding new translatons in 3.6.1
* 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
* 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-de] caldav, webdav, Calendar keine Einträge
* kitpulap talurs: Re: [tryton-de] caldav, webdav, Calendar keine Einträge (Thu, 25 Jun 2015 07:29:58 -0700 (PDT)): In einer Testreihe, die ich im letzten Jahr durchgeführt habe, war CalDAV-Sync das einzige Programm, das wirklich zuverlässige Ergebnisse auf Android brachte. Zugriffsrechte das wars. Hab ich wohl irgendwie übersehen. Funktioniert die Termin und Kontakt Synchronisation mit DAVdroid eigentlich? Bei mir zeigt er nur die Termine an kann sie aber nicht bearbeiten. In Thunderbird/Lightning/SOGo Connector geht das. Am Donnerstag, 25. Juni 2015 13:14:03 UTC+2 schrieb Mathias Behrle: * kitpulap talurs: [tryton-de] caldav, webdav, Calendar keine Einträge (Thu, 25 Jun 2015 01:17:23 -0700 (PDT)): Hallo, ich benutzte trytond 3.6.1, habe das webdav und das party_vcarddav Modul installiert. Aber die Calendar und Event Einträge werden nicht im Browser (Firefox) angezeigt. Die Contacts aber schon. Habe ich was vergessen? Zugriffsrechte? Debug output: http://pastebin.com/16w23pDF Du scheinst auf die Gesamt-Collection zuzugreifen, hast du die URLs wie in https://code.google.com/p/tryton/wiki/HowtoUsingCalendarsWithCalDAV probiert? Es gab einige Fixes in der letzten Zeit, vielleicht trifft einer für dich zu: https://bugs.tryton.org/issue4786 https://bugs.tryton.org/issue4776 https://bugs.tryton.org/issue4759 https://bugs.tryton.org/issue4670 Grüße, 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: 0x8405BBF6 -- 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 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe tryton-de sind. Weitere Optionen: https://groups.google.com/d/optout pgphIr3If31gJ.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-dev] Confirm date on sales and purchases
* 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
* 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
* 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
* 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: 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
* 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
* 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
* 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
* 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
* 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
[tryton-fr] Handling of returns/cancelations (was: extourne/annulation d'un mouvement)
* Raphael Hertzog: Re: [tryton-fr] Re: extourne/annulation d'un mouvement (Wed, 25 Mar 2015 14:37:06 +0100): I am pulling this discussion of the french mailing list to tryton, because I find it interesting enough for the wide public and I would suspect, that at least in Europe we should have some common or at least similar procedures about the handling of credit notes versus cancellation notes. I have put the research together done by the german community at that time (dating back to 2008) and posted it at https://code.google.com/p/tryton/wiki/CreditNotevsCancelation May be we can find together the most common denominator of this business case. Le mardi 24 mars 2015, Richard PALO a écrit : En effet, avec le Nouveau Plan comptable (1999), une obligation de traçabilité des modifications d'écritures comptables impose l'utilisation des contrepassations d'écritures (voir Mémento Comptable 2015 § 332.3 III Traçabilité. Au delà des règles comptable, la traçabilité est imposée également par l'Administration fiscale qui risquerait de ne pas se satisfaire d'une comptabilité contenant des écritures négatives. Donc, il est impérative d'organiser un aménagement pour tenir une comptabilité légale avec tryton en France. Moi je comprends tout cela bien différemment... « la traçabilité impose l'utilisation des contrepassations d'écritures » ca veut juste dire qu'on ne modifie pas l'écriture d'origine mais qu'on effectue la correction avec une ou plusieurs écritures supplémentaires. Absolutely agreed about tracibility and immutability of posted moves. For german installations we are disabling the button, that allows to change posted moves. Cette question de signe me semble tout à fait anecdotique. L'usage d'un signe négatif pour une contrepassation qui annule totalement la première écriture me semble légitime (pourvu que l'écriture soit documentée comme telle!). As Cédric has pointed out in another mail, the result between annulating a move with negative amounts to the same account (debit/credit) versus positive amounts on the contra account is different. While one will not increase the balance, the other will. Mais je ne suis pas comptable... I am an accountant neither, so happy on further input. -- 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 pgpKDWQ4Kf7v2.pgp Description: Digitale Signatur von OpenPGP
[tryton] Handling of returns/cancelations (was: extourne/annulation d'un mouvement)
* Raphael Hertzog: Re: [tryton-fr] Re: extourne/annulation d'un mouvement (Wed, 25 Mar 2015 14:37:06 +0100): I am pulling this discussion of the french mailing list to tryton, because I find it interesting enough for the wide public and I would suspect, that at least in Europe we should have some common or at least similar procedures about the handling of credit notes versus cancellation notes. I have put the research together done by the german community at that time (dating back to 2008) and posted it at https://code.google.com/p/tryton/wiki/CreditNotevsCancelation May be we can find together the most common denominator of this business case. Le mardi 24 mars 2015, Richard PALO a écrit : En effet, avec le Nouveau Plan comptable (1999), une obligation de traçabilité des modifications d'écritures comptables impose l'utilisation des contrepassations d'écritures (voir Mémento Comptable 2015 § 332.3 III Traçabilité. Au delà des règles comptable, la traçabilité est imposée également par l'Administration fiscale qui risquerait de ne pas se satisfaire d'une comptabilité contenant des écritures négatives. Donc, il est impérative d'organiser un aménagement pour tenir une comptabilité légale avec tryton en France. Moi je comprends tout cela bien différemment... « la traçabilité impose l'utilisation des contrepassations d'écritures » ca veut juste dire qu'on ne modifie pas l'écriture d'origine mais qu'on effectue la correction avec une ou plusieurs écritures supplémentaires. Absolutely agreed about tracibility and immutability of posted moves. For german installations we are disabling the button, that allows to change posted moves. Cette question de signe me semble tout à fait anecdotique. L'usage d'un signe négatif pour une contrepassation qui annule totalement la première écriture me semble légitime (pourvu que l'écriture soit documentée comme telle!). As Cédric has pointed out in another mail, the result between annulating a move with negative amounts to the same account (debit/credit) versus positive amounts on the contra account is different. While one will not increase the balance, the other will. Mais je ne suis pas comptable... I am an accountant neither, so happy on further input. -- 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 pgpCCXMFym_36.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-dev] Client translation
* 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] Posting minor release to tryton-announce@
* Cédric Krier: Re: [tryton] Posting minor release to tryton-announce@ (Wed, 18 Mar 2015 13:09:28 +0100): On 18 Mar 12:34, Mathias Behrle wrote: * Cédric Krier: Re: [tryton] Posting minor release to tryton-announce@ (Wed, 18 Mar 2015 11:45:02 +0100): On 18 Mar 11:08, Mathias Behrle wrote: * Cédric Krier: [tryton] Posting minor release to tryton-announce@ (Tue, 17 Mar 2015 14:58:17 +0100): What do you thing about posting minor version bump of Tryton's packages to tryton-announce@ mailing list? To keep the lists readable I would recommend - to create a separate list tryton-release, otherwise the announce list will be swamped by those release messages Why will it be? There are about 20-30 releases per month with the exception of about 80 the day of the new series. Why should we create one more mailing list for 2 days of flooding per year. Because all those messages will hide more or less currently low traffic news. So you don't want more announce on the tryton-announce@ because it is low traffic and you want to keep it low traffic. Yes, keeping announce lists at low traffic is preferable for me. The value of the single message will be higher and substantial. I doubt, that every minor bump is interesting to the wide public. I think such reflexion will always prevent to do anything. Why? By the way, the traffic is low because we don't have a lot of news contribution but it is not a rule. It will be very welcomed to have more news submitted. BTW. how will this display at http://www.tryton.org/news/index.html? It will not as it is human written news. Until now it is 1:1, which has its advantages. -- 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 pgpFLMj1y_HOH.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton] Posting minor release to tryton-announce@
* Cédric Krier: Re: [tryton] Posting minor release to tryton-announce@ (Wed, 18 Mar 2015 11:45:02 +0100): On 18 Mar 11:08, Mathias Behrle wrote: * Cédric Krier: [tryton] Posting minor release to tryton-announce@ (Tue, 17 Mar 2015 14:58:17 +0100): What do you thing about posting minor version bump of Tryton's packages to tryton-announce@ mailing list? To keep the lists readable I would recommend - to create a separate list tryton-release, otherwise the announce list will be swamped by those release messages Why will it be? There are about 20-30 releases per month with the exception of about 80 the day of the new series. Why should we create one more mailing list for 2 days of flooding per year. Because all those messages will hide more or less currently low traffic news. BTW. how will this display at http://www.tryton.org/news/index.html? -- 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 pgpbj43HcNTEl.pgp Description: Digitale Signatur von OpenPGP
[tryton-contrib] How to handle goods temporarily absent from the warehouse
Hi all, it would be nice to find a generic approach for the following operations in the scope of many companies: - Handing out samples for inspection to the customer for evaluation and evtl. later purchase. - Lending goods to the customer. - Leasing goods to the customer. All operations have in common, that the goods still are property of the warehouse, but physically are at the customers place. The challenge: since those goods are just temporarily unavailable and are expected to come back to the storage zone, they shouldn't trigger any provisioning mechanisms like internal or purchase requests. So for all kind of requests the goods should behave as being in a location of type storage, but without being available for sales. I have setup the following scenario: The stock part: - Defined a location of type storage as a child of the primary storage zone, which shall contain the goods temporarily not available. - This should allow for correct processing of requests, since e.g. generate_internal_shipment is called with_child=True. Note: it currently doesn't behave correctly (3.4), the child locations don't seem to be propagated to the parent location. - The display of the available quantity should then be the storage zone with_childs=False. Note: the display is currently that way, but could also be part of the bug mentioned above. The model part: May be - there could be a model similar to sale, that will generate moves targeting the temporary locations depicted above instead or additional to the customer location - or some asset type like it is done in Nan-tics module pool. Does this sound reasonable? Other ideas? -- 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 pgpbf41Cr5gpo.pgp Description: Digitale Signatur von OpenPGP
[tryton-contrib] Best practices: Layout of stock provision via multiple warehouses
Hi all, I just wanted to get feedback on how to setup the following scenario in the best way. This scenario is a quite common pattern used by a number of companies in the retail sector and could serve probably as a general pattern also for others. The company is sharing (pooling) its storing capacity over - the main warehouse - several stores nearby in the city - additionally a webshop shall be driven with the base of available products computed from the products available in the different warehouses. So the webshop basically is just handled as another store, but without stock (at least in terms of storage). There shall be a precedence on how the goods for the sales of the webshop shall be picked from the different warehouses. Purchases shall only be made from the main warehouse, which serves generally as the central communication point to the suppliers (incoming shipments, returns, etc.). Deliveries to stores and pickings from stores back to the shipping department are usually made twice a day. To represent the above scenario I am currently using the following layout: - The main warehouse as well as the stores are defined as locations of type warehouse. - The supply chain from the main warehouse to the stores is defined by order points of type internal shipment. - The supply chain of the main warehouse is defined by oder points of type purchase request. - The supply chain of the webshop is: just pick the available products from their respective locations (with a defined precedence). This basic setup works out of the box except for: - Internal shipments currently are created additively, not being replaced with the complete numbers of the actual state (like purchase requests). I don't know if this behavior is necessary by design/use case or if it could generally be changed to behave in the same way as purchase requests. - The current handling of internal shipments is not convenient to handle requests, where often only a part of the requested quantity can directly be assigned (e.g. existing stock on the main warehouse), but the remaining quantity has to be assigned later (e.g. when available from the main warehouse in future, after purchase). We will have to find a way, how to automatically assign available stock while waiting for stock to be purchased. At least having to go back to Draft to be able to delete non assignable products is more than unconvenient and probably bothers other users, too. Perhaps we could extend the force assign wizard to ask to split out non assignable products into a new shipment? - The webshop will need a special provision to create internal shipments according to the available stock in the different warehouses. Does this basic setup look ok for you? Thanks for your input, 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: 0x8405BBF6 pgpCzpWrLEGwF.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-dev] Request testing of new sale_opportunity workflow
* 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] Additional sale lines
* Cédric Krier: [tryton] Additional sale lines (Tue, 27 Jan 2015 12:08:27 +0100): Hi, I'm working on a new module for sale that will add automatically new sale lines base on criteria (MatchMixin). I'm first looking for a name before writing a blueprint. I find premium [1] but it is only for free products while this module could be a much more generalize one which could add also non-free products or even extra costs (services). So is anyone have a better name? By the way, it will probably be quite similar to sale_shipment_cost. [1] https://en.wikipedia.org/wiki/Premium_%28marketing%29 sale_line_match sale_line_add_matching -- 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 pgp6lXinn_cHu.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton] Revisiting product's type
* Cédric Krier: Re: [tryton] Revisiting product's type (Fri, 2 Jan 2015 10:49:44 +0100): On 02 Jan 00:20, Albert Cervera i Areny wrote: Currently product's type can be one of: - Assets - Goods - Service However, I don't think it's correct to have the distinction between Assets and Goods/Service. For example, if my company is dedicated to selling cars and I have the product Kia Sportage Emotion I may have it in stock for selling but I may also purchase the car to be used by one of our employees. Yes and they are different things. You can not sale an asset like that and you can not use a goods. In this case, currently we'd need to create two separate products for what it actually is the same product. No it is not the same product. Product in Tryton will depend of its usage. For example, you can have different service products but that are at the end the same thing for example the employee work. I think I understand your conceptional idea, but the result is quite distict from the understanding and needs in everyday business. The average user doesn't want to follow the line of thought, that this very same product in terms of origin, name and all attributes shall be different products with regard to its further usage. Also it is a real shortcoming, if models in software don't meet the usage of objects in the real world. In my understanding the usage of a product shouldn't have any relation or impact on the type of a product. Just another example: A shop for art supplies sells batteries and pencils. For their own use they just take, what they need, from stock. They surely don't want to order the same product as different products from the supplier according to a usage, they even don't know exactly beforehand. They will be unnecessarily impeded by the current design. I think that just like we moved Consumable out of the Type field into a boolean we should do the same with Assets. Add a new check box Asset that when true it would allow to fill in the asset-related accounts. I think the checkbox should always be available (no matter if type is Goods or Service) because a patent is not a good but it is an asset. Patent is not really a problem. Of course you could make a stock move with patent but it is not a big deal. But the main reason we must have 2 different products for asset and product is because they must be distinguished at the stock level and they have a different behaviour on an invoice. Perhaps I don't see the implications, but I don't understand, why this behavior shouldn't be possible without tying it to the type. Could you elaborate a bit more, why a Boolean couldn't serve this purposes? Maybe we should put the type in the rec_name of product to avoid having twice the same name for both types. -- 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 pgpIKbbErrcOa.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton] Revisiting product's type
* Mathias Behrle: Re: [tryton] Revisiting product's type (Fri, 2 Jan 2015 14:25:43 +0100): Could you elaborate a bit more, why a Boolean couldn't serve this purposes? Just thinking a little bit further ;) I realize that a Boolean doesn't change anything. Finally I think, that it shouldn't be necessary at all to define a product as asset , but that a product should just behave like an asset, if it is used as asset. -- 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 pgpR8AAo8icuA.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton] Revisiting product's type
* Albert Cervera i Areny: [tryton] Revisiting product's type (Fri, 2 Jan 2015 00:20:16 +0100): Currently product's type can be one of: - Assets - Goods - Service However, I don't think it's correct to have the distinction between Assets and Goods/Service. For example, if my company is dedicated to selling cars and I have the product Kia Sportage Emotion I may have it in stock for selling but I may also purchase the car to be used by one of our employees. In this case, currently we'd need to create two separate products for what it actually is the same product. Agreed. I think that just like we moved Consumable out of the Type field into a boolean we should do the same with Assets. Add a new check box Asset that when true it would allow to fill in the asset-related accounts. I don't even think, that a new checkbox is needed, because the Boolean 'Depreciable' already exists. I think the checkbox should always be available (no matter if type is Goods or Service) because a patent is not a good but it is an asset. Comments? -- 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 pgp7iYUEvLMEP.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-dev] mercurial-server and roundup
* 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] RfC: maning of new state of stock move
* Cédric Krier: Re: [tryton] RfC: maning of new state of stock move (Fri, 19 Dec 2014 11:56:57 +0100): On 05 Dec 11:57, Mathias Behrle wrote: Hi all, I would like to pull a little bit of your attention to the following issue: For [1] there is coming a new state for stock moves, for which the current proposal [2] is 'None'. My point of view is: there shouldn't be a state of None. As soon as an object has a state, it has one and 'None' is misleading. This is different from selections, where you can can make a selection or not. I proposed several alternatives: 'Preliminary', 'Preparative', 'Provisional', 'Tentative' What would be your prefered name just in case? I propose 'Staging' as refering in https://en.wikipedia.org/wiki/Staging_%28data%29 Yes, even better, sounds good to 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 pgprHYgcJfh1m.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-dev] contributions: approval rules
* 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
* 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
* 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
* 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] RfC: maning of new state of stock move
* Cédric Krier: Re: [tryton] RfC: maning of new state of stock move (Fri, 5 Dec 2014 12:07:54 +0100): On 05 Dec 11:57, Mathias Behrle wrote: Hi all, I would like to pull a little bit of your attention to the following issue: For [1] there is coming a new state for stock moves, for which the current proposal [2] is 'None'. My point of view is: there shouldn't be a state of None. As soon as an object has a state, it has one and 'None' is misleading. This is different from selections, where you can can make a selection or not. I don't understand this thought. state field can only have one of the value of the selection so there is no misleading by naming one of the selection 'None'. A state of 'None' logically is not at all a state , so if choosen the state should disappear from the object. It would be way easier for our users to have a meaningful name instead of a logical clash. A selection is different. Not doing a selection is an empty selection. I proposed several alternatives: 'Preliminary', 'Preparative', 'Provisional', 'Tentative' What would be your prefered name just in case? Cheers, Mathias [1] https://bugs.tryton.org/issue4362 [2] http://codereview.tryton.org/5811002/diff/20001/CHANGELOG#newcode1 -- 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 pgphv026qRm0N.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton] RfC: maning of new state of stock move
* Cédric Krier: Re: [tryton] RfC: maning of new state of stock move (Fri, 5 Dec 2014 13:17:03 +0100): On 05 Dec 12:34, Mathias Behrle wrote: * Cédric Krier: Re: [tryton] RfC: maning of new state of stock move (Fri, 5 Dec 2014 12:07:54 +0100): On 05 Dec 11:57, Mathias Behrle wrote: Hi all, I would like to pull a little bit of your attention to the following issue: For [1] there is coming a new state for stock moves, for which the current proposal [2] is 'None'. My point of view is: there shouldn't be a state of None. As soon as an object has a state, it has one and 'None' is misleading. This is different from selections, where you can can make a selection or not. I don't understand this thought. state field can only have one of the value of the selection so there is no misleading by naming one of the selection 'None'. A state of 'None' logically is not at all a state , For me this is wrong, it is a state. so if choosen the state should disappear from the object. I don't understand. If you choose to set a state to 'None', you could expect to remove it. It would be way easier for our users to have a meaningful name instead of a logical clash. What best meaning that the move has no state because it has a state that does nothing. So give it a meaningful name describing its purpose: 'Preliminary', 'Preparative', 'Provisional', 'Tentative' A selection is different. Not doing a selection is an empty selection. Wrong. This is not how Tryton works. If there is not a selection entry for 'Empty', it is not possible to not select something. It is logic for selections to contain an empty item, if the selection is not required. It is not logic for a state to be not a state, because as soon as something is in a state, it has one, but not none. -- 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 pgp1n44sNO8Ij.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton] RfC: maning of new state of stock move
* Cédric Krier: Re: [tryton] RfC: maning of new state of stock move (Fri, 5 Dec 2014 14:27:08 +0100): On 05 Dec 13:54, Mathias Behrle wrote: * Cédric Krier: Re: [tryton] RfC: maning of new state of stock move (Fri, 5 Dec 2014 13:17:03 +0100): On 05 Dec 12:34, Mathias Behrle wrote: * Cédric Krier: Re: [tryton] RfC: maning of new state of stock move (Fri, 5 Dec 2014 12:07:54 +0100): On 05 Dec 11:57, Mathias Behrle wrote: Hi all, I would like to pull a little bit of your attention to the following issue: For [1] there is coming a new state for stock moves, for which the current proposal [2] is 'None'. My point of view is: there shouldn't be a state of None. As soon as an object has a state, it has one and 'None' is misleading. This is different from selections, where you can can make a selection or not. I don't understand this thought. state field can only have one of the value of the selection so there is no misleading by naming one of the selection 'None'. A state of 'None' logically is not at all a state , For me this is wrong, it is a state. so if choosen the state should disappear from the object. I don't understand. If you choose to set a state to 'None', you could expect to remove it. To remove what? It would be way easier for our users to have a meaningful name instead of a logical clash. What best meaning that the move has no state because it has a state that does nothing. So give it a meaningful name describing its purpose: 'Preliminary', 'Preparative', 'Provisional', 'Tentative' All sounds like for the current 'Draft'. A selection is different. Not doing a selection is an empty selection. Wrong. This is not how Tryton works. If there is not a selection entry for 'Empty', it is not possible to not select something. It is logic for selections to contain an empty item, if the selection is not required. False assumption. It is not logic for a state to be not a state, Who says it is not a state? You. Citing you from [1] | But for me, None is clearly defining what it is. A move with no state. because as soon as something is in a state, it has one, but not none. There is always something in a field. Cédric, I know that we disagree. It doesn't make much sense to me that we both repeat arguments again and again. That's why I just would like to hear from others, how they think about the matter. -- 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 pgpJBlnL9aXdj.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-de] Ungültige GPG-Signaturen
* LAG Robin Baumgartner: Re: [tryton-de] Ungültige GPG-Signaturen (Thu, 27 Nov 2014 08:28:41 +): On 27.11.2014 08:25, Korbinian Preisler wrote: On 27.11.2014 07:47, Jan Grasnick wrote: Am Donnerstag, den 27.11.2014, 07:33 +0100 schrieb Gregor Horvath: Nachdem ich auch keinen Google Account möchte, bin ich ein grosser Anhänger davon, Google durch Besseres zu ersetzen. Find ich gut - Google muss weg. Wie schon auf der TUL 2014 angesprochen, schmeiße ich gerne nochmal discourse[1] als weitere Alternative in den Ring. Das nimmt nicht gerade den Verlauf den ich mir vorgestellt habe. Ich möchte Google Groups nicht vehement verteidigen, aber ich finde wir sollten den selben Dienst wie die englischsprachige Mailingliste nutzen. Wenn schon müsste die Diskussion über Google oder nicht also dort geführt werden. Auch wenn das nicht den Verlauf nimmt, den du dir vorgestellt hast, so finde ich meinerseits den Verlauf in diese Richtung sehr überlegenswert...;) Gründe: - google hat (wie von Gregor schon beschrieben) ein mittlerweile seltsam beliebiges System, gültige Mails abzuweisen. Es kommt hier immer wieder zu Restriktionen, Verzögerungen oder Fehlern, die auch bei guter Spambekämpfung nicht sein müssen. So wird ein und diesselbe Mail vom selben Server eingeliefert mal angenommen, mal abgewiesen. - dass google Gruppenfooter innerhalb von PGP tags einpflegt, spricht nicht gerade für tiefes Verständnis/Rücksichtnahme der Materie. - und letzten Endes bin ich sowieso dafür, US-Server aus denbekannten Gründen zu meiden... Meine eigentliche Frage war allerdings ob dieser Footer-Zusatz in den Listen-Einstellungen abgeschaltet werden kann? Ich glaube so etwas auf der Hilfeseite von Google Groups[1] gesehen zu haben. Ich habe jetzt abgeschaltet: URL der geposteten Nachricht anzeigen Was ich nicht abschalten kann (zwangsweise aktiviert): URL zum Deaktivieren von Google Groups-Nachrichten anzeigen Ansonsten sind sämtliche Footer-Einstellungen deaktiviert. Grüße, 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 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe tryton-de sind. Besuchen Sie https://groups.google.com/d/msgid/tryton-de/20141127113515.01951e91%40monsterix.mbehrle.de, um diese Diskussion im Web anzuzeigen. Weitere Optionen: https://groups.google.com/d/optout pgpRhCB4Q0Qpk.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-de] Re: Tryton DACH
* Gregor Horvath: Re: [tryton-de] Re: Tryton DACH (Wed, 26 Nov 2014 10:04:31 +0100): Am Wed, 26 Nov 2014 09:02:24 +0100 schrieb Jan Grasnick jg...@grasbauer.com: Am Dienstag, den 25.11.2014, 17:47 +0100 schrieb Gregor Horvath: mein Text Freiheit und ERP ist da: http://gregor-horvath.com/freiheit_erp.html Der ist gut - ich muss aber mal kurz ein paar andere Sachen erledigen. Der sollte m.E. etwas gekürzt in einem eigenen Block stehen - schreibst Du das vielleicht? ja mach ich. Ein allgemeines Anliegen zum Wort Open Source hätte ich noch. Ich würde das gerne durch das Wort Frei bzw. Freiheit ersetzen, und Open Source evtl. in Klammer lediglich zur Ergänzung / Klärung hinzufügen. Denn auch SAP ist Open Source, aus Sicht des Kunden. Der ABAP Code steht den Kunden zur Verfügung und darf von ihm verändert werden. Macht das SAP frei? Natürlich nicht. Denn es fehlen die Freiheiten das Programm beliebig zu verwenden, verbessern, verstehen, und zu verteilen. Unser Unterscheidungsmerkmal ist die Freiheit die der Nutzer erhält, nicht die Verfügbarkeit des Codes. Leider ist der schlechte Begriff Open Source als Marke geprägt worden und daher recht bekannt, das macht ihn aber nicht besser. Der Begriff OpenSource ist an und für sich nicht schlecht. Er muss aber, wie du schreibst, mit den entsprechenden Einschränkungen gesehen werden. Ich finde es sehr gut, wenn du dabei den Begriff Freie Software entsprechend ins Spiel bringst - nicht als Gegensatz, sondern als Ergänzung. Ich bin gerade zeitlich wirklich ausgelastet, klinke mich in das Thema nachhaltiger ein so bald wie möglich. Grüße, 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 -- Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe tryton-de sind. Besuchen Sie https://groups.google.com/d/msgid/tryton-de/20141126105518.367761a9%40monsterix.mbehrle.de, um diese Diskussion im Web anzuzeigen. Weitere Optionen: https://groups.google.com/d/optout pgpDjS2Y9Ln4y.pgp Description: Digitale Signatur von OpenPGP
Re: [tryton-dev] Faster contribution
* 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
* 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
* 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
* 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
* 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
* 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] Tryton 3.2 Repository
* Farid Shahy: Re: [tryton] Tryton 3.2 Repository (Tue, 07 Oct 2014 11:36:59 +0330): On 10/07/2014 11:28 AM, Raimon Esteve wrote: 2014-10-07 9:45 GMT+02:00 Farid Shahy fsh...@gmail.com mailto:fsh...@gmail.com: Hi Wanted to get Tryton 3.2 series from repository at http://hg.tryton.org/ but it seems to be the trunk version. I can download it from http://downloads.tryton.org/3.2/ but I prefer to get from repository to be able to update in future. Am I missing something? get 3.2 branch for each module or tryton or trytond. Thanks Raimon I know every module is maintained separately, but where the repository is located? Hi Farid, the branches are all in one repository. To get the branch change to the repository and run hg checkout 3.2 You can find hints in the wiki at https://code.google.com/p/tryton/wiki/InstallationMercurial and subsequent pages. 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] Why not killing company?
* Albert Cervera i Areny: Re: [tryton] Why not killing company? (Mon, 15 Sep 2014 16:08:26 +0200): 2014-09-12 18:29 GMT+02:00 Albert Cervera i Areny alb...@nan-tic.com: 2014-09-11 12:37 GMT+02:00 Cédric Krier cedric.kr...@b2ck.com: Hi, Following my attempt to improve the situation of multi-company [1], I faced so much problem that I only see to solution: - a very complicate one where many things will become a list per company. For example on product, the prices, the accounts etc. This will make the code very complicate but also the user interface. - a very simple, drop company. I start thinking that the last one is the right move even if it will prevent none single company database to migrate. What are the use case of multi-company? - accounting consolidation It is a reporting issue that should be fixed by BI - sharing party That's a good one if you forget that parties have many properties directly linked to the company like the accounts, tax rules etc. And I think this can be acheived by using a synchronisation of the common data using for example the CardDAV or any other similar protocol. - sharing product Quite similar to party expect that it has much more company related properties. So again it could be implemented using a synchronisation mechanism. I know there are product description message in EDI, so it could be a way. I don't see any other cases. So when I imagine the simplification of removing the company, I really think it deserve the annoyance of breaking the migration. And for such cases, a way to go could be to duplicate the DB and drop on each the other the companies. I think the proposed simplification provides nice of advantages when developing new modules and part of trytond including completely removing fields.Property without the need of a replacement, performance and what you mentioned in another e-mail about group management. Also one thing that I like about removing company so other people can understand the benefits is one there's a multi-company situation where those companies have really different needs. Say one needs GNU/Health and the other one needs to manage production. Nobody would put those two setups in the same database. My main concern is that data synchronization is not really a simple thing to do, do it right and efficiently. Not to mention that it is not exactly the same as sharing the same database. For example, conflicts when writing on the same record database are managed by comparing the two records just when the user is updating them. That minimizes the conflict probability. In fact, the number of conflicts and complexity to manage them increases when you update asynchronously. For example, sharing products is not just sharing the product but also the categories which can have parents and thus the order of sending and updating data is not so simple. Specially because you can have cyclic references if a user changed data in the remote system. Category is just an example of a field that we find in core modules, but if we think Tryton as a framework we should probably take care of making a reasonably extensible solution for which we can provide standard solutions to this kind of problems. Regarding other data apart from party and product (and their related information), there can be other information that is interesting to be shared between companies when we move out of tryton core. For example, the templates in quality_control module and I'm pretty sure there can be others. I'm not suggesting Tryton should solve them out of the box but again maybe we should try to think well what should be the mechanism of syncronizing that information because that is non-trivial. In case others are interested, SymmetricDS [1] seems it could be a good solution for data synchronization for companies that need sharing a lot of information such as: product categories, accounts, etc. [1] http://www.symmetricds.org/ Thanks for sharing, Albert, interesting approach. Will have a closer look and come back. Java...:(...;). -- 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
* 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
* 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
* 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
* 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
* 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] admin user vs user with all access permissions
* Dale Scott: [tryton] admin user vs user with all access permissions (Wed, 23 Jul 2014 16:26:35 -0700 (PDT)): Does a user created with all access permissions have the same abilities as the default admin user? I created a ~100 new users by importing from csv, gave all permissions to one of them, logged in as that user to create a new user manually, and wasn't able to login as that manually created user. I then logged in as admin, deleted the new user, re-created the new user manually, and then could login as that user. Did those users have a company assigned? However, after manually creating the user I didn't try logging in immediately. Is anything that prevents a new user from logging in immediately? (I'm wondering if that was my real problem the first time). -- 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] How does Dashboard Module work?
* Paul Leverett: [tryton] How does Dashboard Module work? (Mon, 21 Jul 2014 09:43:15 -0700 (PDT)): I have installed Dashboard module (v 3.0.0) but cannot see what it does or how to use it. I cannot find any documentation on this module. Have a look at the user preferences. There you have to define actions, that shall be shown on the dashboard. All I get is a Reload icon; I cannot create a new record in Dashboard. The dashboard is readonly for the models it shows. -- 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] Configurable rounding strategy
* Dominique Chabord: Re: [tryton] Configurable rounding strategy (Thu, 17 Jul 2014 08:51:45 +0200): [...] - will cost too much to read each time Then replace the database by a big config file, and you will be fast ;-) Out of curiosity, why do you need to read each time from the database and one time from the config file ? Because configuration is by definition static. Data in the database are not. I'm getting lost here. All xml data is static too, isn't it ? And configuration is mainly there to fit the environement, pots, protocols and so on. +1 I already shared the opinion, that company related data should be in the database. If we put such data in the conf file, we will have a great mixture of some configuration items in the database and others in the conf file. -- 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] party field on account line
* Cédric Krier: Re: [tryton] party field on account line (Mon, 7 Jul 2014 17:50:29 +0200): On 07 Jul 16:12, Nicolas Évrard wrote: Hello, In issue 3731 [1] we are discussing about the meaning of the party field on the account move lines. It seems that the consensus is that this field should be used as some kind of sub-account categorization. Following this consensus I implemented the review 14341002 [2]. This review adds on the account definition a boolean to specify if the account use the party field for sub-accounting. But while implementing it we realized that all the accounts with the boolean set would be receivable / payable accounts. So we're considering using this information instead of the new boolean. Does anybody have any additional information such as: - there are some other kind of accounts where the party sub-accounting can be used - not every receivable/payable account entries must have a party linked to them. This could be the case if accountant create such account for a specific party. I'm wondering if it is wise to enforce the party to be empty if the required boolean is not set. My concern are about performence because it requires to test such property in many places of the code instead of not care and always set it because any way the field will be invisible. I also don't see any advantage in forcing the field to be empty, when it is not required. The Boolean can be used as constraint or domain and should be 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
