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>
Task 2888204
- Name is automatically split into code and name
- account_type is computed based on the closest parent of the code prefix (and can be changed)
- _onchange_name is needed to split name into code and name when creating from a related model's form
closesodoo/odoo#94171
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
*: calendar, iap_mail.
Now that the bus service is a wowl service, we don't need to wait for
the webclient to be ready before using it. Indeed, the services now
have the bus service as a dependency which means it will always be ready
in time. This also showed that the rpc service was missing as a bus service
dependency. It has been added.
Some part of the code were also checking if the bus service was in
`env.services`. Those calls have been removed as well since we now
have the guarantee that it is.
closesodoo/odoo#96002
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Some legacy services are still relying on the bus_service as a dependency.
However, this service is now a wowl service which means those services
won't start.
closesodoo/odoo#96001
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Issue:
sale order mobile view cannot show product_forecast_report.
Cause:
move_ids field is missing in the view.
Solution:
Add move_ids back to the view.
closesodoo/odoo#96000
X-original-commit: 9c19460ce7fb1a16cfeed607e474e273f5ce690b
Signed-off-by: Steve Van Essche <svs@odoo.com>
When dragging an article with an open nest, the `jquery.mjs.nestedSortable`
library does not refresh the positions of the following articles. This forces
the user to drag the nest far below the target position to move the placeholder.
This commit is a small fix to the library, to refresh said positions before
checking for element intersection.
Task-2883290
closesodoo/odoo#95749
Related: odoo/enterprise#29315
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Prevent a flickering effect when dragging item down in a nested tree using the
`jquery.mjs.nestedSortable` library.
Situation:
1.) start dragging, moving down and slightly to the left
.dragged item
.nest0
.nest00
.nest000
2.) intersect nest0
.nest0:hover:.dragged item
.nest00
.nest000
.drop destination
3.1.LIBRARY) intersect nest00 first trigger
.nest0
.nest00:hover:.dragged item
.nest000
.drop destination (frame 1)
3.2.LIBRARY) intersect nest00 second trigger (slightly below and to the left)
.nest0
.nest00:hover:.dragged item
.nest000
.drop destination (frame 2)
frame 1 and frame 2 are rendered almost simultaneously, and in a cycle (after
3.2. comes 3.1. again), resulting in a flickering effect.
3.1.FIXED) intersect nest00
.nest0
.nest00:hover:.dragged item
.nest000
.drop destination
drop destination is not allowed to go UP in the dom since the mouse is lower
than before. No flickering in this case.
To go up in the tree, the user can simply move the cursor to the right and/or
up.
The `jquery.mjs.nestedSortable` library will be rewritten internally in the
future to remove the jQuery dependency, but this fix allows a smooth utilisation
in the meantime.
Task-2883290
Part-of: odoo/odoo#95749
Step to reproduce:
- Go to 'My Preference' or User profile as admin
- Click on the world icon to add a language
Old Behaviour:
- Open the technical view of languages
New Behaviour:
- Open a wizard to add a a language
taskid-2774319
closesodoo/odoo#92855
Signed-off-by: Arnaud Joset <arj@odoo.com>
Due to the recent bootstrap changes one attribute on the carousel
indicators was badly migrated which caused bootstrap's carousel code to
throw an error.
This commit fixes that issue.
TaskId-2833507
closesodoo/odoo#92447
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
This commit adds a new display type for a product page, namely the grid
mode.
The web designer will now be able to choose between carousel (previous
mode) and grid.
The web designer may also choose how much space the images take on the
page between 0%, 50% 66% and 100%.
TaskId-2833507
Part-of: odoo/odoo#92447
Before this commit, orders were not confirmed when there was more than
one transaction linked to them, regardless of their state.
As of now, we check if there is only one confirmed transaction (meaning
that the state of the transaction is either 'authorized' or 'done').
Fix 4d2b04a843
task-2906040
closesodoo/odoo#95443
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The expense dashboard was displayed on the Expenses Analysis whilst it
shouldn't have.
closesodoo/odoo#95987
Signed-off-by: Kevin Baptiste <kba@odoo.com>
For zero percent taxes, when the repartition lines are defined as 0% of
the 0% tax, the DatiReipilogo elements are not generated.
This is because of the recent addition of a filter to the calling of the
_prepare_edi_tax_details inside of the function that generates the
values for the template. The filter specifies that the tax data
retrieved relates to repartition lines with a percentage > 0. This
excludes taxes that are 0% of a 0% tax (which would be the same as a
repartition line of 100% of a 0% tax).
The solution is to change the > to >= so that these 0% tax repartition
lines are included.
A test is created with an invoice with two 0% taxes. One tax has a 100%
tax repartition line, and one has a 0% tax repartition line. With the
fix, there should be DatiReipilogo for both taxes in the xml.
The reverse_charge_invoice tests are also fixed in order to ignore the
invoice name (which will change depending on how many invoices are
posted in the previous tests).
closesodoo/odoo#95966
Ticket-id: 2909394
X-original-commit: 089f59ef79c554d7517d8621bfaee03875ad6062
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”
- Tracking: by serial number
- BOM:
- Component: C1
- Create a storable product “P2”
- BOM:
- Component: P1
- Create a MO to produce one unit of P1:
- serial number: SN1
- Confirm and mark as done
- Unbuild the manufactured product
- Manufacture the same product using the same serial number again
- Create a new MO to produce one unit of “P2”:
- Component P1 → select SN1
- Try to confirm and validate the MO
Problem:
Get User Error: The serial number “SN1” used for component “P1”
has already been consumed
We do a search in the `stock.move.line` to find if the SN has already
been used in a previous MO, but there is no specific condition to get
only those used in an MO so the unbuild order is in the same condition
and therefore the SN is considered as it has already been used
opw-2883450
closesodoo/odoo#95935
X-original-commit: 5ac7f4d6fa5551ba7c6da49a52edf0a7df2d0745
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
*: bus, calendar, iap_mail, im_livechat, project, web.
In order to ease the PR introducing the websockets in Odoo, the bus service
has to be updated to be a wowl service. This PR takes care of it.
task-2053917
closesodoo/odoo#95824
Related: odoo/enterprise#29361
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Stpes to reproduce the bug:
- Create a storable product “P1”:
- tracking: Serial number
- BOM: 1 unit of C1
- Create the MO 1:
- produce 1 unit of P1:
- Create the SN1
- Create the MO 2:
- produce 1 unit of P1:
- Create the SN2
- Create an Unbuild order:
- Select the MO1
Problem:
You have the possibility to select any Serial number linked
to the product “P1”, whereas only SNs created in this MO can be selected
opw-2834529
closesodoo/odoo#95956
X-original-commit: 167b1668450c5af44bc1d36d1c7d59921bc2b811
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Fabio Barbero