When modifying a translatable record, we try to keep close translations
However, we do not need to do it if there is already a translation for
the matched term.
When a portal user changes his account details and presses the 'Save' button
when a mandatory field is not set, the selected country will be reset even when
the user did change the country in the form. This fix prevents this from
happening and leads to an improvement for the end user.
This commit closes#22439
As Admin:
- Set up 2 languages for the installation, e.g. English and French
- Admin language is English, Demo language is French
- Create a `res.partner.category` named 'Test English'
- Assign the category to a newly created partner
- Create a French translation for 'Test English', e.g. 'Test Francais'
As Demo:
- Create a Mass Mailing
- Select a custom domain: ('category_id', '=', 'Test Francais') => it
should match one partner
- Save and validate
Now either:
- manually run the scheduled action "Process Mass Mailing Queue" as
Admin
- wait for the cron to process the mass mailing
No mail will be sent since the domain will be evaluated in the Admin
language, i.e. English. Indeed, the domain
`('category_id', '=', 'Test Francais')` does not match any record in
English.
The solution/workaround is to use the language of the last user who wrote
on the mass mailing.
Closes#20906, Closes#15467, Closes#15445
opw-778922
- Create a new pricelist for a new currency
- Set the 'Sale Price' option to 'A single sale price per product', so
that the user cannot see the pricelist details
- Sell 0.5 unit of the product with the new pricelist
The pricelist is not correctly applied.
This is because the default minimum quantity is 1. Once the user is
selling less than 1 unit, the pricelist is not applied.
opw-1825353
This commit https://github.com/odoo/odoo/commit/965f49201812cc3cca319a3b5b93331272dd2288 removed empty meta-description and meta-keywords from
the DOM for SEO audit reasons (these tags when empty are considered as
duplicates at a SEO point of view).
By doing so it prevent the 'Optimize SEO' to work correctly since it can't
retrieve the DOM elements that are used to store the user modifications until
he saves.
Now, even when these meta-tags are empty, we display them to people having the
rights to 'Optimize SEO'.
This closes#23659
Before that, partial payments on open invoices were ignored by the query, due to the fact we used checked "reconciled=false" instead of "full_reconcile_id is not null".
The payment lines shown in the payment widget on invoices, should only list reconciliation made towards the lines sharing the same account as the invoice/bill. Previously, if a tax or an invoice line was using another account set reconciliable, any payment made against this account would be shown in the payment widget, which is wrong.
OPW: 1805968
When a membership line has its dates changed
(date_from, date_to, date_cancel)
The membership start/stop dates on the member
(res.partner) were not changed accordigly.
opw-1823981
In a multi-company environment,
if a user in company A
created a Payslips batch for an employee in the company B
and used the `generate payslips` button,
the created payslip was set with the user company (A) while
it must be the employee company (B).
opw-1820138
Have your OS be in Vancouver with time = 15:59:00
We are on day X
Have a next activity on a lead, scheduled for today
At 15:59:00 the next activity is not overdue
Before this commit:
Past 16:00:00 the next activity becomes overdue
This is because 16:00:00 is 00:00:00 in UTC (+8 hours)
And the next activity is scheduled for day X
But in UTC, we just passed at day X+1
Hence, the next activity being overdue
After this commit:
The next activity is not overdue, since we are actually on day X
OPW 1815323
The previous commit forbids to change the currency of a company having accounting entries, but there are some created by demo data and some tests were trying to set a different currency (to set up a fix environment). So in order to allow that in tests, we do it via a SQL query directly
The computation of residual amounts on account.move.line does not use account_id.currency_id... and should not. Never.
The previous implementation was thus stupidly recomputing the amount_residual fields on all journal entries of an account as soon as its currency field was touched, for nothing.
Make an invoice for partner X
Make a payment from partner X (not using the register payment button)
On the invoice, you'll see your payment proposal
Now, reverse the move of the payment
Before this commit:
On the invoice you *still have* the payment proposal
This is because nothing reconciled the reversed entries with the original ones when they were created
After this commit:
The reversed moves are reconciled one on one with their original counterparts
And the original payment doesn't show up anymore on the invoice's proposal
OPW 1816462
OPW 1816641
Strangelly, this worked in 9.0 as the `this` element refers to the
`window` which also contains the `$` function. This may still be
wrong in some cases though, so it is fixed here (even if reported for
10.0).
opw-(1)817789
The test_mimetypes and base_import modules need various files for their
tests. Before this commit some of those files (.ods, .odt, .xlsx, .docx,
.zip) were not included in the packages.
Fixes#22778
Before this commit:
1. When enabling 'List View of Variants' on a product page, it would not
replace the variant normal view as it should since the code being replaced
is included in the code replacing it.
2.The badge specifying the price difference between the variance and the
product base price would be calculated by taking the price_extra of the
variance attribute and converting it in the user currency which was not
correct if a pricelist was set on the product variant because the price diff
would then be (the variant price set on the pricelist) - (product base price)
Note: this is about the 'List View of Variants' mode, not the normal mode
which list variant attribute and not variant itself
3. The strikethrough amount was not in the user currency
Step to reproduce:
- Enable variants & pricelists
- Enable multi-currency and activate 'COP' as second currency (you may want
to change the currency symbol on edit mode since it is also '$')
- Go to iPad Retina Display product page in shop
- Enable 'List View of Variants' in 'Customize'
- Both Variants selection mode are visible (bug 1)
- The third variant shows '+$ 50.40' which is the diff between the
strikethrough prices (in fact the sum of the price_extra of the product
variant attributes, +50,40 on the 32GO attribute in this case)
It should show '+$ 40.32' since the price change from $600 to $640.32.
This is bug n°2
- Change Public Pricelist currency from USD to COP
- Back on iPad page, change between the 3 product variants, you will see
the $ price strikedthrough instead of the COP one:
Strikedthrough: 750 (it should be 1 714 491,47)
Price: 1 371 593,17
This is bug 3
- You can notice the bug n°2 being more visible since it shows
'+$ 115 213,83' instead of '+ 92 171.07'
- Remove the iPad Retina from Public Pricelist and add iPad Retina 32Go
variant to it with a fix price of $1 000 000.
- '32Gb, 2.4GHz, White' variant cost $1 000 000 but shows '+ 115 213.83'
instead of '- 714 491.47' since the base price of Retina is
'1 714 491.47'.
- You can play with the pricelist price for this variant up and down, the
diff price shown in the badge will always be 115 213.83 since it will
always calculate it by summing all the variant's attribute price_extra
and then converting it to the user currency.
This closes#14094, closes#22553
This commit improves link creation in web editor.
Before this commit, anything with a @ would be considered as valid email which
is obviously not the case. It would then be prefixed by 'mailto:'.
This was causing 2 issues:
- URL with @ symbol in it would have 'mailto:' added as prefix, like google
maps coordinates.
eg: mailto:http://www.google.com/maps/whatever/@312211.22,321321
- Incorrect emails would go through (eg: @@@, ko@k@k@, mail@mail)
Now, we will try to detect and identify valid emails from invalid emails from
URLs. It will also handle 'mailto:' directly typed in the input.
This commit comes with it's counterpart in enterprise https://github.com/odoo/enterprise/pull/1859
This closes#11984, closes#22936
Note that there is a WIP in master to use this new is_email function
everywhere we try to validate emails. It will aim to uniformize email
validation in odoo's javascript that are often performed with different mean
here and there, some more permissive than others, some only checking for @.
Apparently, SEO audit thingies (possibly google's own? unclear) don't
ignore *empty* keyword or description meta tags, then complain that
they're duplicated (there's a use case for SQL-like nulls).
So remove the keyword & description metas entirely if the
corresponding fields are empty.
OPW-815492
Having base_vat installed (but is potentially more general than this)
In the pos frontend, try to save a partner with an incorrect VAT
Before this commit, the generic and cryptic message "your internet is probably down" was displayed to the user
when a python exception occured
After this commit, we display the exception's message
OPW 807656
We should normally stick as close as possible to the version we depend
on in the official DEB packages. This in turn depends on the version of
Debian stable at the time of release - for 9.0 that would be Debian 8
(jessie) and thus Pillow 2.6.1.
However Pillow versions before 3.1.1 suffer from a few issues that could
lead to crashes of Odoo workers. The bugfixes have been backported in
the DEB packages for Pillow, so users of Debian/Ubuntu LTS versions
won't be affected if they are keeing their systems updated.
However it's worth an exception to our rule for pip users.
FWD-PORTS: skip
When the utility method `keep_query()` is used outside an httprequest
context (e.g. rendering a template from a unittest) the following
exception is throwng:
`RuntimeError: object unbound`
The above exception is caused by the method trying to retrieve
parameters from the HTTP request, even if the request object is unbownd.
This change ensures those parameters are retrieved only when exists,
making possible to use it outside the web client
Closes#18841Closes#22942
Closes opw-815322
Christophe Simonis