1) Improve readability / performance of moves checks
The queries checking the move name & the duplicate vendor reference was complex
and unefficient for no reason.
2) Recompute amount_currency when reversing invoice
When reversing an invoice, the amount_currency wasn't recomputed even when dealing with
a refund date having another currency rate.
3) The refund must not keep the payment ref of the reverted invoice.
The payment ref is stored inside the receivable/payable line's name. However, when
duplicating the invoice to create a refund, this must be emptied until a new
payment ref will be set.
4) Reintroduce user_id field on account.move
The field user_id has been renamed to invoice_user_id. However, some mail templates
need to access the generic user_id field for multiple models.
5) Fix 'misc' Journal Entry totals
Misc journal entry must have an amount total always positive and not signed.
Furthermore, we don't know how to compute the amount_untaxed/amount_tax so don't
compute that with such entries.
6) Fix cancelling an exchange difference entry / tax cash basis entry.
When cancelling an exchange difference entry, the reconciliation is undo and then,
the exchange difference entry is reversed. Same for tax cash basis entries.
issue: https://github.com/odoo/odoo/issues/35841
7) Fix creation of cash basis entries for reversed journal entries.
When reconciling entries with one being the reverse of the another one, cash basis entries
for taxes must not be created. However, it must be the case when reconciling the reverse entry
(like refunds) with something.
issue: https://github.com/odoo/odoo/issues/35276
8) Fix matching rules ignoring the structured communication.
Since account-pocalypse, the structured communication is landing on the name of the
journal items. Then, the matching rules must consider it.
closesodoo/odoo#36062
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before this commit, a fixed tax amount was incorrect in invoices in a multi-currency
environment as the amount was applied both in company's currency and in foreign currency.
In this commit, the amount is converted when dealing with a foreign currency.
Before this commit, the tax computation was done in invoices using the balance of each base lines.
However, when dealing with python tax having sometimes an amount only dependent of the price_unit,
we need to handle the case when quantity is zero.
issue: https://github.com/odoo/odoo/issues/35358
Since the base in compute_all could be negative but is signed to perform the computation,
the price_unit should follow the same logic and be signed when evaluating a python tax.
Before this commit, the price_unit was equivalent to the base line balance and then, was negative
in case of a customer invoice.
E.g. For an out_invoice of 100, the price_unit is 100 but the balance is -100 for the base line.
Then, the computation is done using a base of 100 but having a sign of -1. However, when evaluating
a python tax dependent of the price_unit (here the balance), the price_unit was negative and then,
the tax amount will have a wrong sign at the end.
In case of large cart and promotion program with a discount reward
of percentage type, we are rewriting the reward order lines
multiple times while we can do all in one update.
opw-2038791
closesodoo/enterprise#5086
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
X-port/Cherry-pick of odoo/enterprise@243e66663a
UTM fields are available in the invoice without sale_crm. That's why just apply
search_read on account.move instead of doing
--> search on sale order
--> map on invoice_ids which is computed
--> search_read on account.invoice.report
to get sale_invoiced_amount.
Currently, stat button 'Invoiced' is not redirecting to invoices tree
view because of wrong action and domain parameters. Thus we, set proper
action and pass valid parameter to get that invoices tree view.
Task 1919391
closesodoo/odoo#35296
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
It happens a lot that we access to the employee timezone to compute
presence states, leaves, ...
Instead of sudoing all those accesses, it looks better to expose this
data in the public profile.
closesodoo/odoo#35811
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Create two models, `object` and `category`. The object have a Many2One
to the category. Override the `search` on the category so it returns a
subset of the records if a context key is present. Create an IR Rule on
object with the following pseudo-domain: `categ_id in category.search([])`.
Search on object with the context key present. Even if the context
should only be applied to category, it is applied to object too thus
there are some object missing.
When evaluating the domain of IR Rules, the current user is propagated
with the current environment context. API calls triggered by the domain
are called with the given context, possibly populating the cache with
different records than it would normally does without the context (i.e.
at `addons/point_of_sale/models/account_journal.py#L19-L23`). Following
requests do use that invalid cache thus return invalid results.
Forcing an empty context on the user used during the evaluation of the
context ensures the IR Rules are working as they should and is
future-proof (cf `load_company` v13 context key)
opw-2041667
closes#35123closes#35125closesodoo/odoo#35667
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Co-authored-by: Hugo Adan <hugo@vauxoo.com>
When accessing a SO's tasks from Contacts (the partner_id's page), and
calling action_view_task, the active_id first corresponds to the contact's id.
Therefore, if a project.project exists with the contact's id, one can access
the SO's tasks, but otherwise, we get the error
Record does not exist or has been deleted.
(Records: [partner_id], User: ...)
Thus, if there is one corresponding project, we first update the context:
active_ids is set to project_id,
allowing access to the SO's corresponding project's tasks.
Note that the same thing is done lower:
eval_context.update({'active_id': task_projects.id})
which is too late to avoid trying to access the wrong record.
In the case where there are more than 1 corresponding projects (or if
there are no corresponding tasks), we don't have the issue.
OPW 2052559
closesodoo/odoo#35792
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
In some cases, the first request of a test is made before the
proper setting of the cookie. In that case, Odoo picks a new session,
leaving the request unauthenticated.
closesodoo/odoo#35780
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
- Take a quizz survey, and fail it
- Go to Answers
- Print the Certification
Even if the quizz was failed, the certification can be printed.
There is no option to prevent printing a PDF, therefore we need to print
a different template.
opw-2049481
closesodoo/odoo#35769
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create Event (Where All Day is Set to False)
- Edit Event > Check 'All Day', make it 'Recurrent'
An error occurs because a mandatory field is not set (`stop_date`).
It is possible to work around the issue by doing:
- Check 'All Day'
- Save
- Make it 'Recurrent'
However, the result should not depend on the order we perform the
action. To solve this we send data to server with `force_save`.
Fixes#27269Closes#33068closesodoo/odoo#35758
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
From the Maintenance app go to "Settings">"Equipment Categories".
Create a new category, insert a name and save. An alias get
automatically created with the same name as the new category.
The new alias point to "Maintenance Equipment" model, so when
an email is matched with the alias a new equipment under the new category
is created. This is indeed the default behavior but the help message
is deceiving the user. Changing it.
opw-2049830
closesodoo/odoo#35728
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Rewrite the product associated to a serial number.
There is a check to forbid this if some move lines already exist.
This check does not actually care what value is written,
so it can raise uselessly (and forbid a legitimate write).
opw 2049717
closesodoo/odoo#35736
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Before this commit, when a user received a needaction notification
on a message already stored locally, it crashed with this error:
`TypeError: Cannot read property 'getThreadIDs' of undefined`
This is caused by `addMessage` returning a Promise not resolved with
the message when the message is not new. The returned promise should
always be resolved with the message, in order to be consistent.
closesodoo/odoo#35724
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Revision on https://github.com/odoo/odoo/commit/e8f7770a13d6ddc1cb8ec1bcebcb22e21962ba52
Commit above fixes an issue with chat windows being open twice.
It fixed the issue by aborting opening a chat window in case a
chat window is already being open.
Opening chat window may be a slow process, due to requiring fetching
some messages beforehand. This operation is necessary in order to
check whether the user has access to messages or not, and prompt an
error message without opening the chat window in the latter case.
The fix did not respect the specs of the method `openThread`: it
pre-emptively returned nothing, instead of returning a resolved
promise. Because of this, it crashed on `undefined.then()`.
Task-ID 2053095
closesodoo/odoo#35722
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Before this commit, The dropdown menu remained open after clicking on
activity icon.
After this commit, The dropdown menu is closed whenever the activity
icon is clicked.
Task-Id: 2047408
closes: #35568
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before, If direct chat or channel has no any message in chat history, then
send button is not clickable in discuss.
Now, fix in scss file will allow to click send button for channel and chat.
Task : 2037292
Closes#35570
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
In case a User is defined as Expense Responsible for another
user, and if he has Officer Expenses Rights, he cannot validate
an expense while it should be the case.
opw-2043985
closesodoo/odoo#35711
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
From the Inventory (stock) application go to Operations>"Batch Pickings"
Create or open an existing Batch Picking and click on "Print".
A report will be generated containing the barcode associated with the
operations. The barcode cannot be read from a barcode scanner because
it's too blurry (probably because of the low quality it contains
an unnatural greyscale).
When this report is generated from the template, a request to generate
the barcode is sent to the controller, which invoke the procedure to
create the png image on the fly with a set of parameters embedded into
the request.
If the width and height parameters are too low the result is a low
quality image, so the solution is to pass higher parameters and then
resize the image via "style" attributes.
Note that the same solution is applied in multiple templates.
opw-2045949
closesodoo/odoo#35752
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Make sure we don't execute the method with an empty list of candidates
to avoid a zero division.
opw-2049881
closesodoo/odoo#35723
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Let's consider two company C1 and C2 and a user U allowed for this two companies
- Create a storable product P tracked by serial number
- Create a PO in C1 with P and deliver it with a serial number SN
- Go to Inventory>Master data>Lots/Serial Numbers
- Change your current company to C2
- Click on SN
Bug:
An access rights error was raised because the system tried to compute SO and PO linked to SN
with the moves of all the companies. So the record rule "stock_move multi-company" was
raised.
opw-2049093
closes#35694
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Pdf files created with third party tools could trigger an exception in
several modules that attempt to manipulate them (see example below).
```
File "/usr/lib/python3/dist-packages/PyPDF2/pdf.py", line 2239, in mergePage
self._mergePage(page2)
File "/usr/lib/python3/dist-packages/PyPDF2/pdf.py", line 2277, in _mergePage
originalContent, self.pdf))
File "/usr/lib/python3/dist-packages/PyPDF2/pdf.py", line 2199, in _pushPopGS
stream = ContentStream(contents, pdf)
File "/usr/lib/python3/dist-packages/PyPDF2/pdf.py", line 2673, in __init__
stream = BytesIO(b_(stream.getData()))
File "/usr/lib/python3/dist-packages/PyPDF2/generic.py", line 845, in getData
decoded._data = filters.decodeStreamData(self)
File "/usr/lib/python3/dist-packages/PyPDF2/filters.py", line 346, in decodeStreamData
data = FlateDecode.decode(data, stream.get("/DecodeParms"))
File "/usr/lib/python3/dist-packages/PyPDF2/filters.py", line 111, in decode
data = decompress(data)
File "/usr/lib/python3/dist-packages/PyPDF2/filters.py", line 49, in decompress
return zlib.decompress(data)
zlib.error: Error -5 while decompressing data: incomplete or truncated stream
```
This is caused by the decompression function used by default in PyPDF2
which uses a limited buffer, unable to store all the data.
The solution, as per
[zlib documentation](https://docs.python.org/3/library/zlib.html#zlib.decompressobj),
is to use an intermediate ```decompressobj``` object to handle
the decompression.
However we do not directly control the library, which is also used
multiple times in the codebase so we decided to apply a fix directly into
the core module instead of patching every call.
opw-2048029
closesodoo/odoo#35646
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Install Email Marketing (mass_mailing) without Website.
From Email Marketing app, under Configuration -> Settings
the section "Mailing List" is empty.
This is not the expected behavior: any empty section should not be
visible.
To avoid breaking some third-party app which could rely on the element
'<div id="mailing_list" class="row mt16 o_settings_container"/>'
we choose to hide the title of the affected section, re-enabling it when
the appropriate app is installed.
opw-2045481
--
I confirm I have signed the CLA and read the PR guidelines at
www.odoo.com/submit-pr
closesodoo/odoo#35491
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The decimal precision must not be dependent of the current company's decimal places. E.g:
Create a move Z in the company A where decimale precision is 5.
Switch into the company B having a decimale precision of 8.
Edit the move Z, an error can appear because the decimale precision is now 8 instead of 5.
closesodoo/odoo#35572
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Because of a whitespace character present at the beginning of the message_id of some mails,
they were fetched twice.
From the SQL side, we see that Outlook is formatting the header following the RFC822
by allowing the header to look like:
Header:<CRLF>
<whitespace><hash_of_msg_id>
From RFC822:
"Each header field can be viewed as a single, logical line of ASCII characters.
For convenience, the field-body portion of this conceptual entity can be split
into a multiple-line representation" (abr.)
It was also possible to find out by checking the logs.
One or two whitespace(s) can be seen before the hash of the msg_id.
The following commit is making sure we use and save the message_id without the whitespace
by stripping them off on the coming mail.
OPW-2006806
Applying CHS solution to avoid crash on empty header.
closesodoo/odoo#35682
Signed-off-by: bve-odoo <Abridbus@users.noreply.github.com>
Odoo Translation Bot