New Tryton release 4.8
Publié: 2018-04-23 18:00:00+00:00
Read in English
Llegeix-ho en català
Auf Deutsch lesen
Beri v slovenščini
Leer en español
| Plus d'articles sur
We are proud to announce the 4.8 release of Tryton.
This is the last release that will support Python2, as decided on the last
Tryton Unconference, next versions will be only Python3 compatible.
In this way we introduced a new way of dynamic reporting. For now it's only
available on sale module, but the plan is to extend it to more modules in newer
releases. The effort to make all the Desktop client features available on the
Web client has continued on this release. This resulted in fixing many small
details and adding some missing features on the web client. Of course this
release also includes many bug fixes and performance improvements. We added
Persian as an official language for Tryton.
As usual the migration from previous series is fully supported. Some manual
operation may be required, see migration from 4.6 to 4.8.
Major changes for the user
- The clients show a toggle button next to the search input for all models that
can be deactivated. This allows the user to search for deactivated records
and to know that the model is deactivable.
- Until now, when changes on a record from a pop-up window were cancelled, the
client resets it using the stored value from the server or deletes it if it
was not yet stored. Now, the clients will restore the record to the state it
had before opening the pop-up, which is a more expected behaviour for the
- It's no longer possible to expand a node that has too much records. This is
needed to prevent to consume all the resources of the client. In such case
the client will switch to the form view where normally the children will
be displayed in a list view which supports loading records on the fly when
- To help companies to be compliant with the right to erasure
from the GDPR, a new
wizard to erase a party has been developed. It erases personal information
linked to the party like the name, addresses, contact mechanisms etc. It
removes also those data from the history tables. Each module adds checks
to prevent erasure if pending documents for the party still exist.
- A name has been added to the contact mechanism. It can be used for example
to indicate the name of the recipient of an email address or to distinguish
between the phone number of reception, accounting and warehouse.
- The default search on party will now also use contact mechanism values.
- Similar to the design of the addresses which can be flagged for invoice or
delivery usage, the contact mechanism received the same feature. So the
code may now request a contact mechanism of a specific type. For example, it
is now possible to define which email address of a party should be used to
send the invoices.
- All the matching criteria against product categories have been unified
between all the modules. Any product category will match against itself or
any parent category. This is the chosen behavior because it is the least
- The desktop client already has mnemonic for all button but now they are also
added to all field labels. This allow to jump quickly to any visible field
by pressing ALT + <the underlined key>.
- The desktop client has a new option to check if a new bug fix version has
been published. It takes care of the notification on Windows and MacOS.
- The Many2One fields in editable tree now show the icons to open the related
record or clear the selection. This unifies the behaviour with the form
- Numeric values are now formatted with the user locale and use an input of
type 'number' for editing. This allows to have the right virtual keyboard on
- The web client finally receives the label that positions the selected record
in the list and shows the number of records in the list.
- The spell checking is now activated by the browser, so fields with the
spell attribute defined will have spell checking activated.
- The buttons of widgets are now skipped from tab navigation in the web client.
The actions of those buttons are available via keyboard shortcuts.
- The management of editable list/tree has been completely reworked. Now the
full row becomes editable on the first click. The focus is kept on the line
if it is not valid. The editing is stopped when the user clicks anywhere
outside the view.
- The sum list feature has been implemented in sao.
- The same shortcuts of the Date and DateTime widgets available on tryton can
now be used on web client.
- Many2One fields are displayed on tree view as clickable link which opens
the related record form view to allow quick edition.
We have pushed many small improvements which fix small jump of elements of the
- The general ledger accounts are now opened from the Income Statement rows.
This allows to see the details of the computed amounts.
- It happens that users need to customize the configuration of the chart of
account that comes from a template. Until now, this would prevent any further
update without loosing this customization. Now, the records that are
synchronized with a template are read-only by default. A check box allows
to edit the value and thus remove the record from the update process.
- Users may create a second chart of account by mistake. There are very rare
cases when such creation is valid. As it is a complex task to correct such
mistake, we added a warning when creating a second chart of account.
- Now an error is raised when closing a period if there are still asset lines
running for it.
- Until now, only one tax code was allowed per tax. This was too restrictive.
For some country it was needed to create null children taxes to allow more
complex reporting. Now, tax codes are no longer defined on the tax but
instead they contain a list of tax lines. Those lines can define the base or
the tax amount. On the report, the lines of each tax code are summed per
period. All chart of accounts have been updated to follow this design.
Tax report on cash basis
The new account_tax_cash module allows to report taxes based on cash. The
groups of taxes to report on cash basis are defined on the Fiscal Year or
Period. But they can also be defined on the invoices per supplier.
The implementation of this new module also improved existing modules. The tax
lines of closed period are verified against modification. The registration of
payment on the invoice is limited to the amount of the invoice.
Spanish chart of account
The module, which was published for the first time in the last series 4.6,
needs a deep cleaning. The last changes in the accounting modules raised
concerns about choices made for this chart. So it was decided to
temporary exclude the module from the release process and to not guarantee a
migration path. The work to fix the module has started and we expect to be
able to release a fixed version soon.
- The description on invoice line is now optional. If a product is set the
invoice report will show the product name instead of the line
- The reconciliation date is now shown on the invoice instead of the Boolean
reconciled. This provides more information for a single field.
- The Move lines now show which invoice they pay.
- An error is raised when trying to overpay an invoice.
A cron task has been added that will post automatically the clearing moves
after a delay. The delay is configured on the payment journal.
- If the customer disputes the payment, a
dispute status will be update on the Tryton payment. When the dispute is
closed, the payment is updated according if the company wins or loses.
- Some missing charge events has been added. In particular, the refund event
which may update the payment amount when it is partial.
This new module adds the automatic import of OFX
file as statement. The OFX format is a common format which is supported in
various countries, like the United States.
- The stock quantity was only computed per product because it is the column
stored in the stock move. But it may be useful for some cases to compute the
stock quantity per template. Indeed products from the same template share the
same default unit of measure so their quantities can be summed.
This release adds on the products_by_location method the possibility to
group by product columns like the template, but also a relate action from the
template which show quantity per locations.
- When there is a very large number of locations, the tree Locations Quantity
becomes difficult to use. Especially if you are searching in which location a
product is. So we added the option to open this view as a list, this way it
is possible to search location by quantity of the product.
- We found that there are two different expectation from users about the
default behavior of the inventory when the quantity is not explicitly set.
Some expect that the product quantity should be considered as 0. And others
expect that the product quantity is not changed. So we added an option on
the inventory to choose the behavior when an inventory line has no quantity.
- Until now, the assignation process for supplier return shipment was not using
children location but this did not work if the location was a view. Now we
assign using the children if the location is a view.
- The supplier shipment support to receive the goods directly in the storage
location. This way the inventory step is skipped.
- Until now, only sub-projects having the same party were invoiced. Now
an invoice for each different party will be created.
- The description on sale line is now optional. This prevents to copy the
product name to sale description as it is now shown on the sale report.
- In case a different product is shipped to the customer if the invoice method
is based on shipment, this shipped product will be used for the invoice.
Previously only the initially sold product was always used.
- Now it is possible to edit the header fields thanks to the new Wizard which
takes care of recompute the lines according to the changes.
Reports on aggregated data has been added to the sale module.
The report engine allows to browse the Revenue and Number of sale per:
Country > Subdivision
Those data are over Period, Company and Warehouse.
The reports also show a sparkline
for the revenue trend which can be drilled down.
- The sale with the shipment method On Invoice Paid will create the purchase
requests and/or drop shipments when the lines are fully paid. Before they
were created directly on validation.
- The shipment cost is not more computed when returning goods.
- The product supplier can be used now on the purchase line. This allows to
display the supplier definition of this product.
- Now it is possible to edit the header fields thanks to the new Wizard which
takes care of recompute the lines according to the changes.
- The description on purchase line is now optional. This prevents to copy
the product name to purchase description as it now shown on the purchase
report. The same change have been applied on purchase requests and
- In case a different product is received from the supplier if the invoice
method is based on shipment the received product will be used on the invoice.
Previously the purchased product was always used.
- The user is warned if he tries to confirm a purchase order for a different
warehouse than the warehouse of the linked purchase request.
Purchase request quotation
- This new module allows to manage requests for quotation to different
suppliers. Each request will collect quotation information from the supplier.
The preferred quotation will be used to create the purchase.
- Now it is possible to filter which type of email to use for sending the
- The email notification skip the recipients if the target field is empty. For
example if a notification is defined on the Invoice with the Party as
recipient and the Party has not an email address, then the invoice will not
be sent. Adding a fallback recipients the email is sent to specific user
email which could be a secretary which will be in charge of sending it or
a mailbox for a printer which will print it automatically etc.
Major changes for the developer
- Starting from this release the tryton client will only support the version 3
of GTK+-3. This will allow to migrate it to Python3.
- The group widget can be defined as expandable by adding the attribute
expandable. If the value is 1, it starts expanded and if the value is
0, it starts unexpanded. Both clients support it.
- To ensure that all buttons may have their access rights configured a new
test has been added. We added also the string, help and confirm
attributes to ir.model.button. So they can be shared between different
- The monetary format is now defined on the language instead of the language.
According to User Experience best practices the amount should be displayed
in the user language format event if it's a foreign currency.
- It's now possible to manually define an exceptional parent of a language.
This allows to use a custom monetary format for each country of the
Latin American language.
- Dict fields are now stored using it's canonical representation. This allows
to make equity comparison between them.
- The language formatting has been simplified to expose the instance methods:
format, currency and strftime. A classmethod get is
added to return the language instance of the code or the transaction
- The previous API for session management was based on the ORM methods. This
makes more complicated to implement alternative session manager. We created
a simplified API agnostic to the ORM: new, remove, check and reset.
- If the database has the required features (for PostgreSQL: the unaccent function), the ilike search
will be performed on unaccented strings per default on all Char. This
can be deactivated by setting the attribute Char.search_unaccented to
- We have added the support for EXCLUDE constraints. An EXCLUDE constraint
is a kind of extension to the UNIQUE constraint which can be applied on a
subset of the rows and on expression instead of only columns. For more
information, please read the EXCLUDE documentation of PostgreSQL.
- It is now possible for a module to register classes to the pool only if a
specified sets of modules is activated. This replaces the previous silent
skip. Existing modules that were relying on the old behaviour must be updated
to use the depends keyword otherwise they will crash at start up.
- Sometimes a module depends optionally on another but it may need to fill from
the XML record a value for a field that is defined on the optional module. We
added a depends keyword on the field which ignores it if the list of modules
is not activated.
- The clients now support the definition of a specific order and context when
searching from a field like Many2One, Reference, One2Many etc. This is
useful to have preferred record on top of the list of found records.
- A new mixin has been added to add logical suppression to a Model. But also
we ensure that the client is aware that the model is deactivable. All the
modules have been updated to use this new mixin.
- The context model name is now available on the screen context. This allows
for example to change the behaviour of a wizard depending on the context
- Tryton prevents by default to modify records that are part of the setup
(which are created by XML file in the modules). This requires to make a
query on the ModelData table on each modification or deletion. But usually
only a few models have such records, so we now put in memory the list of
models that should be checked. This allows to skip the query for most of
the models and thus save some queries.
- Buttons can be defined with PYSON expressions for
the invisible or readonly attributes. Some times, the developer wants to
be sure that the field used in the PYSON expressions are read by the client.
A depends attributes have been added which ensure that the listed fields
will be included in all the view where the button is displayed.
- The administrator can now reset the password of the user with a simple click.
The server will generate a random reset password which is available for 1
day by default and send it by email to the user. This reset password is only
valid until the user has set a new password. It is also possible to reset
this way the admin password using the trytond-admin command line tool.
- The context has a new optional key _request which contains some
information like the remote address, the HTTP host etc. Those values are
correctly setup if the server run behind a proxy which set the
- A malicious hacker could flood the LoginAttempt table by sending failing
request for different logins. Even if the size of the record is limited and the records are purged frequently. The server now limits also the number
of attempt per IP network. The size of the network can be configured for
each version (IPv4 and IPv6). This are only the last level of protection,
it is still recommended to use a proxy and to set up IDS.
- The name attribute of the tag image can now be a field. In this case, it will
display the icon from the value of the field.
- Now it is possible to extend with the same
Mixin all the existing pool objects that are
subclasses of a target. An usage example is to extend the Report.convert
method of all existing reports to add support for another engine.
- We have decided to remove the MySQL backend from the core of Tryton. The
back-end was not tested on our continuous integration server and so it has many failures like not
supporting Python3. The current code has been move to its own repository. This module will not be
part of the release process until some volunteer make it green on the test server.
- The current form buttons are automatically added to the toolbar under the
action menu for fast access. Now the developer can define under which toolbar
menu the button will appear.
- Tryton now uses LibreOffice instead of
unoconv for converting between report formats. There were some issues with
unoconv, which where fixed by using libreoffice directly. Now we publish
also docker images with the suffix -office which contains all the
requirements for the report conversion.
- A new Currency.currency_rate_sql method has been added 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.
- Since the introduction of context management in proteus, the client
library, the context management was taken from different places in an
inconsistent way. We changed the library to always use the context and
configuration at the time the instance was created. Some testing scenario may need some
adjustment as they could rely on the previous behavior.
- The previous API to reconcile lines allowed only to create one reconciliation
at a time. But as this can trigger the processing of the invoice for example,
it can be a bottleneck if you are reconciling a lot of different lines like a
statement can do. So the API has been improved in the most backward
compatible way to allow to create many reconciliation at once.
- The invoice now has a method to add and remove payments which should always
- The limit of authentication request per per network is also applied to
the web users.
- Thanks to the implementation of the exclude constraint, the uniqueness of the
email of web user only applies to the active users.