Getting the `res.company` record by browsing the `company_id` cached
value from `website` instead of reading it directly on the website
record will avoid a read on the website table.
While this might seems unusual and not elegant, since this is a very
low level method used to render every view, it seems fine.
task-2774979
X-original-commit: bc643a573a7339c82661cbcff2cc59bdd0eec3e3
Part-of: odoo/odoo#85456
We can easily avoid a read on the website table when serving the
homepage by simply caching the website.homepage_id value and then
browsing the record (no query needed) instead of reading it on the
website record.
While this code is not really elegant, it seems like a good tradeoff to
gain a query on this particular homepage serve controller, which is the
main entry point of a website and generally the page the more often
served.
task-2774979
X-original-commit: 69b443b85656c895c66a1f83b235f5d1e53727d4
Part-of: odoo/odoo#85456
* website, website_blog (perf)
If the source values is only composed of empty elements (list of `None`
values), don't try to translate it, as there is nothing to translate
anyway.
While the translation method being called (xml_translate,
html_translate) won't be costly as they will return instantly if the
provided value is falsy, there is still an SQL Query made to get the
callable translation method, which we won't actually use.
This commit avoids that query if we already know we won't do anything
with the translation method.
task-2774979
X-original-commit: e1eb5a6e1610a9550a59ba229a83b9e70e10aa88
Part-of: odoo/odoo#85456
Install website, create a custom web page, we'll call it page_1. Ensure
you are not in debug mode (go to /web/health?debug=0 to disable it).
Open the web page enabling the debug-mode /page_1?debug=1, the page
opens but the debug mode is disabled.
Because web pages are served using another routing mechanism than
controlers we have to ensure we load the debug query-string in those
mechanisms too.
closesodoo/odoo#85340
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Some flows were broken in httpocalypse, sadly those were not tested.
X-original-commit: 6161987c94544162de16eb2544295d152f123d17
Part-of: odoo/odoo#85340
Install the website_sale and open '/shop/whatever-9999' in your browser,
the response is a 500 Internal Error instead of a 404 Page not Found.
Because `request.endpoint` has been murdered by the httpocalypse, we
must re-match to get the endpoint later used to re-build the URL. When
an URL contains a record-id but that record does not exists, matching
the URL will raise a `odoo.exceptions.MissingError`.
Part-of: odoo/odoo#85340
* remove unused delay column (there was no field using the value server
side)
* remove unused joins in the FROM part of the table definition (join on
pricelists)
* fix broken inheritance API
pos_sale inheritance adds a null value for fields not available added in
sub modules (website, invoice_status, ...). But this was only working
because the default value of the fields parameter of the _query method
was overridden to a dict in all overrides, filling the record while
climbing the inheritance chain.
This was clearly too magic, using information provided higher in the
inheritance chain, assuming you were calling the super before generating
the pos part of the query.
This commit cleans the methods and API of the model, providing clean
hooks and reducing the mess of values given in overrides of _query.
closesodoo/odoo#85125
Related: odoo/enterprise#24626
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Multiple refactors
- The module pos_hr had two attributes `cashier` and `employee` referencing to the same actual person. The `employee` attribute was removed for the sake of `cashier`.
- Refactor of the `useSelectEmployee` which returned functions that where used in two components. Instead, a mixin class was implemented and inherited from both components.
- Renaming of the substring `client` and `customer` to `partner` (css included) when it was referencing to the actual `res.partner` object. This way, developers will always know that the object used in the UI is coming from `res.partner`.
- Renaming of the substring `client` to `customer`(css included) when it was referencing to a real life person. This avoid having ambiguity since the term `client` can refers to multiple things (hardware, browser, person, ...)
closesodoo/odoo#83983
Related: odoo/enterprise#24477
Signed-off-by: Masereel Pierre <pim@odoo.com>
Currently, a service can be configured to be invoiced on milestones.
This means that the user has to manually update the delivered quantity on the SO in order to invoice it.
We now also have the notion of milestones in the project module.
It would be nice to have a link in between the milestone and the corresponding SOL, so that the delivered quantity is automatically updated when the milestone is reached.
This would help the users save time, limit the risk of error and reduce the confusion of having unrelated milestones at two different places.
To this end, this commit adds a new "milestones" invoice policy that computes the delivered quantity of a SOL based on the milestones that have been reached, and renames the previous "milestones" policy into "manual".
Task-2558889
Closes https://github.com/odoo/odoo/pull/81684closesodoo/odoo#81684
Related: odoo/upgrade#3265
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The `product.template` service policies that do not involve timesheets should be available with `sale_project` and without `sale_timesheet`.
This commit adds the `service_policy` field and moves those policies to `sale_project`.
It also moves the `allow_billable` field on project.project to `sale_project`.
Task-2558889
Closes https://github.com/odoo/odoo/pull/81684
Part-of: odoo/odoo#81684
- Log the traceback when a proxy request raises an exception.
- Don't log the traceback returned by the proxy when an exception is
raised on IAP.
closesodoo/odoo#85503
X-original-commit: 529608eb12082463648ded5b46e40d8ce03aab53
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Current behavior:
In a multicompany environement when you create a sale order and go into other info tab
you could see all the salesperson in the Saleperson field even if they were not part of the selected company.
Steps to reproduce:
-Get in a multicompany environement
-Create a saleorder
-Go in other info tab
opw-2714085
closesodoo/odoo#85498
X-original-commit: 07ef7cc0a35313f98336f6b1d28fc9424c937c33
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
- Three controllers were actually useless as the relevant public methods
of the web_editor.assets can be called directly via RPC in the related
usecases.
- Review the web_editor.assets model methods organization in the model
declaration.
closesodoo/odoo#85392
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, the 'none' state was not considered as a possible
attendee state for the microsoft, and it created an empty field in
Odoo.
This commit maps the 'none' state to the 'needsAction', based on the
microsoft documentation.
opw-2694644
closesodoo/odoo#85367
X-original-commit: 1fbd14728980bfabc466efeb437f9f7ce105dfac
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
How to reproduce the bug:
- Install POS and data_cleaning
- Create 2 customers and set loyalty points
- Select both customers and merge them
- Once the merge is done, the loyalty points have not been summed
Bug:
When you merge 2 contacts that have both loyalty points, the resulting
contact won't have the sum of the 2 source contacts. Instead of that,
the resulting contact will only have the points of one of of the
contact.
closesodoo/odoo#84739
Opw: 2686208
X-original-commit: 56efd70e5c0e10302990d14730d801d3720f630e
Related: odoo/enterprise#24445
Signed-off-by: Simon Goffin <sig@odoo.com>
Signed-off-by: Minet Adrien (admi) <admi@odoo.com>
When setting up an acquirer there is sensible information to
be supplied.
There was inconsistency on what was obfuscated and what not.
Now sensible information as passwords and keys is obfuscated
and public information as names and addresses is visible.
Task - 2694139
closesodoo/odoo#81211
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Step to reproduce:
- Switch language to arabic
- Go to Time off
- Click on 'New TIme Off'
Current behaviour:
- Traceback
Default date_from and date_to are given in arabic which cannot be parsed by the field
Behaviour after PR:
- Default date_from and date_to are given in english and then translated via the field
opw-2755258
closesodoo/odoo#85495
X-original-commit: f0c457607521bc6a8b8a682bd4851029e63249b8
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Reproduction:
1. Start the process to buy (register) 2 tickets for an event
2. Go back to “review order” and reduce the quantity to 1
3. Sign up with a new portal user and create an account
4. Change the number of tickets to 2
Reason: the seats_expected in event.event has a different computation
logic from the attendee_count in sale.order. In event.event, the
seats_expected does not count canceled registrations. In sale.order, the
attendee_count counts the canceled registrations. But they are both
shown as "Attendees" in the statinfo widget of form views
Fix: Added a domain condition to filter out canceled registrations when
computing attendee_count in SO
opw-2739310
closesodoo/odoo#85491
X-original-commit: 88fecdc4966dfba2a3f65bc2a8f139e7ee025d15
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Whenever making a refund for a transaction with a saved token
the token will appear also on the refund transaction.
It is useful to keep track of which token was used in each
transaction, this remains true for refunds.
The token will also appear on the payments.
Task - 2694760
closesodoo/odoo#85484
X-original-commit: 351812a81ec29fe96bf3766c45ea3b51f4055066
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The generic tax report in V15 need the tax line for each tax to be computed correctly.
Currently the tax line for 0% tax will not be generated for a journal entry generated
from the point of sale and will not be taken into account in the tax report.
Now we will generate this tax line. This is basically a reverse of 0ddfbab90f
removing generation of 0% tax line because it could cause issue if no account is set on
the tax. This case is now handeld by 4f7061dcb402ed56d56c51de35edf747d0684a8d.
opw-2754107
closesodoo/odoo#85454
X-original-commit: 1e846844348107d5d0d1e46b5911b883bd088b4e
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Adds a class on the notebook page in order to create a JS tour for
`hr_payroll`.
closesodoo/odoo#85471
Taskid: 2661217
Related: odoo/enterprise#21559
Signed-off-by: Kevin Baptiste <kba@odoo.com>
PURPOSE
Improve documentation design in eLearning frontend. Fix and improve
publisher tour(s).
Prepare attendees status improvements.
SPECIFICATIONS: LAYOUT
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);
SPECIFICATIONS: CONSTRAINTS
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.
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.
SPECIFICATIONS: SLIDE ATTENDEE VIEWS
Purpose of this spec 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.
SPECIFICATIONS: OTHER
Fix publisher tour and add a standard tour (not using video / youtube to be
reproducible). Provide various fixes and improvements.
LINKS
Task-2777216
Prepares Task-2508019 (Slides membership refactoring)
closesodoo/odoo#74171
Related: odoo/upgrade#2854
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to add a publisher tour in standard that is not
only run using external tags. Indeed external tours are not monitored and
previous commits show that they can be broken since a long time.
In this commit we somehow copy the publisher tour with an article-based
slide instead of a video slide. That way it can be launched with other
standard tours.
Task-2780920 (eLearning: fix publisher tour)
Part-of: odoo/odoo#74171
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>
Romain Derie