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.
The CVE-2017-0360 allows an authenticated user with write access to report or icon definition to make the server open any readable file under any sibling folder of the trytond installation but only if starts with trytond (for example: ../trytond_suffix). This is a remaining case from CVE-2016-1242
The sibling folder starting with trytond could be renamed.
All users should upgrade trytond to the latest version.
Affected versions per series: <=3.4.16, <=3.6.14, <=3.8.10, <=4.0.7 and <=4.2.2
Non affected versions per series: >=3.4.17, >=3.6.15, >=3.8.11, >=4.0.8 and >=4.2.3
Any security concerns should be reported on the bug-tracker at https://bugs.tryton.org/ with the type security.