When an order with a fixed amount tax was returned the sign of the tax
was wrong because amount_base was negative and quantity was negative too,
then the tax was positive due to math.copysign(self.amount, base_amount) * abs(quantity)
The sign of the base amount already takes into account the the sign
of the quantity.
opw:682407
Since using new api for the website_sale module with commit 788c1334e2,
the website_sale module cannot be installed after the sale_stock module
is installed. The problem has not been detected on the runbot as, by
chance, the website_sale module seems to be installed before.
The problem here is that on installation, the _default_website_sequence
method is called to add a default value for the added website_sequence
field. In this method, a search() is done, ordered by this field values
then a read() is performed. The problem is that the read does not use
the given order value and use always the default one, which uses the
website_published field which happens to not be created at that time.
However the creation order of a model fields is difficult to determine
which is why when sale_stock is not installed, the bug does not appear,
the website_published being created, by chance, before calling the
_default_website_sequence method in that case.
To fix the problem, refactore the method by using a SQL query so that
the website_published field is not used. This also makes the method
easier to understand and more efficient.
Thanks to @rco-odoo
Commit cf925c2a58 introduced the test_forum_process file which launches
the UI tests of the website_forum module. Unfortunatly, the file was
not linked in the __init__.py file.
When making an advance payment in percent, the function onchange_advance_payment_method
set the Down Payment Product to False. Then each time an advanced payment in percent
was made, a new down payment product was created and set in sale.config.setting in the field
deposit_product_id_setting.
Now the function onchange_advance_payment_method let the Down Payment Product
even if the payment method is in percent.
opw:683167
The migration of `website_sale` to the new API at revision
788c1334e2
repeated this problem initially fixed by PR #8795.
A browse_record returned by a cached method will be
broken at the next use, because it is bound to a
closed cursor.
The symptom is weird exception in the middle of a future
request:
```OperationalError: Unable to use a closed cursor.```
(which refers to an old cached cursor, not the cursor of the
current request!)
Solution: workaround the problem by returning IDs in the
method that needs to be cached (`_get_pl_partner_order`),
and re-browse them as needed in caller methods.
In addition, remove the useless extra caching of `_get_pl`,
as all it does is browse() the result of the former method,
and that would trigger the very same bug again.
inter_company_rules is an enterprise module and can not be installed in
community version.
Disable the installation and warn the users about it.
Fixes#12800
On website/theme installation and other website_* module installation,
an action was triggered to launch tours. These tours are now used only
for tests and should not be used as onboarding anymore.
Note: in master these tours will be removed to use the new test system.
This is a temporary workaround, which probably deserves
further thinking by @ged-odo, as the root cause
stems from commit 96bf5b2656
The problem is that the list view looked for composite group_by
keys such as "create_date:month" within `fields_get`, which
only contains true fields.
When there is no `color` field on the model
e.g. On invoice line taxes
The color class to apply on the badge was set to
`o_tag_color_undefined`
which doesn't exist. It must be set
from `o_tag_color_0` to `o_tag_color_10`
in order have a color.
Because of this, the taxes in the invoices lines
were not visible, because they were written in white
on a white background.
This has been broken by the below revision:
fe66472e2c
removing the or statement (`||`) to set a default
color for models not having a `color` field.
We choose to set `10` as default value, so the color
remains the same compared to the previous release
(light grey). However, if the new behavior chosen
by the usability is to have these in black, it should then
be changed to `0` again.
This filter must be added in the regular searchview,
and not have his own search view.
Without this:
- view_sales_order_filter_ecommerce is a not search view
for the sale orders, having the same priority than the regular one,
and therefore this view can be loaded by default for other menus
(In this case, this was for the menu Website Admin > Orders).
e.g. Clicking on the `Sales` stat button on a contact no longer
filtered the orders of this contact, but displayed all the orders,
because it was this view which was loaded instead of the regular one.
- In Website Admin > Orders, it was simply not possible to type a string
and search for it in the search bar.
* Move files and reorganize directories according to guidelines
* Lint and clean code, remove dead code
* Migrate code to the new API
In REF commit, some fields of calendar.event models changed. Due to
bad design, the code was not clean with the new API. Changing computed
fields make it more performant, and reduce code complexity.
See commit "[REF] calendar: change computed fields for start and
stop dates" for details.
Change `send_email_to_attendees` signature to force setting email
template and remove `email_from`, since it is not usefull.
Now, when sending email to attendee, meeting author will also received
an invitation.
`get_ics_file` has been modified to be executed in batch.
- `start` and `stop` fields are not computed anymore. Indeed, it was not normal
to have required stored computed field. Normally we shouldn't write on these
fields, but since client calendar api need them, we keep them as normal
datetime fields
- `start_date` and `stop_date` become stored computed date fields depending of
`start`,`stop` and `allday`. An inverse method allow to write on these fields,
since it can be the case from the form view
- `start_datetime` and `stop_datetime` follow the same logic
- `onchange_allday` code is mostly moved in `_inverse_dates` of new computed fields
- `_set_date` method (called in create/write) is now removed, since it does the same
thing as old onchanges
- `_onchange_duration` is kept to adapt `stop_datetime` when changing `start_datetime`
or `duration` on form view
- Duration is now 'zero' in database for allday meeting. Before, it was not changed.
Setting it to zero is less falsy. `duration` can not (yet) be a computed field since
it depends on others computed fields.
After migration, we manage to keep old behavior but the code was crap. Switching stored computed
fields make it cleaner, and respecting new API standarts.
This changes avoid multiple methods doing almost the same thing, and is less 'buggy'.
- move `get_ics_file` from calendar.attendee to calendar.event
- remove calendar.event arguments to convert method into
`api.multi`, which make more sense
- `create_attendees` now returns recordset instead of list of ids
- change signature of `get_interval` method
Goffin Simon