Before this commit, we asserted that the view did not switch to form when clicking
on the the color picker. It was wrong because there is no action manager, hence no possibility
to effectively switch view.
After this commit, we assert that the list view's callback selectRecord is not called, which
is equivalent.
closesodoo/odoo#96159
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With commit[1], we added `o_text_overflow` classes at several places to avoid
long names going out of the boxes. However, for the name/title fields in the
form views, we should always show the full name.
So this commit replaces `o_text_overflow` class with `text-break` from
name/title fields in the form views to display full string in the read
only mode, but also keep them from going outside of the form view.
Below are the modules affected:
- base
- coupon
- crm
- event
- mass_mailing
- mass_mailing_sms
- project
- sales_team
commit[1] - a0ebb46
task-2889845
closesodoo/odoo#96132
X-original-commit: 4a74c7af6b54bd771f50d3885813f4aae442c9e7
Related: odoo/enterprise#29552
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Add .col to the button to properly align it with the pos_config_id
field and label.
closesodoo/odoo#96113
Signed-off-by: Masereel Pierre <pim@odoo.com>
This commit fixes the product image grid not being updated after
changing a variant.
TaskId-2922057
closesodoo/odoo#96102
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
*: calendar, note, test_mail.
In order to ease testing and to prepare for the ActivityMenu widget to be
converted into a component, let's add the sytray menu item into the registry
systematically when using the start helper.
closesodoo/odoo#96094
Related: odoo/enterprise#29529
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
on/off are deprecated in favor of addEventListener/removeEventListener.
Calls to the bus service have been updated to reflect those changes.
task-2053917
closesodoo/odoo#96017
Related: odoo/enterprise#29501
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, if installing a new module from the "new content"
modal would fail, the "Building your website" gif was not removed.
This commit removes it when the installation fails.
task-2687506
closesodoo/odoo#95955
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, uploading multiple files could lead to inconsistent
results: the files array was sorted from the lower to the higher size,
but this sorted array was not used after (the unsorted one was).
This commit fixes this issue by clearly defining a sorted array, and
uploading the files sequentially, as it was done before [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#95955
Before this commit, the media dialog was not handling properly the
upload of svg files from the media library: a whole part of the original
ImageWidget was missing in the converted media dialog from [1], which
was converting the svg with the appropriate color codes from the color
palette, to allow for color customization.
See original file from 15.4: web_editor/static/src/js/widgets/media.js.
Also, it was not displaying those svg correctly with the appropriate
background.
This commit fixes those issues by adding back the code handling the
dynamic colors detection and the background css rule.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#95955
Before this commit, following those steps:
- Go to /hello.css
- Create the page/file
- View in page manager
- Click on its row
-> You're redirected to the file, with infinite loading
This commit fixes this behaviour by unblocking the iframe:
- on the OdooFrameContentLoaded event for frontend pages
- on the load event for other pages
To do that, the BlockIframe component is changed to handle process ids.
Before this commit, the BlockIframe component would count the calls to
block or unblock the iframe (and store it in an iframeLocks variable),
so that multiple processes can block the iframe independently from each
other.
As an exemple, for two processes A and B, the iframe should remain
blocked during those two processes, and released at the end:
(A) blockIframe => (B) blockIframe => (B) unblockIframe => (A)
unblockIframe.
But that iframeLocks variable was fragile: a process that blocks the
iframe should unblock it once, otherwise it would mess up the locks
count. It was not appropriate for a process that could be ended with two
events, for example loading the iframe. The first of the 'load' or
'OdooFrameContentLoaded' events should unblock it.
To change that, a process can block the iframe with a processId. The
first unblock call with the same processId will unblock the iframe, the
other ones will be ignored.
task-2687506
Part-of: odoo/odoo#95955
Before this commit, when uploading multiple files and clicking on the
cross button, the toast was reappearing every time a new file was
succesfully uploaded.
This commit changes its state so that it is only visible when one or
multiple files are added to the uploading queue. The user can still hide
it with the cross.
task-2687506
Part-of: odoo/odoo#95955
Before this commit, clicking on a different variant of a product from
the WebsitePreview client action introduced in [1] would not update the
browser's url.
This commit adds an event listener to update the browser url on hash
changes, as load events are currently handled.
The product variant buttons are directly changing the hash instead of
replacing the state of the history.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#95955
This commit aims at making the website dialog as well as the edit_menus
tour more stable.
Commit [1] introduced a new dialog API for website.
The component WebsiteDialog handles click asynchronously.
Prior to this commit, the tour could sometimes detect and click on modal
triggers before the actions that the previous trigger was triggering
could complete. This could lead to a modal closing too early either
because a click would done on the wrong modal or the input was completed
before the validation method was called (since the click handlers are
asynchronous).
Here are a few examples of possible failure in the tour :
- The tour clicks on "Add Menu Item", which should open a new modal
- The tour then clicks on OK to make sure the modal does not close.
- The click on OK is done before the New Menu Item modal is open and
therefore is triggered on the previous modal
- The modal is closed too early
- The tour clicks on OK while the URL field is empty
- Before the validation method is processed the tour inserts a value in
the input field.
- The validation method doesn't block the OK method which results in the
dialog being closed
- The tour expects the dialog to be open and crashes
- The tour clicks on OK while the URL field is empty
- Before the validation method is processed the tour inserts a value in
the input field
- The tour clicks on OK again
- 2 entries are created instead of one.
The last one doesn't crash the tour but is still incorrect.
This commit disables the buttons when they're clicked for the first time
until the handler is processed.
This commit also make the triggers in the tour more specific so that the
tour always clicks on the right modals.
[1]: https://github.com/odoo/odoo/commit/28a78fb4e4e4465aa99fb94f7cac3a21b2188502
runbot-4122
closesodoo/odoo#95839
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
After this commit clients will be able to select whether to display the add to cart button when the computed price of a product is 0.
This option will be available in the settings.
task-2694860
closesodoo/odoo#87952
Related: odoo/enterprise#27594
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Purpose
=======
When a user receives an email to activate their account, allow them to
click on the "Activate Account" button after the account has already
been activated instead of showing a "Invalid signup token" error.
Specifications
=============
Add a parameter p_id to the sign up url to check if the partner has
already activated their account (if their user_ids state is not new) and
redirect them to login otherwise.
Task-2680414
closesodoo/odoo#79936
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce the bug:
- Create a user with only "Inventory/Administrator" access right
- Connect with this user
- Go to Inventory/Configuration/UoM Categories
- Try to add/delete/change any unit of measure in any category
Problem:
an access error is triggered `You are not allowed to access 'Model Data'
(ir.model.data) records.`
opw-2905840
closesodoo/odoo#96137
X-original-commit: 8e58feb6e6151db8e47af4f296d5eb552532cb29
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
When contacting attendees of an event, exclude cancelled attendees by default
as chances are they do not have any interest in what you are going to
communicate.
Task-2796152
closesodoo/odoo#86625
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Consider two models A and B, where
- model A has a many2one_reference field 'res_id' with model field 'res_model';
- model B has an auto-join one2many field 'stuff_ids' to A using field 'res_id';
- the field 'res_model' is not flushed on some record.
model | A | B
-----------+-------------------+-------------------
memory | res_model = B |
-----------+-------------------+-------------------
database | res_model = NULL | id = 42
| res_id = 42 |
| foo = 'bar' |
Now, perform a search on model B that should return record with id=42 by
matching some condition on the unflushed record in model A, like:
B.search([('stuff_ids.foo', '=', 'bar')])
Before this patch, the search method would not flush the field
'res_model', which causes the method to return incorrect results. This
patch fixes the issue by ensuring that searches on one2many fields flush
all the fields on which the one2many field depends.
The issue was discovered while working on task 2735672.
closesodoo/odoo#96115
Signed-off-by: Raphael Collet <rco@odoo.com>
This commit improves the expendability of the attachment_viewer model
and component by making it less dependent on attachment_list.
This is required by the refactoring in wowl of the documents app(s).
TaskId-2898342
closesodoo/odoo#94930
Related: odoo/enterprise#28976
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The `sale.report` `paid` state is added in `pos_sale` and shouldn't be considered in the standard `sale` code.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#96125
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Since [1] when Bootstrap 5 was introduced, the position of the
connectors between steps of the "Steps" block is wrongly computed.
The left offset of the connectors between steps is computed as 50% of
the column width + half the size of the content it connects to.
In Bootstrap 4 the columns are positioned as relative.
In Bootstrap 5 the columns are positioned as static.
Because of this "50% of the column width" became "50% of the row width"
in Bootstrap 5.
This commit makes the specific columns of this snippet positioned as
relative so that the offset calculation get back to its former result.
Steps to reproduce:
- Drop a "Steps" block.
=> Connectors are wrongly positioned, even spanning outside the page.
[1]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
task-2729177
closesodoo/odoo#96071
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The HTML sanitization regroups similar elements into a single one.
For 'style-inline' HTML fields, the font awesome icons are converted
to images within spans.
Because of this, when sanitizing a "5 Stars" block in a 'style-inline'
HTML field, the spans are grouped and all the images end up inside a
single span, with:
- each image being `display: block;` and
- the global span having a fixed width equal to a single image's width.
This turns the horizontal succession of stars into a vertical one.
This commit adds the `oe_unbreakable` class to the image wrapping spans
to prevent sanitize from grouping them into a single one.
Note that this commit does not address the issue that upon a further
edit of the field, the Stars block is not recognized anymore. This
would require a `convert_from_inline` reverting operation which would
change many other behaviors.
Steps to reproduce:
- Go to user profile.
- Edit signature.
- Insert a "5 Stars" block (i.e. use the "/5" command).
- Save.
=> Stars became vertical.
task-2845963
X-original-commit: 9bf0b9872056e5f69a9c912825b863e0a353d5f5
Part-of: odoo/odoo#96071
Since [1] when the Stars blocks were introduced, they were corrupted
during the save operation of views because the views do re-render their
content with `pretty_print=True`.
This commit prevents this from happening by adding a zero-width space
to the Stars blocks.
Steps to reproduce:
- Drop a Text block in a page.
- Insert a "5 Stars" block after the text (type "/5" to find it in the
Power box).
- Save the page.
=> Spaces appear between the stars, and the block does not respond
anymore when clicking on stars if the page is edited again.
[1]: https://github.com/odoo/odoo/commit/8266b978e1bfa5bedfaf1c4fcceadd26400fc85c
task-2845963
X-original-commit: 832995cafcf6181ab3bd1b2d432fd34f6aeed7fe
Part-of: odoo/odoo#96071
Since [1] when the stars were made available in the power box, an
exception is raised when clicking on a technical SVG of the "Steps"
block.
This happens because SVGs have their `nodeType === Node.ELEMENT_NODE`,
they have `className` and `classList` properties, but their `className`
is not a string: it is an `SVGAnimatedString`. Because of this, the
`includes` method is not available on `className`.
This commit prevents the non-existing `includes` from being called.
Steps to reproduce:
- Drop a "Steps" block into the page.
- Click on the column before the first step, at the same height as the
steps icons. (There is an hidden SVG there containing the definition of
the arrows head.)
=> Did raise an exception.
[1]: https://github.com/odoo/odoo/commit/8266b978e1bfa5bedfaf1c4fcceadd26400fc85c
task-2845963
X-original-commit: dbfbf264750a0760d4f2d96a1b7a13ea27472316
Part-of: odoo/odoo#96071
Steps to follow:
- Set your timezone to New York
In linux for example with: `timedatectl set-timezone America/New_York`
- Verify that the user timezone is also set to NY
- Create a reccurent event the 6 july 2022 (a wednesday)
- In options, check the recurrent box
- Set repeat to once every week
- Thursday is the only day checked
-> It should be Wednesday
Cause of the issue:
When `_compute_recurrence` is called, `event.recurrence_id` has not
yet been set
-> `event.recurrence_id.event_tz` is False
=> Copy the defaults before computing the start date and check the
timezone of the event itself
opw-2886253
closesodoo/odoo#96049
X-original-commit: 7186dbad38ef1f05919c398f3c0c5f5d8f8b2219
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
The code handling user presence and the one handling bus notifications
are mixed up. In order to ease the PR introducing the websocket in Odoo
and to clear this mess, the presence service has been introduced.
task-2053917
closesodoo/odoo#95981
Related: odoo/enterprise#29524
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, when clicking on a link with the standard header as
anchor (e.g. Enable "scroll to top button" option to the footer in edit
mode). The scroll animation stopped before reaching the top.
This happened because we stop the scroll animation when the scrollTop no
longer changes. This is the case during the standard header transition
animation. It is only at the end of the transition that we can know that
there has been a change of scrollTop. So this commit makes sure to wait
for the end of the transition to check the scrollTop position.
This commit also adds a "z-index" on the footer "scroll-to-top" button
to place it on top of the elements around it. Before that, the entire
button area was not clickable because it was partly covered by the
elements around it.
task-2773973
closesodoo/odoo#96067
X-original-commit: 201298c66d86c27c1ee05489ccf5c70da88b7e14
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit improves the smoothness of the scroll animation to an
affixed header.
As in this case, we stop and continue the animation several times in the
"scrollTo" function, we need to force the easing of the animation to
"linear" when the scroll animation is restarted in the "progress" of
"animate".
task-2773973
X-original-commit: 1770f61ebd9ebd0991ee13a93f0e771c9c0ad698
Part-of: odoo/odoo#96067
When generating the PDF for the SnailMail report, a script is executed to
adapt the size of the address to match Pingen requirements (as per [1]).
Step to reproduce the issue:
1) Have a contact created that has VAT configure
2) Create an invoice and 'Send and Print'
3) Select the POST button to send via POST
4) In dev mode, go to Techincal > Snailmail Letters
5) Download the PDF of the newly created invoice
You should see that the font becomes extremely tiny.
Solution: There are different elements that needs to be corrected to solve the
issue.
1) The CSS used to specify the `height` requirement of the address was not
properly loaded (the path was incorrect)
2) The JS selector used into the resize script is incorrect
3) The CSS selector into the CSS file was invalid
All these issues are due to incomplete migrations.
[1]: https://github.com/odoo/odoo/commit/c50f5da4160c63dcc79900dc882cd36c9ad96b2e
opw-2819823
closesodoo/odoo#96055
X-original-commit: 7bbdbdcde2315155d17fb30d5496c3daf9a5c4cf
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
Since frontend to backend commit [1], links having `enable_editor=1` to
enable edit mode were not working anymore in certain cases.
Case 1 [OK]*:
From frontend, click on `enable_editor=1` link without `/@/` in it.
Case 2 [OK]:
From frontend, click on `enable_editor=1` link with `/@/` in it.
Case 3 [KO]*:
From backend, click on `enable_editor=1` link without `/@/` in it.
Case 4 [KO]:
From backend, click on `enable_editor=1` link with `/@/` in it.
This commit fixes case 4 and adds a test for all cases, while leaving
case 3 commented as it will be fixed later with a larger fix related to
URL change listener.
* Note that we will probably change the behavior for case 1 and 3: if
the version with /@/ + enable_editor=1 enters edit mode properly in
both frontend and backend contexts (case 2 and 4), it's probably not
worth having code to support case 1 and 3.
The issue for case 4 was that it was trying to load the whole Odoo app
inside of website preview iframe instead of making the parent window
load that URL.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#96054
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When creating a new manufacturing order with `move_finished_ids`
passed in the values, but `byproduct_id` is not amongst the move values,
the creation of the manufacturing crashed.
```
File "/home/odoo/src/odoo/master/addons/mrp/models/mrp_production.py", line 811, in create
vals['move_finished_ids'] = list(filter(lambda move: move[2]['byproduct_id'] is False, vals['move_finished_ids']))
File "/home/odoo/src/odoo/master/addons/mrp/models/mrp_production.py", line 811, in <lambda>
vals['move_finished_ids'] = list(filter(lambda move: move[2]['byproduct_id'] is False, vals['move_finished_ids']))
KeyError: 'byproduct_id'
```
By reading the implementation of the byproduct moves field:
```py
@api.depends('move_finished_ids')
def _compute_move_byproduct_ids(self):
for order in self:
order.move_byproduct_ids = order.move_finished_ids.filtered(lambda m: m.product_id != order.product_id)
```
it seems a better implementation to filter the move on the fact their
product is different than the manufacturing order to determine whether
they are byproduct or finished product moves.
Take the opportunity to write a unit test testing the tricky behavior
of the create override when both `move_finished_ids` and `move_byproduct_ids`
are passed in the create values.
This is related to revision
odoo/odoo@6c087f2043closesodoo/odoo#96044
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Due to a race condition, the chair product was sometimes added before
the js of the product configurator applied the changed attribute.
Changing the rhythm of the tour and making it clearer solves the problem
for the runbot. As the race condition itself will be solved soon with
the owl migration and isn't a problem customers can trigger themselves,
it was decided that it stays as is for now.
task-2909387
closesodoo/odoo#96041
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit makes some adaptation in the scss of the website visitors
kanban view with respect to the introduction of the owl kanban view.
closesodoo/odoo#96003
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Since [1] when the media dialog was re-written in owl, the problem is
solved, this forward-port only keeps the added test scenarios.
See the description of the initial problem below:
Similarly to the comment introduced in [2], classes identifying a video
are only available before media.js begins to save.
This led to wronly inserting the pictogram in an incorrect location when
replacing a video by a pictogram.
This commit keeps track of the fact that a media node was a video before
being replaced instead of trying to find out after the classes have been
removed.
Steps to reproduce:
- Drop a "Text - Image" snippet.
- Replace the image by a video.
- Replace the video by a pictogram.
=> Was adding the pictogram in the first column's button instead.
[1]: https://github.com/odoo/odoo/commit/7fd0698cf765a79959566b51e33cb76bff83d344
[2]: https://github.com/odoo/odoo/commit/d4d25c8b497e465753cef030292faa4824145cb1
task-2729177
closesodoo/odoo#95963
X-original-commit: b50a8015da7bba3b156fa8941b6c2b17533159c7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: test_website
Since [1] when the media dialog was re-written in owl, the problem is
solved, this forward-port only keeps the added test scenarios and some
of the code cleanup & comments.
See the description of the initial problem below:
Since [2] replacing an image by an icon then selecting the icon opens an
error popup.
After this commit there is no error when selecting the icon that
replaces an image because the editor of the replaced media is destroyed.
Steps to reproduce:
- drop a Text-Image snippet
- select the image
- replace the image by a pictogram
- click on a different snippet
- click on the pictogram
=> an error popup is displayed
[1]: https://github.com/odoo/odoo/commit/7fd0698cf765a79959566b51e33cb76bff83d344
[2]: https://github.com/odoo/odoo/commit/d934b81aaae8d68b5579d1489b1fbe8ea347b4ed
task-2729177
X-original-commit: e1c4b62601e5a76a36406d790c9ad2da91c54951
Part-of: odoo/odoo#95963
Co-authored-by: qsm-odoo <qsm@odoo.com>
Since [1] the file size is displayed only for images that support
processing (filter effect, crop, resize...) but when switching to an
image that does not support it, the old size remains displayed.
After this commit when an image for which the file size is not computed
is selected, the previous file size is hidden.
Steps to reproduce:
- drop a Text-Image snippet
- select the image => the size is displayed in the options block title
- replace the image with an animated gif
=> previous size did remain displayed (now size is not shown anymore)
[1]: https://github.com/odoo/odoo/commit/089ae3d28b5d2d7bdbaad133174ae54240113181
task-2729177
X-original-commit: 378f67749a51d8c0b9fb65767faceaa0844916e5
Part-of: odoo/odoo#95963
* test_discuss_full
channel invitation to rtc calls are now using the `ChannelMember` and
`mail.channel.partner` models instead of the `partner` and `guest`
models.
part of task-2692836
closesodoo/odoo#95898
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
`options` were not properly forwarded all the way to `_insertOtherRecord` which
lead to issues when a compute would try to insert an inverse that already
existed but for which the inverse of the inverse was not yet defined because it
also depended on a compute.
Part-of: odoo/odoo#95898
When creating a bill from a bill mail alias, we can end up with a tax or a product from another company
inside the bill. This can cause access issues afterward.
Here is a use case:
- Setup with 2 companies -> A and B
- Both companies have a 21% tax for purchase but the tax from company A has a lower sequence number
- Create an invoice in company A with a 21% tax and print the PDF
- Send the PDF by mail to company B
- The bill generated from facturx will have the purchase tax from company A
=> access error when it's opened
We use 'with_company' function with 'self.env.company' to imply a company to search into but this lead to
two issues when the generation comes from a mail alias.
1. 'self.env.company' may not be the company of the invoice
2. 'self.env.su' is set to True -> company constraints from the environment are not applied
This commit aims to change those two problems.
opw-2752673
closesodoo/odoo#96026
X-original-commit: b706eb6333913fb6c39cfa941f00c4bf499dfa3d
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Beckers Thomas (tbs) <tbs@odoo.com>
The field `company_currency` is indirectly used by portal users, and
does not seem to be a security concern in that context. But as portal
users cannot read companies, the field should be computed in superuser
mode. This apparently used to work by accident in the past...
closesodoo/odoo#95325
Signed-off-by: Raphael Collet <rco@odoo.com>
Merging both the memory of field values and suspended updates has
several advantages:
- avoid inconsistencies between cache and towrite
- cache updates can be made safer w.r.t. dirty flag
However, the dirty flag in cache does not go well with context-dependent
fields. When a context-dependent field is dirty in cache, the value to
store in the database is accessible through some context values. But
when the model is flushed, the context values on the current environment
may be different. When this happens, the method flush() fails to
retrieve the data to flush.
The proposed solution is to store the "dirty" value in cache under
conventional context values, and to retrieve them under the same
conventional context values to flush them. For instance, when storing
the value of a binary field, it will be stored once under the context
value `context.get('bin_size')`, and a second time under the context
value `None`. The flush implementation will then retrieve the value
using the context value `None`.
Translated fields are also problematic when a value is put in cache with
an environment where lang=False, and the value is retrieved with another
environment where lang=None. This issue is addressed by normalizing the
context key 'lang' to None when the context value is False.
Part-of: odoo/odoo#95325
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
The two modules both implemented the cart update warnings box
incorrectly, and differently (though in part because of later
changes):
- `aria-hidden` has meant `display: none` for a while, so the dismiss
button would never show up
- the class is alert-dismiss*i*ble, not alert-dismiss*a*ble
- unnecessarily complicated dom manipulation on updating the warning
- wishlist would go and update the cart badge by hand, unnecessarily
Extracted the warnings stuff to its own helper, with a fixed DOM, and
a slightly modified structure so it's possible to update the message
without having to rewrite the entire box content.
Also modified wishlist to update the cart badge via the existing
helper, this way both modules just call
updateCartNavBar(data);
showWarning(data.warning);
the same way in the same order, and everything is clear.
Also updated `updateCartNavBar`:
- removed the iteration as jQuery should be able to work on the set
- added the warning message and an icon if the quantity is 0 (could
not add to cart) as the separate warning may not be available on all
pages e.g. "recently viewed" product widget can appear anywhere,
previously was only set through wishlist
- keep reveal of cart quantity ancestor as on some pages it's not
visible by default (see previous item for user-case)
closesodoo/odoo#96047
X-original-commit: 2ff55c5fd684ab701cf143d3b0d46979759a8e9f
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
When creating an invoice from a repair order, the account mapping of the
fiscal position doesn't apply even though the tax one does
Steps to reproduce:
1. Install Repair and Accounting
2. Go to Accounting > Configuration > Invoicing > Fiscal Positions and
create a new fiscal position with:
- Name: 'FP test'
- Tax Mapping from 'Tax 15.00%' to a new tax 'Tax 10.00%'
- Account Mapping from '400000 Product Sales' to '450000 Other
Income'
3. Go to Sales > Products and create a new product 'Product A' with:
- Product Type: 'Consumable'
- Customer Taxes: 'Tax 15.00%'
- Income Account: '400000 Product Sales'
4. Create another product 'Product B' with same values except type which
is 'Service'
5. Go to Repairs and create a new repair order with:
- Any Product to Repair
- Any Customer (once set, edit the customer's fiscal position to 'FP
test')
- Invoice Method: 'Before Repair'
- Parts: add a line of type 'Add' with product 'Product A'
- Operations: add a line with product 'Product A'
6. Confirm the order, create an invoice and open it: the account mapping
of the fiscal position didn't apply (it should be '450000 Other
Income')
Solution:
Apply the fiscal position mapping on the income account of the product
opw-2902056
closesodoo/odoo#96038
X-original-commit: 02975a8a7b1803167a5ba8365cfbf29f80f84b2e
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
There was an issue with the computed `read_group` `__range` when grouping on
the same date/datetime field on multiple granularities (i.e. month, week).
Since the range was stored with the field_name as a key, the last evaluated
range would override the previous ones.
Impacted Versions:
- master
(- exists since 15.0 but it does not impact the user directly so it has been
decided to fix this only in master, since the API is modified)
Steps to reproduce:
1. Open a list view and group by a date field with at least 2 granularities
2. Open the chrome debugger (network) and check a web_read_group rpc preview
3. Find the web_read_group for groups related to one of the largest
granularities and check the `__range`
Current behavior:
- `__range = {field_name: false}`
Expected behavior:
- `__range = {field_name: {from: range_start, to: range_end}`
Explanation
Since the smaller granularities are evaluated last, and the condition to update
`__range` is related to the field_name and not the granularity, the range is
always overriden by the smaller granularities (even if their value is False)
when grouping on the same field with multiple granularities.
Furthermore, there is a conceptual problem with the current solution: it does
not allow to store multiple ranges when the read_group is not lazy and when
grouping on the same field with multiple granularities.
Therefore, the proposed solution is to use the full groupby keys in the
`__range` to allow storing multiple ranges depending on granularity. The keys
in `__range` would thus match the group value keys and allow more flexibility
if a domain must be forged from the group(s) range(s).
Task-2894519
closesodoo/odoo#95193
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Lucas Perais