Since "I don't know" image selection tour is broken as the current image
selector is quite different from the time this tour was run. Update it to
use an external URL as it seems we don't have any default image anymore.
Task-2780920 (eLearning: fix publisher tour)
Part-of: odoo/odoo#74171
Followup of odoo/odoo@7b5427f6d6 where a frontend form was updated but
not the tour using it.
Task-2780920 (eLearning: fix publisher tour)
Part-of: odoo/odoo#74171
Followup of odoo/odoo@60fadfeaf6 where navbar was updated to be responsive.
However that broke eLearning tours. Youpie.
Task-2780920 (eLearning: fix publisher tour)
Part-of: odoo/odoo#74171
Linked video is not reachable anymore on youtube. Let us replace it by
another great video.
Task-2780920 (eLearning: fix publisher tour)
Part-of: odoo/odoo#74171
Currently, in the documentation type of courses, card layout for the lessons
is broken because there isn't enough space to display everything.
To fix this, this commit moves the 'Completed' badge (which is in the card
footer) and other tags at the end of the card-body. It formats likes and
dislikes using a decimalized formatting (ex, 10000 will be displayed
as 10k).
But that improvement leads to another trouble. Say there are '1k' likes and
user upvotes the lesson. There is no indication whether or not the vote was
recorded. To fix this, we will now use different icons based on the user vote
- The thumbs-up icon will be filled if user has liked the lesson and it will
be hollow otherwise;
- Likewise, the thumbs-down icon will be filled if user has disliked the
lesson, and it will be hollow otherwise;
Clicking on either of the button, if the vote is recorded successfully, icon
and user vote will be toggled for better indication. Note that before this
commit, if user was performing the same action (for example upvoting again)
a warning popover used to appear, which isn't the case anymore because now
the vote will simply be toggled. The mechanism is somewhat similar to youtube
(you can also directly dislike the already liked content and visa-versa).
The same mechanism is also applied for likes/dislikes in the footer of each
lesson's page. And, on the same page under 'Statistics' tab, they are simply
formatted like everywhere else.
Apart from that, this commit makes other small UI changes listed
as below:
- We now display three slides per category instead of four, giving the
cards a bit more space;
- On the lessons' page, we move the likes/dislikes right after description
which previously was at bottom right of the page;
- Likes / Rating is now always displayed the same in lessen view whatever
the channel type (displaying ratings / comments / likes);
Also see odoo/upgrade#2854
Task-2607416
Part-of: odoo/odoo#74171
Co-authored-by: Munaf Bahelim <mub@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Purpose of this commit is to allow decimalized formatting of numbers when
rendering integer fields in qweb. This is done through an option and will
be used notably in elearning.
Task-2607416
Part-of: odoo/odoo#74171
When working on qweb fields it is difficult to find some custom override as
they are never in the right file. Finding them is always a bit of random pick.
Task-2607416
Part-of: odoo/odoo#74171
Purpose of this commit is to have access to slide.slide.partner model that
holds member progress on specific slide. It is used notably to build completion
on slide.channel.partner or to store vote data. It is interesting to have
access to it to have some detailed informations.
It is now reachable through the "attendees" smart button that replaces the
'views' button. Public / other views are moved in slide details as those
buttons do not add much to the slide usability.
Task-2607416
Part-of: odoo/odoo#74171
Before completion could hold about any value, even if it is generally correctly
computed as a percentage. To be sure we don't have incoherent values in db
a constraint is added to ensure completion is contained between 0 and 100.
--- Links ---
Task-2777216
Prepares Task-2508019 (Slides membership refactoring)
Also see UPG PR - odoo/upgrade#2854
Part-of: odoo/odoo#74171
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>
Thibault Delavallée