Inspired from this commit: 90219a7e0a
It's not possible to modify the shipping area description on a product in
the e-commorce.
opw:1908308
closesodoo/odoo#28624
When the qunit tests runs they are expecting the new line to be the character 10,
but in windows the new line is 10+13.
The test has been updated to ignore the character 13.
closesodoo/odoo#28599
Put the browser in timezone Sao Paulo (Or like West of UTC)
Trigger the autocomplete (and the subsequent search) on a date field
by writing a date (in the locale format) in the search view
Before this commit, the domain sent to the server contained the date as the day
**before** the one asked for in the input
This is because, the string input is parsed and gives:
input = 12/02/2018
When creating the moment object:
> since there is no explicit time, moment will interpret it as 12am (midnight)
> We force moment to consider the string as being UTC (function: moment.utc())
> the moment contains, as output the time ** 2018-02-12T00:00:00 UTC **
When getting the facet value for making the domain
> we call toDate on the moment object, which, according to the browser is UTC and will
be converted to the locale timezone before formatting
> And the domain will use the date 2018-02-11T22:00:00 Brazil/SaoPaulo
which gives the day before the one we asked for
After this commit, this issue doesn't arise, because we use the string representation of
the moment object in search_inputs (i.e 2018-02-12T00:00:00 UTC), to create a new one
*BUT* we create it with a date format that excludes the time from being interpreted.
Also, the resulting moment object in this case is not flagged as UTC anymore
OPW 1903224
The `context.company_ids` variable seems mostly empty in the case of the
Manual Reconciliation widget. Therefore, we fetch the current company of
the user in the session.
Complement of e5c8071484Fixes#28270
opw-1904475
closesodoo/odoo#28541
Be in the timezone Australia/Brisbane
On an object, create a Meeting activity
Create the calendar event and set a start date "tomorrow" at 7:00am
Now go back to the object to see the activity
Before this commit, the activity appeared as due "today"
After this commit, it is due "tomorrow"
OPW 1891110
closesodoo/odoo#28576
Firefox when asked to block format (formatting over a block with
blockquote, h1, ...) has a special case for blockquote (it is documented
in https://developer.mozilla.org/docs/Web/API/Document/execCommand at
formatBlock command) and will wrap any element instead of replacing
existing block formatting.
Thus the code not expecting it was not able to remove a blockquote in
firefox once introduced.
opw-1903735
closes#28587
When we for example do ctrl+a in firefox, the selection is over the
container and not the content.
This is an issue when we apply a format, since the container could be
removed.
eg:
we have selection over `<pre>hello</pre>`, on firefox the selected
node is `pre`, on chromium it is `TextNode "hello"`.
if we remove the style, `pre` is deleted so firefox selection is
broken, whilst chrome has no issue since "hello" still exist.
There was also an issue when the selection was over the blockquote,
there was no error but the style could not be removed.
opw-1903738
opw-1903735
closes#28369
There was a code that on:
- a form that sent a mail
- with a custom file field
would set the file as attachments, but the code was dead because of a
typo in `if` statement order.
opw-1906883
closes#28525
In mail template a link with reference such as:
${object.user_id.signup_url}
are often used.
These are template directives that are replaced when the mail is saved,
so when editing in the editor and they are prefixed by "http://" this
breaks the link which is not wanted.
Now link beginning with `${` are not prefixed anymore to prevent
shooting oneself in the foot.
opw-1906695
closes#28522
If cost(purchase_price) was 0, margin calculation was incorrect.
The function _product_margin didn't consider the use case
where the cost of the product was set to 0 on the line.
So before the fix it fallback on standard price instead of considering a cost of 0.
opw:1890452, 1885587
- When creating an eCommerce cart using the Public User, the code tries
to access all the sale orders linked to it.
Depending on the count of sale orders linked to the partner, the
loading can take a lot of time.
To avoid this, we only search for the sale orders of connected users
and we only retrieve the last one.
PKG-INFO is generated during the setup phase and is not needed anymore.
Also this file contains outdated informations.
py2exe is not used anymore to build the windows installer.
closesodoo/odoo#28494
c5dc0b2f39 disabled send button on composer sent.
But this is only needed for chatter composer, other composers directly
send the message and are not refreshed asynchronously.
So for other composer, the send button worked one time but then was
disabled and the only way to sent was ENTER (on basic composer) or
CTRL+ENTER (on extended composer).
With this fix, disabling the button is done only for chatter composer.
11.0 backport of 12.0 #28474
issue found when checking opw-1904029
closes#28506
When loading the Reconciliation Widget, all reconciliation models are
retrieved. This is not correct: only the one matching the company and
the journal should be retrieved.
Fixes#28270
opw-1904475
closesodoo/odoo#28474
Consider the generation of an invoice for a SO having the following lines:
quantity | unit price | taxes | subtotal
----------------------------------------
1 | 100 | 15% | 115
1 | -110 | | -110
Previously, the invoice wrongly received the type 'out_refund' instead of 'out_invoice'. This was because the code was only considering the untaxed amount.
Closes#28259Fixes#26726
Co-authored by pedrobaeza
Before this commit, when there was several previews
on the messaging menu that were not linked to any
document, marking one of them as read had the unintended
behaviour to mark all of them as read.
Steps to reproduce:
- Admin with notification management as 'Handle with Odoo'
- Demo assign Admin to two different tasks
- Admin mark one preview as read
> Both previews notifying assignment to a task have been
marked as read
This is caused by the fact that messages of those previews
are not related to any document. As a result, when marking
one preview as read, it maps related messages to mark as
read, which was taking into account all messages that are
not related to any document.
With this commit, previews now tracks message IDs, so that
marking one preview as read only mark the related messages
as read.
Task-ID 1907159
Before this commit, when the user clicked on a preview in the systray
messaging menu that is not linked to any document, there was a
traceback.
Steps to reproduce:
- Admin sets notification management to "Handle with Odoo"
- Demo user assigns Admin to a task
- Admin clicks on preview from being assigned to a task
Those are previews from notifications received from the inbox,
which are not related to any document. It attempts to open a
document that does not exists (i.e. no model/id).
With this commit, when such a preview is not linked to any
document, it now opens Discuss with Inbox.
Task-ID 1891350
Before this commit, if you ask for a small image, you was waiting a picture of
64x64 but in case this image was not found, a placeholder with an other size
was returned.
Now, we try to guess the asked size, and return a resized placeholder.
This bug appear since we change the default placeholder picture with a big one
This will fix several issue and avoid to hard code size everywhere in the code
Eg: commit 92f837c and commit https://github.com/odoo/odoo/commit/154fc7d9dd550d35b7266af024e54c20e18938fc#diff-9af1af2039d16d6b544d481b4ee1ed7cR144closesodoo/odoo#27695
When changing the field `image` on `res.users`, the `write_date` of the user is
not updated because the field is inherited from `res.partner`.
Related to Issue : 1839603
This code is called by account_reports to build the Aged Receivable/Payable.
However, no support for the multi-company/multi-currency is there and then,
the multi-company filter on account_reports never worked.
In a multicompany environment, an user who has access to multiple companies is
able to select accounts and analytic accounts of multiple companies. This can
easily lead to mistakes in the definition of the asset category.
With this commit the user can only read/select accounts and analytic accounts
belonging to the company already set in the asset category.
This is what is already done in most invoice or other accounting views
Closes#26578
payment_term.id, creates a tuple wich works if payment_term.id is set
in case payment_term.id is False this creates the tuple (False,) which
is then converted by the Odoo ORM to a account.payment.term(False, )
record set, which in term may cause weird behaviour as this value does
not eval to false in cases like `if self.payment_term_id:`
Closesodoo/odoo#28397
Before that, when reversing an account.move, if two lines of the move shared the same account, we tried reconciling them once for each line: it worked the first time but triggered an error message the second, since the lines had already been reconciled.
On the BoM structure report the price on line with a
child BoM is inchoerent. Also the sum of all lines in
the report is not always equals to the total of the parent
line.
For the first issue, it happens due to commit 17b6256955
that use the number of operation cycle as quantity.
The second issue happens because sometimes the rounding is not done
at the smallest level and thus the rounding of the sum is different than
the sum of the rouding.
Fix translation placeholders in invite wizard, to make them easier to
understand for translators. Also rework the message generation code
to ensure proper XML structure.
Fix translation placeholders in invite wizard, to make them easier to
understand for translators. Also rework the message generation code
to ensure proper XML structure.
Before that, taxes were only applied with the most recent currency rate, which caused problems in multi currencies, when reconciling statement lines made in the past with invoices, causing the amount currencies in the payment account.move to be wrong.
//Scenario to reproduce the issue (from customer ticket 1903497):
(for a company with USD as base currency)
1. Create a new bank journal for EUR payments
2. Create a new customer invoice for 90€
3. Create a new tax for the reconciliation model, price-included and amounting to 15%
4. Create a new reconciliation model using this tax
5. Use the currency rates from the demo data, add one that is closer to current date than the most recent one.
6. Create a new bank statement for the created EUR bank journal. Make sure that the transaction is less than the actual amount due on the invoice so that we can apply the reconciliation model. Also make sure to set a date on the transaction that lies in the past at some point when the currency rate was (significantly) different.
7. Hit the reconcile button, select the amount due from the invoice and apply the discount reconciliation model(take note of the amount on the created tax move line). Now reconcile.
What is the current behavior that you observe?
Now go back to the bank statement and check the created journal entries. You will see a difference in the amount currency values of the payment and the tax account move line. This difference should not exist.
Revert commits da2140b726, e65c8826ef and 06cd145a79. They
introduce an incorrect UOM.
The original issue was an `AccessError` due to the fact that the
employee chosen was not in the same company than the user. Therefore,
instead of changing the logic of the UOM selection, we make sure to
select the employee in the appropriate company first, then fall back on
any company then.
opw-1888299
Due to the implementation of PEP-475[1] in Python 3.5, revision
e98e8e9b1b used the recommended technique
of wakeup file descriptors in order to detect interruption of sleep() and
select() by signals, when running in multi-process mode (workers > 0).
The technique works well, however the initial patch never bothered to
read the byte that is written to the wakeup pipe when a signal is
processed. This does not matter when the signal is meant to shut down
the server, but it matters when the signal is SIGQUIT: it simply prints
thread dumps, and continues operating normally.
As a consequence, that byte remains in the wakeup pipe forever, causing
all the subsequent select/sleep calls to return immediately because
the wakeup fd *is* already ready. The symptom was that worker
processes would start cycling their main run loop very fast after
receiving a SIGQUIT signal, eating 100% CPU.
This patch ensures we always empty the wakeup pipe after an interruptible
call, to avoid this effect. It also refactors another occurrence of the
"empty pipe" pattern, in the PreforkServer, and incidentally uses readable
aliases for the file descriptors bound to the ends of the wakeup pipe
(wakeup_fd_r / wakeup_fd_w).
[1] https://www.python.org/dev/peps/pep-0475closesodoo/odoo#28356
This commit tackles the issue of having the pseudo-object 'parent' in the
invoice lines views
In the regular o2m, parent refers to the current invoice
From commit eca030cc38
we learn that parent.get() is not a valid field according to python
From OPW 1912243, we learn that:
- when the invoice line form view is standalone (not popped from the o2m)
'parent' is not what we expect (in this case it will refer to the record list of all invoice lines, NOT the invoice)
- parent.type in that case is undefined and makes the JS crash
So, to make sure we retrieve the right field and value, we retrieve them through
related fields pointing to the invoice
closesodoo/odoo#29074
Have an expense product with a supplier tax on it
Write an email to be caught by the thread model to create an expense for that product
Before this commit, the tax was not set up on the expense
After this commit, it is
OPW 1908596
closesodoo/odoo#29061
Goffin Simon