Before, a partner could be present several times in the list of attendees
(slide_channel_partner model). To avoid noise and confusion, a sql constraint
is added to the model to make the couple (partner, channel) unique in db.
If several exist, we only keep the most advanced one in terms of
completion (see UPG script).
Same move is done for slide activity tracking (slide_slide_partner model).
Certification or completion is considered as more advanced.
Demo data is updated as we try to create a membership that already exists
due to auto subscription of channel responsible. We also make some channel
memberships explicit as some demo data about slide completion exists.
--- Links ---
Task-2777216
Prepares Task-2508019 (Slides membership refactoring)
Also soo UPG PR - odoo/upgrade#2854
Part-of: odoo/odoo#74171
Purpose of this commit is to finalize the cleanup of current user's membership
on a given slide.
As a followup of odoo/odoo@8b2f887c29 we remove now dead ``_compute_user_info``
method. We also introduce a shortcut to ``user_membership_id.sudo().completed``
by adding its computation directly while computing user_membership_id as well
as user_vote. It allows to remove some sudo on user_membership_id.
Task-2607416
Part-of: odoo/odoo#74171
compute tax amounts corresponding to each invoice line in the edi
document for the invoice.
The issue
In Mexico, companies are required to send every invoice in electronic
format to the government. This document (called the CFDI) specifies,
for each invoice line, the taxes applicable, the amount before tax
and the tax amount. The document also specifies the total amounts
withheld for each tax which was applicable to the invoice.
The PAC (the external service which signs this electronic document
and sends it to the government) does checks on those amounts. In
particular, the tax amounts must satisfy two constraints to pass
validation:
(1) The total tax amount for a tax must be equal to the sum of the
tax amounts reported for each invoice line.
(2) The tax amount reported for each line must be equal to
(tax rate * base amount), rounded either up or down. For example, for
a line with base = MXN 398.28 and an applicable VAT of 16%, the
exact tax amount would be 0.16 * 398.28 = 63.7248, so the acceptable
values for the tax amount on that line are 63.72 and 63.73.
In v14, we used the AccountTax.compute_all method to compute the tax
amounts reported for each invoice line. This gave the exact tax
amount, rounded (either up or down depending on which side of 0.5 it
is). This always fulfils condition (2) but fulfils condition (1)
only if the tax rounding method is 'Round Locally'. Because of this,
in v14 MX users couldn't use 'Round Globally'.
In v15, we use a new SQL-based method to compute the tax amount
reported for each invoice line: we take the total tax amount, and
allocate it among the invoice lines proportionately to the base
amount of the invoice line. This always fulfils condition (1) but
sometimes doesn't fulfil condition (2). This has caused many issues
in customer DBs (see list of tickets at the end).
This was introduced in commit 433656415a and seems to be an issue
for all MX customers who have upgraded to v15.
The solution
@smetl and I have looked into what can be done about this.
Modifying the tax amount computation method in a way which satisfies
both conditions is possible, but requires more work and testing.
The existing v14 code generates tax amounts which satisfy both
conditions, at least when the tax computation method is
'Round Locally'.
A good temporary solution, while we try to modify the tax amount
computation to satisfy both conditions, would therefore be to use
the v14 tax amount computation when the tax rounding method is
'Round Locally'. While not ideal, this will at least enable
customers with the 'Round Locally' rounding method to correctly
submit their invoices to the government. Customers with the
'Round Globally' method will need to wait for the full fix.
This commit does exactly that.
Tickets linked to this problem (non-exhaustive list):
opw-2695243
opw-2733280
opw-2723571
opw-2724805
opw-2722370
opw-2722388
closesodoo/odoo#85407
X-original-commit: cddb5bc3af4806c7d1b9b09d07a5b9361d2815c0
Related: odoo/enterprise#24767
Signed-off-by: Laurent Smet <las@odoo.com>
Before this commit:
Suppose invl1 of 1000.0 with 10.0% and invl2 of -100.0 with the same tax. A tax line of 90.0 is created.
If invl1 is created before invl2, the tax details is computing the tax amounts as:
invl1 tax amount = 1000/900 * 90 = 100 (OK)
invl2 tax amount = 90 - 100 = -10 (OK)
total tax amount = 100 - 10 = 90 (OK)
If invl2 is created before invl2:
invl1 tax amount = 100/900 * 90 = 10 (NOT OK)
invl2 tax amount = 90 - 10 = 80 (NOT OK)
total tax amount = 10 + 80 = 90 (OK)
closesodoo/odoo#85406
X-original-commit: bada85c7621b45970c88548c4d09b88b77c08e8e
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
By adding the `style` attribute to the `.o_layout` element
it can be customized according to the data collected
with `themeParams`, making it possible to add a custom background color
in our template design, for example.
See b7537e1d66b4ca26e12f4be16eb1c30632ecee61
closesodoo/odoo#83701
Signed-off-by: Antoine Guenet <age@odoo.com>
Purpose
=======
Fix bug introduced in efd178daee689192d4e930a075475587038b3e0d
that created a new review instead of modifying your old one in
website_slides.
Task-2723643
closesodoo/odoo#85184
X-original-commit: f939260f9e90b58ea79197939d9644160c84a0a9
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The Stripe Connect onboarding only allows to create production accounts.
This is problematic because, before this commit, it was possible to set
the state of an acquirer linked to a connected account to 'test', even
though the payments would actually be made on the live environment of
Stripe.
Additionally, this commit fixes a minor display issue that caused the
"Connect" button to be shown when an API key was set, while it should be
hidden as soon as an API key is set.
closesodoo/odoo#85444
X-original-commit: 4f9b19b9a9891cb0c39dcb88991de174be60cef9
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
revert commit https://github.com/odoo/odoo/commit/5f25be8eef9a9efc18a995f2c6405d08a657ac96
Goal:
- Gives the expected tag to the account move line created by the PoS.
- Add tests to the PoS regarding the created account move line
Before this commit:
If the configuration was set to round_globally, a pos.order.line was processed
as a refund only if all order.lines were a refund.
This leads to unexpected results in the tax report. Indeed,
since commit https://github.com/odoo/enterprise/commit/46769076526701d96ee4f2653e44b57604cc0b7a
"Negative" line in PoS (debit) are processed as positive to give a
correct results.
This means that if a line is set as debit and is suppose to lower a
line, it makes it bigger.
Example:
aml from PoS: debit: 10 tags: +03
---> report.line [03] is suppose to make a -10 but will do a +10.
As a result, report line [03] is false.
After this commit:
PoS never use "invoice_repartition_line" to create a refund line.
closesodoo/odoo#85461
Ticket: 2718998, 2714310, 2746890
Community-pr: https://github.com/odoo/odoo/pull/85149
X-original-commit: e4dedaf08b41cf3d80bfb01e70de714c9a84167d
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Brice Bartoletti <bib@odoo.com>
This commit gives the possibility to create pos_order_line with discount
This is needed in order to reproduce real usecase.
X-original-commit: 49bfb576a76e2ad4449326c4b12ebf57bece7069
Part-of: odoo/odoo#85461
Steps to reproduce:
- Install website_appointment module
- Change website theme and select : Cobalt Theme
- Go to website
- In menu, click on Appointment
- Select anyone, select any date and confirm appointment
Issue:
Title text on each other.
Cause:
The custom page_header class (in portal module) override the default
line-height with 2.1 rem (instead of 1.1).
In some themes, the headings tags font-size has been changed with
3.875rem (instead of 2.5rem).
=> font-size is too big regarding the line-height
Solution:
Remove line-height rule.
ref. commit: https://github.com/odoo/odoo/commit/86ab1c55b4229afb74f630b5041a8354c705f849
opw-2745485
closesodoo/odoo#85453
X-original-commit: b84d9597df1be89ba418c7969a2cf8c632eb8316
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Since PR odoo/odoo#78857 , the TOTP authentication support is broken
when used inside either Android or iOS mobile apps.
Due to our inability to update the iOS app (following review from
Apple), this commit aims at restoring the bare minimum requirements to
make the current mobile apps (specially iOS but also Android)
authentication workflow works.
As extended explanation:
- Set-Cookie header is expected to be sent even when session_id hasn't
changed (iOS specific).
- Successful credentials check on `/web/session/authenticate` expect a
successful response with a result containing `uid` set to `null` to
mark the need of an additional totp handshake (both platforms).
closesodoo/odoo#85463
Signed-off-by: Julien Castiaux <juc@odoo.com>
Steps :
Install Project and Dashboard.
Project > My task > Favorites (search zone) > Add to Dashboard.
Notice you can drag task between stages.
Issue :
Dashboard > Notice you cannot.
Cause :
m2m groupby normally (in kanban_renderer.js) does not allow drag.
project_kanban overrides its _setState() method to allow it for parsonnal
stages, because they "become m2o" with a user.
Yet, in the dashboard, we pass through the default method, because the
wrong view is created.
Fix :
Take into account the js_class in the arch to create the view.
opw-2752072
closesodoo/odoo#85033
X-original-commit: 4d864c05dfa8f9be25d41bbae318f75a61d0cde2
Signed-off-by: Géry Debongnie <ged@odoo.com>
Steps to reproduce the bug:
- Go to settings and enable “External Email Servers” option
- Go to accounting > Configuration > journals
- Create a new journal, Choose "purchase" type
- save
- Go to advanced settings tab > click on email alias
- Note that default value = `in_invoice`
- Create another journal, choose "Miscellaneous" type > save
- Change the type to "purchase"
Problem:
the default value = "out_invoice", because it is not updated in the write function after changing the journal type
In the case of type == 'purchase', the default value should be 'in_invoice', and in any other case, it should be 'out_invoice'.
opw-2618357
closesodoo/odoo#85292
X-original-commit: c86b1e5a46b5923136fa920a8bb4fc1c8bd31c2d
Related: odoo/enterprise#24708
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, the `doc_count` field is defined into the kanban
view of `project.project` model but it is never used. Since it is
defined into the view, the compute of this field is unnecessary
called.
This commit removes `doc_count` field in the kanban view of project to
avoid computing the view since this field is never used.
closesodoo/odoo#85405
X-original-commit: 3c62c4aad5cecb9cc305925ca76ef24d375f5a09
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
###To reproduce (V15):
Video:
https://drive.google.com/file/d/1wCebPCVQMXmQk7G4CIMkh1MbZ89HW9ek/view
1. Install the module "Product Availability" ("website_sale_stock")
(that will install ecommerce & stock)
2. Choose a theme for the website (like developement)
3. Uninstall website
=> Internal server error
```
Exception: Unallowed to fetch files from addon website
Error when render the template
Exception: Unallowed to fetch files from addon website
Template: web.frontend_layout
Path: /t/html/head/t[1]
Node: <t t-call-assets="web.assets_common" t-js="false"/> - - -
```
###Analysis:
The assets and view should in theory be deleted in cascade when
the websites records are uninstalled.
However, if a website record fails to be removed,
for instance - in this case - because of pricelist which have an
`ondelete=restrict` PSQL constraint on its `website_id` field.
The PSQL cascade constraints on the other record are dropped
before being applied which result in the resource being still
there but not usable.
Note: this issue is not specific to the website app in particular.
It's just not worth to think for a more sophisticated way to fix
this issue in a stable version.
OPW-2700476
closesodoo/odoo#85443
X-original-commit: ef5296ab32426422698b763c33b2ddb5d0da6cc6
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit display rating average percentage in project update right
side panel view's rating stat button instead of just displaying
rating_avg_percentange field's value.
task-2732325
closesodoo/odoo#82859
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
These changes have been made:
- Each account name now starts with a upper case letter. This was change to be more coherent with the other localisation
- There was too much account that allowed reconciliation. Only some should so we have change that (in particular, receivables and payable accounts)
- We have added tags to account to more easily manage the control domains. By doing so, the control domains can be more precise about where the error lies
- We have change the type of some account. Before that there was too much 'Current Assets' or 'Liabilities' without distinction for 'Fixed Assets', 'Equity', 'Off Balance'...
It also contains a local migration script to update current installation of the Chart of Account by adding the tags.
task-2468834
closesodoo/odoo#84857
X-original-commit: 534c0384ff64ef141168ee2dd4152116ae0287f8
Related: odoo/enterprise#24498
Signed-off-by: Olivier Colson <oco@odoo.com>
In reality the separator is a comma instead of a dot as can be seen
in the code a bit further below.
closesodoo/odoo#85396
X-original-commit: 2a6e9f166d493aaefc006e949ab45e42311ac886
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
On most of the cases, the fine-grained reactivity is bypassed by:
- Setting the optional `deep` argument as `true` on the renderer
function. This will force a render to update all child components.
- Changing some objects from reactive to non-reactive using `toRaw`
function.
Part-of: odoo/odoo#84314
Co-authored-by: Géry Debongnie <ged@odoo.com>
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#85001
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* Split python file by classes
* Remove empty ir.model.access.csv file
* Correct name for views file
* Use setUpClass instead of setUp to avoid multiple setups during tests
Part-of: odoo/odoo#85001
When unbuilding a MO, if the latter has several lines (in its
components) for the same tracked product, it won't work.
To reproduce the issue:
1. Create two storable products P_compo and P_finished
- P_compo is tracked by USN
2. Update P_compo's quantity to 2
3. Create a MO:
- Product: Finished
- Quantity: 1
- Components:
- 1 x P_compo
- 1 x P_compo
4. Process the MO
5. Unbuild the MO
Error: a validation error is displayed while it should not "The serial
number has already been assigned: Product: P_Compo, Serial Number: C01"
The for-loop in `action_unbuild` do not handle the case where there are
several SMs for the same product. In the above case, there are two
component lines for P_compo, so there are two SM in `MO.move_raw_ids`.
When unbuilding the MO, the module creates and processes two SMs (SM01,
SM02) that "produce" two P_compo (stored in `produce_moves`).
When processing the first one in the for-loop, it takes the original
moves (so the `MO.move_raw_ids` with the same product) and uses them one
by one. Since SM01 needs one P_compo, it uses the first SM of
`MO.move_raw_ids` (and reuse the lot of that SM). Later on, when
processing SM02 in the for-loop, it does exactly the same thing: it
takes the original moves and uses the first one. Here is the issue: this
first SM has already been used and so does its lot, so this SM should
actually not be used again.
OPW-2715155
closesodoo/odoo#85354
X-original-commit: 8d2597965202a76ddeea8d8fed60b7ac014e2df8
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Currently in kanban view of the notes, if there is long content without space
(for example a very long URL), the content goes out of the kanban card.
This commit improves the behavior by breaking such content into multiple
lines and thus displaying full title on the kanban card.
taskID-2754915
closesodoo/odoo#84607
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
PURPOSE
Before this commit, the headers for the eLearning module were fixed
(Odoo purple gradient or images), and did not always fit with the color theme
chosen by the users. This commit enables the customization of these
website_slides headers for homepages as well as courses and lessons
(on a per-course basis).
SPECIFICATIONS
This commit replaces the channel and lesson headers with `Cover` snippet, so
that they are customizable (by channel) with the website editor. The
customization includes background, additional filter, text alignment, and text
alignment.
The banners for categories of channels ("All courses", "Certifications", and
"My courses") are now also customizable, and other website blocks can be added
above and below them.
Before this commit, the static header background for courses was updated to a
different color palette for certification tracks (`website_slides_survey`).
With this commit, the aspect of the header will no longer be different when
a survey is added but keep the customization (or default value for courses).
The `o_wslides_gradient` class is now obsolete and is renamed to different
labels depending on its remaining local purpose.
The default aspect of courses and lesson without images is therefore switched
from the Odoo purple to the theme background color.
LINKS
Task-2516830
closesodoo/odoo#78257
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Sometimes the refresh_token is not saved in the db because the code
after it fails (timeout). We also want to avoid 2 processes
trying to renew the token at the same time (=> avoid desynchronization
of the refresh_token)
So, we added a locking mechanism and do a commit after we refresh the
token.
- If we have very big invoices to receive, they do not get imported into
the database. At the moment we risk timeouts.
Our solution is to do a lot of intermediary commits and we link it
to a temporary account_move before doing the import logic and maybe
putting it into the definitive one.
closesodoo/odoo#85372
X-original-commit: ce47d09c05e4bcc91ee4de68db3a7a471bcb4df8
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
Fine tuning of commit 6acfb2e
It correctly merge the purchase.order in case of direct link and
avoid to relaunch the procurement.
It also correctly set the created_production_id if the demand come
from a SO
closesodoo/odoo#85301
X-original-commit: 9b6fa6c3db55daa3533c0d5cb13da7c98fc3e936
Signed-off-by: Arnold Moyaux <arm@odoo.com>
The query added by 6c207ed1027d9b39eecd19886932b17f1a79dccd is not
optimal. Avoid using `LEFT JOIN` and `OR` by doing 2 queries and adding
their results.
From local tests, a `search_read` on `project.project` is about 4x faster:
2400ms -> 600ms.
closesodoo/odoo#85365
X-original-commit: 0235f2ded8ef6478ed36e2d8ba1c46acef5f1dab
Signed-off-by: Christophe Simonis <chs@odoo.com>
Previous refactoring: odoo/odoo@3b06565 switched move_line.product_qty
to move_line.reserved_qty. This line was missed during the refactoring
so we fix it now.
closesodoo/odoo#85355
X-original-commit: 624c155e77ae1d3fa964a949f17b4d8c73e9b35d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
When checking if the powerbox should open, we check the selection but
that was done on the global document, which returns a wrong selection
for the editable if it's in an iframe. As a result, the powerbox never
opened in mass_mailing.
task-2778414
closesodoo/odoo#85352
X-original-commit: d5b8c26c46b1daf795a6b286af80bb4dad8072ff
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet <age@odoo.com>
*: website_sale_coupon, test_apikeys
The do_search_read method was only used in a single place: the
search_read controller, whose entire function body was just a function
call. The content of the do_search_read method has been moved to the
search_read controller.
The search_read controller is still pretty useless: it's basically
equivalent to making an RPC on a model and calling the method
web_search_read. As such, this controller should be removed, but lots of
code depends on it and adapting all the code that uses it is out of
scope for this PR. It will hopefully be removed alongside the legacy
views in the webclient (which are its main users).
The call_common method and /web/dataset/load route are completely
unused.
The /web/dataset/call controller is used in only two places and can
trivially be replaced with a call to /web/dataset/call_kw
The non-route methods were removed and the route methods now emit a
deprecation warning telling the user what to use instead.
closesodoo/odoo#84811
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
If a report contains a t-if with something like `field in ('a', 'b')`
as a condition, a crash occurs if you try to modify the 'Visible if'
field in the report editor because the domain editor doesn't support parenthesis.
This commit adds this compatibility based on the case of `[]` which is essentially the same thing
opw-2738343
closesodoo/odoo#85331
X-original-commit: bd76793397cb88e12fce4ffc886eefbce0b54975
Related: odoo/enterprise#24722
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Achraf <abz@odoo.com>
Noe Antoine