As new year resolution, we plan to make a monthly post about what happened in the Tryton project.
The annual Tryton Unconference 2017 took place from the 7th to 10th December at Liège. It started with 2 days of talks and finished with 2 days of code sprint. We also celebrated the 10th anniversary of the project with some drinks and cakes. For those who could not attend, the talks have been registered and the video and slides are available here (note: a technical issue prevented to correctly record the sound the first day but it is still watchable). Some pictures of the events have also been published.
The desktop client is supporting since one year both version of GTK+ 2 and 3. It is now time to have only GTK+-3 and thus be able to use new features of this version. The build environment for Windows and Mac has been updated to produce builds with the new version of the library.
A discussion started at the #TUL2017 to have longer term release for Tryton. A new process has been discussed which has a majority of positive feedback. So the series ending by 0 (like 5.0) will be supported for 5 years and the others for 1 year. We will keep the rate of one release every 6 month. The new schema will start with the series 5.0 which will be released the 1st October 2018.
At the #TUL2017, we discussed about when to drop the support for Python 2 for which upstream support ends in 2020. So we must ensure to stop supporting Python 2 for any series that should still be supported in 2020. The result is that 5.0 will be the first release with only Python 3 support for the server side and also for the desktop client.
The description of order lines (sale, purchase, invoice etc.) are no more filled automatically. This prevent to duplicate the content from the product form to each lines. But also simplify and speedup the creation of a line from the code. Moreover the product supplier information can be stored on the purchase line. This information can be used on the purchase line instead of the product information. It allows to search per supplier references and to display on the report as description for the line, the reference of the product from the supplier.
This new module allows to create coupon that are used to apply a promotion on the sale. The coupon can be configured to be usable only a specific number of times globally or per party.
For PYSON domain, the ORM have the simple strategy to validate records to group them per evaluated domain and then make a search per domain. But it is not optimal when evaluated domains are likely to be unique per record because this generate a search per record. A new case has been added to handle this which searches by grouping multiple domains at once and thus reduce the number of queries.
Until now, dialog were created with a smaller size than the parent window. But it had the disadvantage to create quickly too small dialog windows. So this behaviour has been changed to use always the same size as the parent.
The Tryton design for currency rate is a table with the rate and a date from which the rate applies until another row is added for the currency with a later date. A new method has been added Currency.currency_rate_sql which returns a SQL query that produces for each currency the rate, start_date and end_date. This is useful to get a currency rate in a larger SQL query. This method uses the window functions if available on the database back-end to produce optimized query.
Tryton allows to work with standalone lines instead of pre-generated document to follow the grouping method of external sources. But this requires to have enough origin information to select them. So to improve the workflow the supplier stock moves show the purchase order and the invoice lines show their origin.
Some users have the workflow to reconcile the lines of the statement they just validated. For this we added a button on statement to launch the reconciliation wizard for the generated account move lines.
The company m-ds has joined the [list of companies providing services](/services.html) on Tryton.
The work has started to provide to the desktop client notification for bug-fix releases. It is important because the desktop client is the only part of the Tryton suite for which the update needs to be managed by the user. And we often see users not updating it and reporting issues which have already been fixed.
An external backend with support of geographic fields is under review. It will support only PostGIS in a first time but maybe SpatiaLite will be added in the future. The backend adds all the standard geometry type of columns and supports the operator = and != in the domain. More operations can be added by using python-sql.
The first day, 7th December 2017, is dedicated to business oriented talks.
The second day, 8th December 2017, is focused on developer talks.
And don't forget to spread the word! #TUL2017
The 2017 foundation board renewal process has finished. We are happy to anounce that the new board is composed by:
- Axel Braun from Germany
- Jonathan Levy from the United States of America
- Korbinian Preisler from Germany
- Nicolas Évrard from Belgium
- Pedro Luciano Rossi from Argentina
- Sebastián Marró from Argentina
- Sergi Almacellas Abellana from Spain
Congratulations to Nicolas Évrard as he became the second president of the Tryton foundation board.
In order to easy the adoption of Tryton, we are publishing Docker images images on the Docker hub for all series starting from 4.4.
They contain the server, the web client and all modules of the series. They are periodically updated and tagged per series. They work with the postgres images as default storage back-end.
The usage is pretty simple:
$ docker run --name postgres -e POSTGRES_DB=tryton -d postgres $ docker run --link postgres:postgres -it tryton/tryton trytond-admin -d tryton --all $ docker run --name tryton -p 8000:8000 --link postgres:postgres -d tryton/tryton
Then you can connect using: http://localhost:8000/
We are proud to announce the 4.6 release of Tryton.
This release is enhanced by the addition of 9 new modules covering many different topics. There has been also an effort in improving the graphical user interface and the user experience by fixing many small details. It is also good to note the inclusion of the Spanish charts of accounts which required some improvements in the standard accounting modules. Of course it includes many bug fixes and performance improvements.
As usual the migration from previous series is fully supported. Some manual operation may be required, see migration from 4.4 to 4.6.
In addition to the user name, company and currency in the title of the clients, we have added the profile or the login details. This way, the user can find faster the right windows.
The order of the toolbar has been reworked to have a more logical order and grouping. The same logical has been applied also on the toolbars of the widgets.
On previous version, the headers of the column were always centered. Now they use the same alignment as the content following the best practice. Texts columns aligned on left and numerical columns on right. Also to improve the discoverability, editable lists have a grid design instead of just stripped row. This allows the user to know directly if it is editable.
Similar to the redesign of the button on relation field in the release 4.2, this release improves the design of the Binary and Image widget. Only the available buttons are shown instead of being disabled. But also before having the option to upload a new file, the previous file must be cleared. This prevents confusion to some users.
A new wizard has been added to renew the fiscal year. It takes the previous fiscal year and some other parameters to create the new fiscal year automatically. The sequences can be reset automatically and the same number of periods are created.
On some countries, it is required to add a legal notice when some taxes are applied. This legal notice can now be configured on the tax to be included automatically and so avoid mistakes or oversights.
The tax rule system is the way Tryton configure the taxes to apply on an invoice for a party. This works by replacing the default tax by the one defined on the matching rule. Now it is possible to configure the rule to keep the default tax and add the rule one. It is needed to support tax mechanism from some countries like the equivalence surcharge for Spanish VAT.
The tax description which appear on the invoice is now translatable.
The payable and receivable accounts on party are no more required. This prevented the creation of parties when no default values was setup even if the values were not needed. Now, a message will be raised only when the value is needed for a particular operation.
It is now possible to search the amounts of the general legder. It is useful for example to get only the accounts with a balance.
The general ledger and the income statement can be computed for a range of date in addition to the sets of periods.
The configuration wizard allows to configure default receivable and payable accounts for categories and products.
This is a new module that aims to implement common accounting requirements in Europe. The first common feature added is the EC sales list.
A new module registers two default charts of account and taxes for Spain:
The clearing of payments only worked when paying a specific line. Now it can also work if an account is defined instead of a line. The common case is when you register a deposit for which you have no line but still want to register it once the payment is succeeded.
The manage of payment with Stripe received many improvements:
- The user can now create manually Stripe payments. Usage showed that it may be needed and there was indeed no technical reason to prevent.
- It is possible to select the specific Source of the Customer.
- It is now possible to enter an existing Customer by filling its ID.
- Tryton supports now the two steps payment flows. It is just checkbox to uncheck to activate on this flow. The amount can be changed between the authorisation and the capture and the capture is just triggered by a button.
This new module allows to define for a dunning procedure level to send an email to the party. The template of the email can be different at each level. The action of sending an email is logged into the system.
This new module allows to manage consignment stock from supplier in the company warehouse and at the customer warehouse. The corresponding invoices are created automatically when products are used from such location.
This new module allows to define some storage location as movable. They can be moved by an internal shipment. This can be used for example to manage palettes.
This new module allows to register payments on sale before the creation of any invoice. When the payments for full amount of the sale are authorized, the sale is automatically confirmed. For example, this module is used to manage payment from a e-commerce website.
This new module adds under and over shipment tolerance on the sale. If the quantity of a sale line is under shipped but inside the tolerance percentage, then the line will be considered as fully shipped and no back-order will be created. If the quantity of a sale line is over shipped more than the tolerance percentage, then a warning is raised.
This new module adds the generic feature to send email to parties or users of document based on trigger conditions. The email can embed as attachment any report of the document. A common usage for this module is to send automatically the invoice to the customer when it is posted.
From the 7th to 10th of December, the annual Tryton Unconference will come back to its birthplace: Liège. The conference happens later than usual to occur during the 10th anniversary of the first commit.
This will be the seventh edition. Users, developers and interested people will have the opportunity to discover or talk about Tryton.
The two first days will be the proper unconference. A first part will be dedicated to business oriented talks and a second part focused on developer talks. Talks can be submitted at firstname.lastname@example.org.
Informations and registration are available at https://tul2017.tryton.org/.
If you want to request a talk on a specific topic, you can send your request to the Tryton mailing list. If you have question about the organisation, please contact the foundation at email@example.com.
And don't forget to spread the word! #TUL2017
The 10th December 2017 we will celebrate the 10th anniversary of the first commit in the Tryton source code repository.
That is an important milestone for the project and to celebrate it, the Tryton Foundation is pleased to announce that this year's Tryton Unconference will be held in Liège, Belgium. The city were Tryton was born 10 years ago.
Although the exact dates of the unconference are yet to be defined, organizers will make them match the anniversary. So it's time you make room in your schedule to ensure you don't miss this exceptional event.
As always, expect experts from all over the world to share their knowledge and on the field experience on the development and usage of Tryton.
See you there!
It is already 5 years that our current board is running the Foundation. It is time to renew it! The current board has to co-opt new directors based on candidatures. The candidates must apply here before the 30th September 2017.
The Foundation needs to be founded to pursue its missions, so do not forget to checkout our budget for 2017.
We are proud to announce the 4.4 release of Tryton.
This release see many work to make Tryton even more customizable by reusing or improving common design patterns of existing modules, but still continues to extend the features with new modules. There is also a good effort in improving the security of the application. It contains also many bug fixes and performance improvements.
This release see the removal of the set of DAV modules (webdav, calendar, party_vcarddav etc.). Those modules were based on the no more maintained PyWebDAV library and they did not support Python 3. The side effect is that now the full server stack is Python 3 compatible.
Of course the migration from previous series is fully supported. Some manual operation may be required, see migration from 4.2 to 4.4.
This new module allow to correct the price of a posted invoice line. It adds a new wizard which allow the user to select the line to correct and create a new invoice with for each line two opposite ones. This way the user can change the price of the positive line and keep the statistics and the anglo-saxon accounting correct.
This new module adds the support of Stripe as receivable payment method. The module support many Stripe accounts, one per payment journal. It provides checkout method via browser form for payment or to register a party as Stripe customer. The processing of the payment is done asynchronously by a cron task.
This new module adds a start and end date to the price list lines like that the price list change can be planned in advance. There is a relate from the price list to open the lines like that the user can use the filter.
This new module defines the basics to support subscription of recurring services. And periodically invoice them based on consumption created recurrence rules.
This new module allows to manage advance payment on the sale. An advance payment term can be linked to a sale which will create advance invoices when it is processed. The payment of those advance payments can condition the execution of the supply and the shipping of the sale. The amount of each invoice is computed using a formula based the sale amount.
This new module adds the computation of the weight and volume of the shipments and packages. This is a central place where this computation can be shared between different modules.
The Property fields have been removed in favor of the MultiValue based on the MultiValueMixin and ValueMixin. The Property fields were used mainly to provide multi-company capabilities but the API is based on context attribute only which makes them very difficult to use without having record rules to ensure not mixing between company. The new API allows to get values without using context and this will allow us to remove the multi-company record rule in future release.
The col attribute in the view can have a negative value to create an infinite number of column. This is very useful for group that are designed to get an undetermined number of field.
A new domain has been added to the window action. This domain evaluation is reevaluated when the context is changed. This creates more dynamic windows.
All the domain computation can be override by a method domain_<field name> on the Model with until now the exception of the Function fields. This makes the API more coherent and allow to create more performant SQL query for Function fields by using for example joins.
Two new capabilities check methods have been added to the Database back-end:
A better independence between the fields and the backend has been implemented in this version. This allow external modules to define new kind of fields. For example, a set of GIS fields is under development based on those improvements.
The order definition for a column support the extra keywords for ordering null values. The available keywords are: NULLS FIRST and NULLS LAST. For SQL back-end that does not support the keywords, the order is converted into an equivalent SQL query thanks to python-sql.
The Many2One fields on ModelSQL can now target just ModelStorage. Tryton will not try to create a foreign key constraint on the table in that case.
A new filter attribute has been added to all xxx2Many fields. This filter is used to limit the records returned by the getter of the fields. So it is like domain but without being a constraint for the setter. This allows to replace some Function into plain fields. This review still needs to be done for all modules.
The cache management is automatically done now in the Transaction. This allows to ensure the consistency and integrity of the cache but also ease the usage of trytond in Python script.
A new security measure against brute force attack on the login has been implemented. A new max_attempt parameter in the configuration determine the number of attempt before the server answers unconditionally Too Many Requests for new login attempts. This lasts for the timeout period.
Some constraints have been added to the user password to enforce good security practice. Those constraints are:
- a configurable minimal length which is 8 by default.
- a list of forbidden password. This list is stored into a file defined in the configuration. By default there is no list but it is useful for example to forbid the name of the company etc.
- a minimal ratio of non repeated characters.
- the password must be different of the login, email and name of the user.