This month we got a major improvement with a new theme for the web client.
Contents:
Changes for the User
We now set the name attribute of the <input/> elements generated by the web client. This allows the browser to provide better auto-suggestions to the user.
We now use the original cost price of a product to update the FIFO cost price when it is returned. This gives a more accurate and logical value, especially when there is no stock of the product left.
It is now possible to delete or detach a source from a Stripe customer. This is useful if you know that a specific source can no longer be trusted.
We added a relate action to the email notifications from any record. So users can easily access, for example, all the notification emails sent for a specific sales order.
We added a relate action to the stock moves from a product or variant. This is useful if you want to find the last moves that happened to a product.
A dedicated view is now used to show shipment moves. This lets the user focus on the important information only.
It is already possible to define a sequence to generate the product variant code. Now we also have a sequence for the product template code.
The web client has got a new default theme based on the bootswatch Paper theme. But it is still easy to deactivate it and use your own theme.
We now automatically fill in the default accounts (like receivable and payable) when creating or updating a chart of accounts if the template only has a single option available.
Changes for the Developer
We now use the fields.depends to get the carrier context when computing the carrier cost. This makes it simpler to extend this with third-party modules.
We fixed a cache ordering issue in ModelStorage which made browsing a large number of records in depth (more than 2k by default) randomly slower than expected. Now the time is roughly constant.
The stock assignation method now automatically fills in the grouping value on the assigned move that’s used to compute the quantities. This allows you to easily write modules that set the lot on assignation for example.
On busy systems, the queue table can grow quickly. So we’ve added a scheduled task that runs each day which removes completed tasks that are over 1 month old.
We now allow a successful or failed payment to be put back to a processing state. This is because, in some cases (like with Stripe payments), you may need to update a payment that has already been successful (e.g. in the case of a refund). The new transition allows you to avoid using the failed state just for the purpose of performing this change.
1 post - 1 participant
from Planet Python
via read more
No comments:
Post a Comment