In 12.0+ when adding an XI (Northern Ireland) VAT number on a vendor and specifying the country as United Kingdom, an error shows the VAT number as not valid. This is because the method to check specifically XI VAT numbers doesn't recognize XI as a country, and thus uses the GB VAT number verification, which doesn't recognize XI VAT numbers as it isn't up to date yet.
A temporary method to check XI VAT number was already added, but is never called because XI is not recognized as a country code.
With this commit, we add a list of known legitimate country codes, that are not considered as such in Odoo.
opw-2534541
closesodoo/odoo#75399
X-original-commit: 3a1671470b71892dba3eade8f861faaa9689713e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: pvh-odoo <SwagSamaSempai@users.noreply.github.com>
When there is a bill to ship to and ship to is the third party then GSTIN is set from customer address(partner_id), not from shipping address(partner_shipping_id)
closesodoo/odoo#75400
X-original-commit: c7e0229dd3229a5a79c4a32fc02eab3fad98fccd
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before this commit, User was allowed to delete repair order which
is linked to posted invoice by moving it to Draft.
With this commit, user is not allowed to delete repair order linked to
a posted Invoice.
closesodoo/odoo#75109
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
This commit improves action helper message for visitors menus of
website and removes old action helper message from visitor menu
of livechat for better onboarding.
Menus
1) Visitors(action -> website_visitors_action)
Task-2584073
PR odoo/odoo#74082
Related: odoo/enterprise#20125
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
As nicely pointed by @kig-odoo at [1], the new feature of snippet
visibility conditions introduced in [2] has some issues. This fixes
the fact that condition identifiers were built by combining IDs without
a separator. A condition targeting a lang with ID:4 and another one with
ID:5 could thus produce the same condition identifier as another
condition targeting a lang with ID:45 (as 4 and 5 side-by-side makes
45...). Now, all parts of the identifiers are separated with '_'.
[1]: https://github.com/odoo/odoo/pull/67140#issuecomment-902531321
[2]: https://github.com/odoo/odoo/commit/1c442782f887a8c16bae05a43fae13a310ac05dfclosesodoo/odoo#75386
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Revert "[FIX] crm: allow regular salesman to convert and merge opportunities"
This reverts commit 24db93c0e6b88f89fdf03d63afee05fc858ed977.
Indeed adding a sudo at the end of merge process is a strange way to fix
an unexplained issue about "similar emails". CRM code has been cleaned
since v14+ and flows should not gain random sudo trying to solve an
undefined problem.
closesodoo/odoo#75385
X-original-commit: b4fa19376eb50bf07b5753b4664fcad4d637bcec
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since the latest OWL refactoring, "button" DOM element in tree views cannot
be defined without an associated action (it will crash on click).
In the survey module, we use a "fake" button to mark a question as conditional
(based on the answer of another question). The button functions as a simple
icon and has no attached action.
To fix the issue, we now mark the button as "disabled" so the click action will
not trigger anything.
Task-2618108
closesodoo/odoo#75158
Related: odoo/enterprise#20049
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the newsletter popup was using its own mechanism instead of
the popup snippet, making a lot of extra code.
Now, the newsletter popup snippet just use the behavior of both the popup
snippet and the newsletter snippet.
Community: https://github.com/odoo/odoo/pull/74667
Upgrade: https://github.com/odoo/upgrade/pull/2742
task-2246975
Steps to reproduce the bug:
- Go to CRM and create a team.
- Create 2 Opportunities and assign them to the created team
- Put a date in the past for 'Expected Closing'
- Mark one of the opportunities as won
- Go to CRM > Sales > Teams
- You will see that the number of overdue opportunities is 1 but when clicking on it, it shows 2
Problem:
As an opportunity is in a stage with "is_won= True" so it was won (Probability 100%).
It should not be displayed with the overdue opportunities
Lost opportunities should not be displayed also.
Solution:
Opportunities won or lost have a closing date, so we can use this field to filter them:
https://github.com/odoo/odoo/blob/14.0/addons/crm/models/crm_lead.py#L590-L591
opw-2590471
closesodoo/odoo#75376
X-original-commit: b699c3e28c4cf745a91eb29bf5c85c429d152335
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since Odoo 14.0 flag image is not a binary field anymore [1] and field name is
changed to `image_url`.
So, fix it by using the url directly.
STEPS:
* Flag image is used when user country_code is provided and there are events for
that country. The user country_code is computed by IP. If you run Odoo locally
you can temporarly update `get_country_events` to force some country code
* In a website page add a header-title block first, then add the dynamic snippet
"Events"
BEFORE: dummy image "no photo yet"
AFTER: flag image
---
[1] https://github.com/odoo/odoo/commit/710705b64c0134a5b568d998d0a3eb0df0f541c0
opw-2625695
closesodoo/odoo#75374
X-original-commit: ae8403d08d1877ec35cc25d3eb6ac61cfee20919
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Rename website_calendar module by appointment in order to match
the changes on the enterprise part.
We now no longer use the website module to manage the basics of
online appointments. The portal module is now used in its place.
For additional info, check the enterprise PR.
task-2427015
closesodoo/odoo#72241
Related: odoo/upgrade#2492
Related: odoo/enterprise#18426
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit when user quick create a certification,
then it will create record in survey but not with certification
equals to True. Due to which it will be excluded from domain and
we will not able to find it in survey_id in elearning.
With this commit we pass certification equals to true and scoring_type
equals to scoring_without_answers in context of survey_id. So now,
it will be not excluded in domain('certificate', '=', True) in elearning.
Task Id: 2621296
closesodoo/odoo#75375
X-original-commit: 47894929591c7f46451242c1d0368094e2b3c295
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When creating a meeting from a partner/lead, the invitations won't be
created/sent
To reproduce the error:
1. Open a lead
2. Click on Meeting
3. Create a meeting
- On meeting creation, directly click on "Create", not "Edit"
Error: No invitation has been sent. When editing the created event,
there isn't any invitation on Invitations tab. Same error will happen
when opening the form of a customer instead of a lead (step 1)
For an attendee to be created, the partners associated with the meeting
must be explicitly listed in the creation values:
https://github.com/odoo/odoo/blob/3e20e68f0790a0b0f3b5c4d43f59f235b7d20fef/addons/calendar/models/calendar_event.py#L710-L713
However, in the above use case, the partners identifiers are given
through the context. This explains why the attendees are not created.
OPW-2531496
closesodoo/odoo#75353
X-original-commit: a8b4f8f6c009d8abd7210973005fd755ac3bc573
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
[FIX] account: tax details: correct taxes computation when using taxes affecting base with repetition
1) Let's consider then following taxes
- tax 1, 42%, affecting the base
- tax 2, 10%
2) Create an invoice with the following lines, and post it:
- price=100, taxes=tax1
- price=100, taxes=tax2
- price=100, taxes=tax1+tax2
=> The tax details should compute the following amounts:
- base amount of tax 1: 200
- tax amount for tax 1: 84
- base amount of tax 2: 242
- tax amount for tax 2: 24.2
Before this fix, the base amount for tax 1 wasn't computed properly, and gave 300 instead of 200. This was because the same tax line (the one from tax1 with no tax_ids) was matching two different base lines: the one with tax1 and tax2, and the one with only tax1.
closesodoo/odoo#75317
Related: odoo/enterprise#20356
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
*: website_sale_comparison_wishlist, website_sale_stock_wishlist
This fixes problems introduced with [1].
The config setting to continue selling even with no stock was always
shown as true, even if it was false.
Also, this reindents wrongly indented js files and improve them.
[1]: https://github.com/odoo/odoo/pull/68221
Related to task-2458165
closesodoo/odoo#74917
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Slight inconsistency, you could have a view location type not update
when the usage was changed to or from view (the hierarchy would be
shown which should not be the case).
opw-2619043
closesodoo/odoo#75338
X-original-commit: 857ab57756e19525681f0abd36e7f07144f56eed
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When loading calendar views, the client tries to load 'unusual' days,
linked to the employee of the current user. But it does not check that
the current user is linked to an employee for that company.
Closesodoo/odoo#75305
Task ID: 2628736
Signed-off-by: Kevin Baptiste <kba@odoo.com>
If the analytic account have not company then the analytic entrie
would have the company of the account move
closesodoo/odoo#75275
X-original-commit: 3d3e6ddd3383f2e35c254744c9ee5b90c224251b
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
The algorithm extracting primary and secondary colors from
an image automatically mitigates too bright colors. A color
component is considered as too bright if its value is above
an arbitrary value. We re-use this algorithm in the website
configurator to extract colors from logo and to generate a
palette. In this particular case we don't want the mitigation
to be applied. We therefore added the mitigation threshold as
a parameter of 'extract_image_primary_secondary_colors' and
avoided any mitigation by setting it to 255 in our case.
task-2602521
closesodoo/odoo#75255
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The UserError was inadvertently removed and replaced by
`google_pse_id_is_set` variable, which is a boolean.
closesodoo/odoo#75298
Signed-off-by: Valentin Chevalier <chevalierv@users.noreply.github.com>
If the prefix of the production sequence contains some dashes, it can
lead to undesirable behaviors
To reproduce the error:
(Enable debug mode)
1. Settings > Technical > Sequences & Identifiers > Sequences, edit "San
Francisco Sequence production":
- Prefix: "WH-MO-"
2. Create a MO
- Quantity: 2
3. Confirm, Edit:
- Quantity: 1/2
4. (Keep MO's name in mind and) Validate + Create backorder
Error: Backorder's name is "WH-MO-002" instead of "WH-MO-0000X-002".
Going back to the initial MO, its name became "WH-MO-001" (was
"WH-MO-0000X")
OPW-2618971
closesodoo/odoo#75270
X-original-commit: 076fe045f219dcb018b3b18215bfc3a0cfb3aa46
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
When creating a new task the name field was not automatically focused.
closesodoo/odoo#75271
Taskid: 2585999
X-original-commit: a1f4cc03bc4df556f9a832a91d47f1c3727ab115
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This reverts the following commits:
- 164409b00106a5f91d8b84ac698f4cf2aebedb91
- f11c807217cccd96fa18fe24c0cbb436bb1830d1
- c92ebc91e261827dfafa602eae5408de2a072609
The fix we initially made did not cover every possible scenario,
and applied to every fiscal position, which was not required.
It requires a more in depth rework that is under way
and will come in a future PR.
closesodoo/odoo#75284
X-original-commit: d470f2b4fbc7440d19d07268980394909c47ee22
Signed-off-by: Florian Gilbert <FlorianGilbert@users.noreply.github.com>
If an internal user does not belong to Sales / Administrator group, and wants
to convert a lead into an opportunity, he will face an access rights error if
another lead exists with the same email because we are trying to merge them.
We should allow him to convert and merge them without error.
closesodoo/odoo#75283
X-original-commit: 24db93c0e6b88f89fdf03d63afee05fc858ed977
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
When selling a tracked product, if the latter has already been sold
once, the source location of the associated stock move will be
incorrect.
To reproduce the error:
1. Create a product P
- Product Type: Storable Product
- Available in POS: True
- Inventory: By Lots
2. Update P's quantity > 0 with lot L
3. Start POS session
4. Sell one P with lot L (Register payment + Validate)
5. Repeat 4
6. Go to Inventory > Reporting > Product Moves and apply one filter:
- Product: P
Error: There are 3 product moves:
- One from Inventory adjustment to Stock
- One from Stock to Customers
- One from Customers to Customers
The third one is incorrect and should be from Stock to Customers.
Because of the first sale, a `stock.quant` is created and indicates that
one P from lot L is at location "Customers". When selling the second
one, because of the OR-condition, this `stock.quant` is selected. The
condition should be an AND-condition.
This fix is an improvement of #69750. The new test checks the above flow
and the one described in the related PR.
closes#71435closesodoo/odoo#71573closesodoo/odoo#75265
X-original-commit: e0921851a1f1a636169e62f47b4d4c32255f98ed
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
In a multi-currencies environment, if the user creates an expense with a
different currency than the company's, one of the associated account
move lines will have an incorrect base amount.
To reproduce the issue:
(Need account_accountant. Let USD be the company's currency)
1. In Settings, enable "Multi-Currencies"
2. Edit the currency rates:
- EUR: 2
- USD: 1
3. Create an expense:
- Currency: EUR
- Unit Price: 700
- tax: 15%
4. Create Report, Submit, Approve, Post Journal Entries
5. Accounting > Reporting > Tax Report, This Financial Year
6. Audit of "Tax 15.00%"
Error: Base amount of the expense is $700, which is incorrect. It should
be either 700€ or $350
OPW-2613547
closesodoo/odoo#75264
X-original-commit: d6fd7301291dfe3ffd58d33edb3f2c4270e3b8a1
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Steps to reproduce the bug:
- Go to Expenses > Expense Reports to approve
- Select expense reports with different managers
- Click on the Action drop-down button > Approve report
Problem:
Traceback is triggered because we try to access `"self.user_id"` (manager) of expenses as a single element,
While we have several `”user_id”`
Solution:
- Filter the `"hr.expense.sheet"` which must be approved
- Approve each expense separately
opw-2622837
closesodoo/odoo#75212
X-original-commit: e7299b7d0f081fa861d4b25cc76d5b0d5dab4b73
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
PURPOSE
Purpose of this merge is to provide some cleaning in mail application notably
targeting mass mailing and failure management.
SPECIFICATIONS: FAILURE TYPES
Currently there are differences between mail and sms error management
especially when sending them in batch (mass mode). Moreover cancel
(ignored) and error (exception) states meaning is not clear. Finally
some failure types management between mail and sms can be cleaned.
Meaning of ignored / error we want to enforce now is
* error: there was something wrong at sending and user has an action to
perform, i.e. server failed -> check its logs;
* canceled: invalid recipients due to contact information or mailing
configuration (blacklist, opt out, void or invalid email or phone number).
In indicates issues linked to records themselves;
In this task we also add failure information granularity on mailing traces
linked to email like what is done currently on SMS. This can be related to
mailing (blacklist, optout, duplicates) or related to recipient (no recipient,
incorrectly formatted).
We also correctly distinguish optout from blacklist when sending SMS.
Detect and store failure types directly on mail.mail: blacklist, optout,
duplicates, missing email, wrong email, ...
State computation is moved from mass mailing to mail. It is also improved as
currently everything is based on "first recipient found". This is globally
valid for mass mailing who uses default recipients (customer). However when
dealing with generic mailing this is not true anymore.
We choose to store and update status on mail.mail records only when having
a single recipient. When several recipients are defined on a given mail.mail
we cannot really decide a status prior to sending it and skip this computation.
Mass mailing override now uses information from mail.mail to update its linked
traces as computation is now delegated to base composer model.
SPECIFICATIONS: TRACE STATUS MANAGEMENT
In this merge we clean the way trace state is managed. Currently it is a
computed field based on several datetime fields. However this generates a
lot of noise in the table as well as unnecessary computation
* there are several columns (one for each state) storing datetime at
which status was reached. Generally only 2 or 3 contain relevant
information;
* state could be set in code directly to avoid a computed field based on
many triggers;
* recomputing it each time a date changes is not necessarily necessary;
* state value can always be updated manually as this is main done through
some automated server update (mailgateway, link clicks, ...);
As trace states and its triggers should not be updated manually it is better
to synchronize it in code flow. When there is an exception or update done
through sending or gateway status is updated as well accordingly. Various
datetime fields are also updated at the same time. In order to align with
notification model mail and sms trace status are updated to a classic field.
Only last status update is now kept as there is no need to store the entire
history of status change.
We keep only a datetime for relevant metrics: open, reply and click. Other
datetime bring no real value. Knowing when a trace was in error or bounced
is not necessary. Indeed exception generally indicates a server issue (at
sending), cancel indicates a data issue (at sending) and bounce depends on
customer email server.
Status update is removed as using write_date is sufficient. Once created
traces are updated only when an external event occurs (opened, replied, ...).
It allows to simplify trace model.
We also rename ignored field into canceled to match naming use through mail
and sms.
VARIOUS
Improve code readability by renaming some failure type keys, notably those
used in mail application.
Improve user experience by correctly contextualizing trace display when coming
from a mailing.
Improve user experience of report model build on mailing traces.
See sub commits for more details.
LINKS
Task ID-2377974
closesodoo/odoo#61467
Related: odoo/upgrade#1907
Related: odoo/enterprise#14633
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Philémon van Helden