Remaining products :
- product_product_0 becomes service_order_01
- product_product_1b becomes service_cost_01
- product_product_43 becomes product_order_01
- product_product_47 becomes product_delivery_01
- prodcut_product becomes product_delivery_02
- Replace product_product_56 by service_delivery
- Replace product_product_59 by consu_delivery_01
- Replace product_product_58 by consu_delivery_02
- Replace product_product_57 by consu_delivery_03
Removed products :
- product_product_53, product_product_57, product_product_55, product_product_54, product_product_52,
product_product_51, product_product_50, product_product_48, product_product_46, product_product_32,
product_product_33, product_product_28, product_product_38, product_product_39, product_product_40,
product_product_41, product_product_34, product_product_29, product_product_30, product_product_44,
product_product_31, product_product_35, product_product_36, product_product_37, product_product_42,
product_product_45, product_product_49, product_product_26, product_product_14, product_product_15,
product_product_18, product_product_19, product_product_21, product_product_23
Removed corresponding binaries.
Removed all Bill of Materials demo data, that were ridiculous and replace them by 2 bom: A complete
computer, and a kit computer. Rewritten the tests accordingly.
Fixed tests :
- sale_mrp/test/cancellation_propagated.yml : The yaml ref function return a id, not a dictionnary
- sale_stock/tests/test_sale_stock.py : The service product invoiced on the delivered quantity was
in fact not invoiced on delivery on the test. As we are in sale_stock, Without timesheet, we
manually set the delivered qty for the product serv_del. If we don't do this, the invoice will
never be fully invoiced.
- The pricelist rules choice is not based on the sequence anymore (Seems to be a bug, reported to
online). By the way, I changed the product to avoid the overlap.
- sale_mrp/test/sale_mrp.yml: The yaml ref function return a id, not a dictionnary
- mrp : Rewritten the tests to be coherent with the new bom data
Quotations and sales search views are udpated. Indeed they share a lot of
common filters. However their use is different and their filters should
therefore be different.
Using a base view, those two now have separate search views allowing to
define custom filters for quotations and sale orders.
As the report are downloaded from a controller, the context of the
webclient is lost. We chose to use `context_get` to get back one
instead of serializing the context trough the url.
In some non-usual circumstances, using unicode in controllers can lead
to issue. For example on a terminal using C encoding (instead of the
mighty UTF-8) werkzeug might use sys.getfilesystemencoding to encode the
request URL which will fail with UTF-8 inside.
This commit change the URL character of the font awesome controller to
UTF-8, but keep the old way since every sent mail might still use it.
There is the overlap of character 0 to 9 which are overidden in this
commit by unicode code 0 to 9, but these were not used in font-awesome
anyway (or these are not even visible ASCII characters).
closes#9572
When creating a department, a default message appears in the chatter
that says "HR department created". It is misleading because the
department is not necessarily HR.
With de5a00ac9 the editor would be loaded on the forum, but it would
then always be loaded on the website which might not be for the best.
With this change, the editor assets will be loaded on the website:
- if the viewer is part of the "base.group_website_designer" group,
- if we are on a forum page,
better solution for #9402
When you import a record from a XML file, values passed to float fields
are not casted as floats.
Eg: ``<field name="price">1.0</field>`` is parsed as '1.0' string.
The method _update from ir_model.py seems to accept these "fake floats"
strings BUT, if you override write() in a module, you can't guess that
values meant to be written in a float field are actually strings
Eg: The override of write() in sale.order.line expects a float and crash
at second install. (try twice `-i sale` in a 9.0 database)
In order to fix this, we apply the same reasoning than for integers
(two lines above).
Two RPCs were performed by the chat_manager on webclient launch. One of them
was about emojis, and recent messages received in the past 10 minutes in
detached channels. This RPC has been removed as the emojis fetching can be
done in the other RPC (mail/client_action), and the recent messages are not
useful since the refactoring of mail and the introduction of the chat_manager.
HS Code is a standardized code used to describe products categories, and
facilitate customs clearance.
(https://en.wikipedia.org/wiki/Harmonized_System)
Some international transporters require HS codes and use them. We allow
users to store them on product.template's.
When a product is linked to several "supplier.info" records with
the same name or same product_name, the name or product must only
appear once.
opw:660107
By default, users can only create/edit/unlink
personal `ir.values`, the values with themself as
`user_id`.
Setting the default `deposit_product_id` should
therefore be done as sudo in case if the `deposit_product_id`
default value has already been created before by another user
but is no longer valid.
opw-660180
Timesheet lines are meant to have no product, and instead rely
on an implicit "Service" product. The UoM used is the company's
project UOM (project_time_mode_id), and the nominal cost of this
product is set on each employee.
Forcefully using the SO product as was done before is useless
and actually caused inconsistencies. The `unit_amount` value
would be expected in the UoM of the SO product, while still
being computed/set in the company's project UoM.
When no nominal cost can be found for an employee, the cost is
assumed to be 0, so the `amount` value is 0 too.
In addition, the product field is not supposed to be visible on
any form where timesheet lines are recorded.
This patch fixes various bits of logic related to this, including
parts which expected the `amount` value to be non-zero, or
the product to be set.