Tryton Release 4.4

News
1

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

Major changes for the user

  • The URL entry that was set at the button of every tab has been replaced by a button on the toolbar. The button allow to display the URL and copy it to the clipboard. This allow to have more vertical space in the client for the lists and the forms.

  • A common need, when user customize the report template from the client, is to encode the new translations. This is now very easy thanks to the addition of two actions on the report to set and synchronize the translations. A new relate button allows to open the list of all translations linked to the report. The same feature is also available for the views.

  • The desktop client used until now the security model Trust On First Use. But today with the raise of service like Let’s Encrypt, it is very easy and cheap to have a valid SSL certificate but such certificate are renewed very often. So it was no more practical to use TOFU model so the client now validate the certificate of the server using CA of the system or the one configured. The fingerprint of the server is still used as check to prevent to fallback to a plain HTTP connection.

Accounting

  • The period and the fiscal year can be locked definitively. It was already possible to close them to prevent to post anything on them but it was always possible to re-open them. Some countries (like French) has a requirement to have a mechanism that can not be re-open. This is why we have added the lock.

  • The invoice sequences have been simplified. They now use a list of extensible criteria to choose which sequence to use for an invoice. This design is very flexible and allow to implement the country specific requirements very easily.

  • It is now possible to mark a supplier has having direct debit access. In this case its payable lines will not be shown in the list of lines to pay. This prevents to pay them by mistake while the supplier will issue a direct debit.

  • Often a company has only one payment journal. In this case now it will be directly filled in the payment wizard.

  • To ease the task of reviewing the account entries, the statements put the line number and description in respectively move and line description.

  • The analytic accounting has now a rule engine. It allows to apply rules when posting accounting moves without any analytics. The rules can be based on the account, the journal and the party, but of course as usual, those criteria can be easily extended.

account_invoice_correction

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.

account_payment_stripe

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.

Commission

  • It is now possible to use product category as criteria to match a commission plan.

Product

  • The price list has now a new criteria based on the category. It matches products that are linked to the category (standard or accounting).

product_price_list_dates

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.

Production

  • A new producible checkbox is added to the product. This allow to restrict the product that can have a BOM.

Purchase

  • The purchase price is now displayed on the product search list from the purchase line.

  • It is now possible to edit the delivery date of a purchase line. The computation from the supplier lead time is not always possible, but often the supplier can provide an accurate delivery date. So it is good for the supply planning to have a good accuracy of the planned deliver dates.

  • It is now possible to see the requests from which a purchase line was created. This gives more information to the purchaser in case he has to negotiate the quantity for example.

Sale

  • The sale price is now displayed on the product search list from the sale line. This allow the salesman to discuss the prices of similar product with the customer.

  • It is allowed now to leave the lead time of a product empty. There are cases where a company can not define a lead time for selling a product. Then the generated stock move will not have any planned date.

sale_subscription

This new module defines the basics to support subscription of recurring services. And periodically invoice them based on consumption created recurrence rules.

sale_advance_payment

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.

Stock

  • The shipments now record the employee responsible for some states. For example the employee who received the supplier shipment; the employee who picked and packed the customer shipment etc.

  • The internal shipment has now a request state. This allows to have similar design as for production by creating request long time in advance and recompute them as far as they stay in request state.

  • The customer shipment can have the same picking/storage location and output location. This allows to support more warehouse workflow. For example, using grouped internal shipment for the picking, this is often known as wave picking.

  • If an order point exists for a specific type (purchase, production etc.) this disable the other supply methods.

  • The internal shipments are now generated recursively because creating an internal shipment can generate a new need of another internal shipment. Now the generation is looping as long as it is needed.

  • All the different wizards that created supply records for each type have been merged into a single wizard. This allow to ensure that all supply records are created at once, leaving the system in a coherent state.

  • The order point has now a maximum quantity. If this quantity is reached by the location then the extra quantity will be shipped to the defined overflowing location.

  • Just like there is a warning on the supply wizard for late supplier moves, there is also now a warning for late customer moves. By default Tryton consider that customer moves not performed on time, will not be done and so they are no more supplied. This warning ensure the user will take care of those late moves by canceling or replanning them before computing the stock supply.

stock_shipment_measurements

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.

Major changes for the developer

  • 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:

    • has_select_for which allows to use the SELECT ... FOR to lock specific rows instead of the all table.
    • has_window_functions which allows to use the SQL window functions.

  • 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 fields define now which methods should be configured for RPC.

    • A generic SQL type is defined by the fields and it is on the back-end responsibility to convert into its specific version.

  • 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.

Product

  • New methods ceil and floor have been added to the Unit of Measure. They have the same API as round.

Production

  • For better accuracy of production quantities, the input quantities are ceil and the output quantities are floored. This reflect better the really than rounding the quantities.

Stock

  • The default product location uses the MatchMixin pattern now. This makes it easier to extend with new criteria.

  • The computation of the maximum lead time has been improved to be more accurate by summing all the lead times to get the biggest path possible. It also adds extra lead times like the biggest supplier lead time.