Опубликовано: 2017-05-19 09:00:00+00:00
A bug in the trytond release 4.4.0 has
been found that prevents the server to create foreign key constraint.
This means that database created or updated using this version are missing
those constraints. It is important to upgrade to the new release 4.4.1 and
exceptionally re-run the database update to create the new foreign keys.
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.
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
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.
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
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.
It is now possible to use product category as criteria to match a commission
The price list has now a new criteria based on the category. It matches
products that are linked to the category (standard or accounting).
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.
A new producible checkbox is added to the product. This allow to restrict the
product that can have a BOM.
The purchase price is now displayed on the product search list from the
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.
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
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.
This new module defines the basics to support subscription of recurring
services. And periodically invoice them based on consumption created recurrence
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.
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
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
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
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.
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
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.
New methods ceil and floor have been added to the Unit of Measure. They
have the same API as round.
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.
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.
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 Foundation has decided to publish a budget for 2017. This is the result of
requests from the community will to know what are the plans of the Foundation.
Of course as the revenue of the Foundation relies only on donation, we can not
guarantee that every things will be realized. Indeed we have ordered the points
by priority. Each point will be activated once we have we reach its donation
We are proud to announce the 4.2 release of Tryton.
With this release, Tryton extends its scope to tailored user applications like
Chronos and also as backend for webservice.
A part of the effort was put also on closing the feature gap between the web
and the desktop client. The web client is still a little bit behind in terms of
features but at the current rate the gap will disappear in few releases.
This release contains many bug fixes and performance improvements.
Polish is now an official language of Tryton.
Of course, migration from previous series is fully supported.
Major changes for the user
The tabs in list view can now have a counter showing to the user the number
of records under them. The feature is activated by default on tabs where the
number should tend to zero thus providing some hint to the user about pending
When creating a new record from the drop down menu of a relation, the form
will have the value entered in the field as default value. This helps the
user fill the form.
The buttons can now be configured to be clicked by a number of different
users before being triggered. The user can see on the button how many clicks
it already received and on the tooltip who clicked.
With the recent Neso retirement the database
management from the client has been removed. This improve the security of the
system by removing a potential attack vector.
It is now possible to define for each record a different color on the
calendar view. This allow to group records visually.
The icons of the relation field has been improved. The experiences have shown
that the old version had drawbacks which confused some users. The result was
that some users thought they were searching for a new record while actually
they were editing it.
As a result the editing button has now been put in on the left and a new
button to clear the current value has been put on the right of the field.
The web client completes its sets of functionalities in order to be closer to
desktop client. The new features implemented in this release are:
A comparison amount has been added on Balance Sheet and Income Statement,
allowing the amounts to be compared with different date, fiscal year or
The second currency of account is now enforced, closing the gap between the
documentation and the code. Thus it is possible to compute the balance of
such accounts in the account currency.
The creation of a tax can be quite complex. To ease the process, a testing
wizard has been added allowing to see the result of the computation in order
to validate the definition of the tax.
The payment term is no longer required. An invoice without payment term will
create a single due line at the invoice date.
By default, the invoice reports are stored in the database when the invoice
is posted to ensure the immutability of the document. But on large setup with
a lot of invoices, the database becomes very huge and this can generate on
overload and a waste of space for the backups. So a new configuration option
has been added to store the invoice reports in the file store instead of the
The option can be activated on existing databases. If the report is not found
in the file store, the system will take the value found in the database as
The process to post invoices has been reviewed in order to have better
performance when posting a large number of invoices.
The tax identifier of the company is stored on the invoice. This is useful when
company has more than one identifier registered. By default, the system will
take the first one.
A new group for Payment Approval has been added in order to have finer
grained access to the functionalities.
The amount to pay of the invoice is now decreased by the amount of the
It is now possible to block the payment of a line.
A statement line for an existing payment will mark the latter as succeeded or
failed depending on the sign when the statement is validated. This ease the
management of the payment state as some banks credit the bank account first
and later if the payment fails, they debit it.
The statement line can also refer to payment group instead of individual
payment. This is useful when the bank statement contains only one operation.
Many redundant fields with the account lines have been removed on the line.
This simplifies the encoding and avoids mistakes.
A new type of analytic account has been introduced for distribution.
The analytic lines will be divided when used with such account into many
lines accordingly to the distribution ratio defined per sub-accounts.
The move line has now an analytic state which defines if the amount of the
line is correctly set in each analytic axis/roots. This applies by default
only on income lines. A menu entry allow to search for all lines that needs
The analytic chart enforces now the company consistency. It is no longer
possible to attach an account to an axis of a different company.
The supplier invoice for a depreciable asset does not create analytic lines
on posting. Indeed the analytic lines creation is postponed to depreciation
A more generic address design has been added. It supports as many lines as
needed for the streets instead of the previous limitation of two lines. Also
the formatting of the address can be configured per country and language.
The formats for about 65 countries are preconfigured.
A common problem with referential data like party is the duplication. It is
common that the same party ended to be created twice in the system. For such
issue, Tryton has now a wizard that allow to merge one party into another.
The merged party is inactivated to prevent new usage and the remaining one
inherits from all the documents. For example, the receivable amount will
contain the sum of both parties.
SEPA Creditor identifier is now validated and unified into the party
A new relate from products to variants has been added in order to ease the
navigation between them.
As the payment term is no longer required on the invoice, the same applies
also to the purchase.
It is now possible to create a purchase request without product. In such
case, a description is required and will be used for the creation of the
When converting request into purchase, the requests containing the same
product with the same unit will be merged into the same purchase line. This
simplifies the purchase order.
A new module for managing purchase requisitions has been added. It allows users
to create their purchase requisitions which will be approved or rejected by a
member of the Approval group. On approval, purchase requests will be created.
As the payment term is no longer required on the invoice, the same applies
also to the sale.
A lead time can be configured for internal shipments between warehouses. In
such case the internal shipment uses a transit location during the time
between the shipping and the reception.
A relate has been added to the location to show lots and their quantities
inside the location.
The default location defined on the product is used in the output of
production. This unifies the behaviour of this feature with incoming
The supply period of a supplier is configurable now. Before it was always 1
A new set of modules has been published. They provide integration with shipping
services for printing labels and store shipping references per packages of
It is possible to restrict the usage of carriers per country of origin and
destination. Other criteria can be easily added.
The carrier selection is already enforced by default on sales.
A Web-Extension named Chronos has
It allows to quickly encode timesheet entries using the new user application
API (see below). The application supports to work offline and synchronises
when the user is back online.
It will be available soon on the different browser markets.
It is now possible to define a start and an end date for the employees.
In such case, they will not be allowed to encode timesheet outside the
The work has be simplified by removing the tree structure. It was considered
redundant with the tree structure of the projects.
The timesheet works are created automatically from the project form. This
simplifies the management of projects.
Thanks to the new lead time per BoM and routing, start dates can be computed
for productions. This allows to have a better schedule of the production
needs for long running productions.
Following the work on previous versions, the production area has received two
new modules to extend its functionalities:
It allows to track the time spent per production work.
Similar to the stock_split module, this module allows to split a production
into several units.
Major changes for the developer
The desktop client support GTK-3 thanks to the pygtkcompat module. The
support is still experimental and can be tested by setting GTK_VERSION=3 in
the environment. The plan is to switch completely to GTK-3 in one year.
The server provides now a way to connect URL rules to a callable endpoint.
This feature comes with a set of wrappers to simplify the work of the
developer like instantiating the pool of the database name found in the URL
or start the transaction with automatic retry on operational error.
But the more interesting wrapper is the user_application which allows to
authenticate a user with a key for a specific sets of endpoints. This feature
allows to create applications that do not need to login on each use.
Chronos is an example of such application.
The translations now support derivative languages. Most of the main language
has been renamed without their country code. This allowed the merge of all
the Latin American Spanish translations under one common language deriving
It is now possible to configure Binary fields to store the data in file store
by setting the attribute file_id to the name of the char column which will
contain the file store identifier.
A new level of access rights has been added targeting the buttons. It allows
to define how many different users must click on the button to actually
It is possible to configure a different cache than the MemoryCache. It just
needs to define the fully qualified name of an alternative class in the cache
A new widget has been implemented in the clients for the Char field that
stores PYSON expression. The widget displays a human readable representation
of the expression and uses an evaluated dump of the expression as internal
The read-only states for the fields xxx2Many is now limited only to the
addition and suppression of records. The target records must manage
themselves the read-only state for edition. This behavior allows for example
to still edit the note field of a line of a validated sale while other fields
To speed up the tests and especially the scenario, a new option has been
added that allows to store clean dumps of database (per module installed).
A dump will automatically be loaded instead of creating a new database, this
operation is way faster. Of course, the developer is responsible for clearing
the cache when the database schema definition has been modified.
A new mixin has been added to generalize the common pattern of ordering
record with a sequence field. It is named sequence_ordered and can be
customized with the name and the label of the sequence field, the default
order and if null first must be used.
The login process has been reworked to be very customizable. It is now possible
to plug any authentication factors without the need to adapt the clients.
The authentication_sms module allows to send by SMS a code to the mobile
phone of the user that he will have to enter to proceed with the login.
The module web_user is the first of a new set of module which aims to provide
facilities to developers who want to use Tryton as backend for web development.
The videos recorded and the slides of the speakers are published.
25 developers joined the NaN-tic office to sprint during 3 days. 11 of them
achieved to have at least one patch pushed into the repository and for some of
them it was the first one. Others worked on improving the documentation and
some blueprints for future new features.
Even if the sprint is finished, it still influences the project as many
continue to contribute which is the main goal of the sprint: to onboard new
developers. Another result of the sprint is the creation of a monthly remote
to keep the good spirit.
The CVE-2016-1241 allows an
authenticated user to read the hashed password of other users. The exploitation
is not easy thanks to the existing protection of Tryton against such leak.
Those protections are usage of strong hash method (bcrypt or sha1) and the salt
of the password with random data (protection against rainbow tables).
The CVE-2016-1242 allows an
authenticated user with write access to report or icon definition to make the
server opens any readable file. By default, only the administrator group has
such right access.
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
Опубликовано: 2016-06-20 12:00:00+00:00
It was decided to stop the development of Neso, our standalone client/server.
So the last working version of neso will be 3.8.2.
See issue5642 for more details.
A missing access right has been found by Cédric Krier for the Model
'product.product-production.bom'. That allows a malicious authenticated user to
write, create or delete records of this type (see issue5570).
Any authenticated user can modify the links between products and BoM's.
All users should create manually a default model access which limits to read
only and a second model access limited to the group "Production Administration"
with full access.
Affected versions: all versions of production module prior to series 4.0
Non affected version: all versions of production module after series 4.0