To prepare the coming release 4.8, a lot of pending developments have been finalized before the development freeze. The release 4.8 is scheduled for 23rd April. Until there, we are requesting everyone to help us finding and fixing the remaining bugs. The translation process will start the 2nd April until 20th April at 20:00 CEST. You can contribute your translations on Pootle.
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 erase personal information linked to the party like the name, addresses, contact mechanisms etc. It removes also those data from the history tables. But each module adds check to prevent erasure if pending documents for the party still exist.
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 less astonishing.
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 sale modules receive reports on aggregated data. 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 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.
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.
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 those customization. Now, the records that are synchronised with a template are read-only by default. A check box allows to edit the value and to remove the record from the update process.
Sometimes, user may create by mistake a second chart of account. There are very rare case 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.
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 new module account_tax_cash allows to report taxes based on cash. A tax group 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 are verified against modification on closed period. The registration of payment on the invoice is limited to the amount of the invoice.
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 more defined on the tax but instead they contains a list of tax lines. Those lines can define the base or the amount of the tax. On the report, the lines of each tax code are summed per period.
When there is a very large number of location, the tree Locations Quantity become 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 was not using children location but this did not work if the location was a view. So now, we assign using the children only if the location is a view.
The supplier shipment support to receive the goods directly in the storage location. This way the invetory steps is skipped.
Until now, only sub-projects having the same party were invoiced. With issue7096, an invoice for each different party will be created.
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. By 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.
For now, it will no more be possible to expand a node that have too much records. This is needed to prevent to consume all the resources of the client. When such case happen, the client will switch to the form view where normally the children will be displayed in a list view.
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.
Until now, when changes on a record from a pop-up window were cancelled, the client reset it using the stored value from the server or delete it if it was not yet stored. Now, the clients will restore the record to the state it had before opening the pop-up.
We have pushed many small improvements to sao, the web client, which fixes small jump of elements of the page:
The web client receives finally the label that positions the selected record in the list and shows the number of record in the list.
The management of editable list/tree has been completely reworked. Now the full row become editable on the first click. The focus is kept on the line if it is not valid. The edition is stopped when the user click outside the view.
More modules have been reviewed for tooltips:
The clients shows next to the search input a toggle button for all model that can be deactivated. This allows the user to make search against deactivated records and to now that such functionality exists.
The previous API was based on the ORM methods. This makes unnecessary more complicated to implement alternative session manager. So 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 False.
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.
This new constraint has been implemented on party category name to ensure that top level (parent IS NULL) names are also unique.
It has also replaced the unique email of web user to only applies to the active user.
It is now possible for a module to register class only if a specified sets of modules is activated. This replace the silent skip that existed previously. Existing modules that were using this silent skip must be updated to use the depends keyword otherwise they will fail.
Sometimes a module depends optionally on another but it may need to fill in the XML record a field that is defined on the optional module. We added a depends keyword on the field which makes it ignored 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 deactivatable. All the modules have been updated to use this new mixin.
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.