After a fix made in rev:bd621fd456811e7f3ce646e3ecade5e9e4a826e8
It was not possible to generate an invoice from the POS when you have a
fixed tax included applied on a base amount with tax included.
As it was not detected by a test, we are now creating a test with this
use case.
closesodoo/odoo#92106
X-original-commit: 291b564ffebaf8b8708072c981d1072b8bb33677
Signed-off-by: Masereel Pierre <pim@odoo.com>
The recruitment kanban view was redesigned and it looks good, so it was
decided to implement the same design on the department kanban view. This commit
adds the number of employees to the "Employees" button and makes the kanban
cards wider.
task-2849418
closesodoo/odoo#91293
Related: odoo/enterprise#27324
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Prior to this commit, when running the `timesheets.analysis.report`, a
traceback was thrown `TypeError: tuple indices must be integers or slices,
not str`.
After this commit, not traceback is thrown.
closesodoo/odoo#92024
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, the `<iframe/>` element of the `s_map` snippet would
be removed from the field value if the field was sanitized.
The map would then not be displayed, obviously.
The way that `s_map` snippet work is simple:
1. The snippet is defined with a hidden `<iframe/>` element
2. The snippet options are stored as data attributes on the `<section/>`
element.
3. When those options are changed, the iframe `src` is updated and it is
shown if needed.
The fix is simple, as we already have all the data attributes available,
we just need to recreate that iframe when the snippet is started without
one. It most likely means it got deleted through the sanitization during
the save.
opw-2844010
closesodoo/odoo#91866
X-original-commit: c2e9bd0e60014b6a42931cf300e0f89f8cf7c225
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Purpose of the commit is to make the rating thank you
page as editable on website and to make a page editable
we must have to add the oe_structure class and id which
contains oe_structure string.
task-2772369
closesodoo/odoo#86231
Related: odoo/upgrade#3341
Related: odoo/enterprise#25185
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit allows project users to create and modify their own personal
stages.
A lot of overrides have been done on the kanban view to handle our
multiple cases.
Project user will now only see the options to create columns/edit stages
when grouping by personal stage.
This is hardcoded and does not follow possible custom access rules
however.
Any stage created while grouping by personal stage will directly be
assigned to the user and will be seen in the 'My Tasks' menu.
A special method has been added to delete a personal stage.
Upon deletion any task assigned to this personal stage will move to a
lower sequence stage if possible otherwise the next in line.
TaskId-2858445
closesodoo/odoo#92103
X-original-commit: 7b3acbc0b0c21ab106b1b34d9f5c8bc1ceb2fe58
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
In the Firefox browser, when in edit mode, if we click on an input
element, a traceback sometimes appears for no apparent reasons.
The error comes from the fact that when calling the getRangeAt function
on the selection, it sometimes returns a "restricted" range.
Ex: Range { commonAncestorContainer: Restricted, startContainer:
Restricted, startOffset: 0, endContainer: Restricted, endOffset: 0,
collapsed: true }
And so, trying to access a container property (ex: nodetype) will
trigger a "Permission denied to access property "nodetype"" error.
This commit provides a solution to bypass the error. It consists in
redefining the getRangeAt function as the following:
- A range is created by calling the original function that was saved
beforehand
- We check if the range is restricted (the same way as what was done in
this issue: https://github.com/tinymce/tinymce/issues/2194)
- if it is not restricted, the range is simply returned
- otherwise, a new range is created manually, based on the selection
Steps to reproduce the bug:
- Install website
- Drop a form snippet
- Click on the input fields
-> Sometimes a traceback appears
task-2810365
closesodoo/odoo#92097
X-original-commit: c32f6efa956ae9affbb80f84b66118e343268eff
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
To reproduce
============
- choose boxed layout as document layout in settings
- enable packages in inventory
- set Incoming Shipments of warehouse on 3 steps
- enable detailed operations of *PACK* operation
- create a pack transfer
- in detailed operations tab, set destination pack
- validate the transfer and print the delivery slip
on PDF the line of destination pack is white text on clear gray (unreadable)
Purpose
=======
on that line two style classes are applied and both of them are changing the background color,
`.o_line_section` :
https://github.com/odoo/odoo/blob/9ce6136be700ae426b8910efd2357d16e2f49d7d/addons/web/static/src/scss/layout_boxed.scss#L61-L64
`.page > table:not(.o_main_table) tr td:last-child` :
https://github.com/odoo/odoo/blob/9ce6136be700ae426b8910efd2357d16e2f49d7d/addons/web/static/src/scss/layout_boxed.scss#L73-L75
We are taking the background color from one and the text color from the other one that don't match.
Specification
=============
to solve the issue we set the text color on `.page > table:not(.o_main_table) tr td:last-child` so that when this style class is
applied it has it's own text color, that matches the background, and doesn't take it from an other class.
opw-2841460
closesodoo/odoo#92096
X-original-commit: 4ee580d32f88fa9a13775355c75503678369c421
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
BoM Structure & Cost report has different errors:
- The product cost of a subcontractor included in a product doesn't
scale with the quantity of the product (Issue 1)
- The BoM cost of a product composed of a subcontractor doesn't include
the subcontractor price (Issue 2)
- The BoM cost of a component composed of a subcontractor doesn't scale
with the quantity for the subcontractor price (Issue 3)
Steps to reproduce:
1. Install mrp_subcontracting_purchase
2. Create a product 'TEST 1', in the Purchase tab specify 'Azure
Interior' as vendor with price 5$
3. Create a bill of material for the product 'TEST 1' with BoM type
'subcontracting', subcontractor 'Azure Interior' and product 'Bolt' as
component
4. Create another product 'TEST 2', in the Purchase tab specify 'Azure
Interior' as vendor with price 8$
5. Create a bill of material for the product 'TEST 2' with BoM type
'subcontracting', subcontractor 'Azure Interior' and product 'TEST 1'
as component
6. Go to the BoM Structure and Cost of product 'TEST 1'
7. The product BoM Cost doesn't include the subcontractor price (it
should be the sum of its components) (Issue 1)
8. Increase the quantity of the product by 1
9. The subcontractor's product cost doesn't change (it should increase
with the quantity) (Issue 2)
10. Go to the BoM Structure and Cost of product 'TEST 2'
11. Increase the quantity of the product by 1
12. The BoM Cost of component 'TEST 1' only counts the subcontractor
price once (it should be the sum of its components) (Issue 3)
Solution:
Scale the subcontractor product cost with the quantity, update the
BoM cost of a product with the subcontractor price (in `_get_bom`) and
scale the subcontractor price with the quantity (in `_get_price`)
opw-2844482
closesodoo/odoo#92095
X-original-commit: 4f3347c6925e10ec62a85bb01d7cdb65b1e13b15
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Before this PR, nothing warned the user that the invitation link was restricted to
a user group.
task-2818094
closesodoo/odoo#88562
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: calendar, note, test_mail.
This PR prepares the ground for the one introducing the new environment in the discuss app.
Indeed, the start helper won't be able to handle widget anymore. To solve this issues,
we're now adding the activityMenu widget to the systrayMenu.Items array, this will be
mapped by the createWebClient helper to component and added to the new systray item
registry.
task-2582313
closesodoo/odoo#91953
Related: odoo/enterprise#27614
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit aims at improving the display of taxes at onboarding only.
Many active and inactive taxes are mixed in complicated localizations (e.g. Belgium),
even though most of those inactive taxes are useless for most of the users that are
going through the onboarding.
To achieve this, we should change the default sort on the list view as follows:
1. Active
2. Tax type
3. Tax amount (to group them together by amount, even if the column is hidden by default in the view)
Task id: 2846605
bla
closesodoo/odoo#91486
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- Create a Time off Type for which an allocation can be requested
by the employee and approved by the time off officer
- Set a Time Off approver on the employee
- Create an allocation
Current behavior:
The allocation approval activity is assigned to the employee
Expected behavior:
The allocation approval activity is assigned to the time off officer
Problem
The function _get_responsible_for_approval used the validation types
of v14 instead of the one of v15.
XML modification:
While using the form for the time off types I notice that the logic
was incomplete for the "responsible time off officer" invisible and
required fields. the field can not be invisible if the approved by
time off officer is set and it should be required to avoid errors.
opw-2849972
closesodoo/odoo#92067
X-original-commit: 2e2b89eed31e74cb6123f065c7790726753d585d
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The Interviewers couldn't mark Activities as done, as they didn't have
access to the mail.message on the application.
closesodoo/odoo#92063
Taskid: 2857423
X-original-commit: 4a5941eed902927e11605e94b7afcfc227bece9d
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This is the long awaited small POSIX shell script that installs Debian
packages needed to run Odoo.
At the first time it was intended to be a small Perl script as Perl is
available everywhere. Finally it turned out that a POSIX shell script is
smaller, easier to read and could be run everywhere.
closesodoo/odoo#92038
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
The `hasSearch` variable on `this` was not used anywhere and, if it was,
its semantic was arguable because it was set true as soon as the search
was fired rather than when the search had returned.
I'm taking this opportunity to use async/await as it's *way* better here.
closesodoo/odoo#92014
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, animated elements did not animate in a tab that just
opened. Exact same problem was also happening with the accordion block.
Steps to reproduce the issue (with the tabs block) :
- Create a tabs block.
- Add some content with animation on each tab.
- Save.
- When you refresh, the first animation loads.
- Switch tab to another animation and wait - it won't load.
- Scroll up or down -> animation will show up.
opw-2813435
closesodoo/odoo#91850
X-original-commit: 2c21d5a7b493a3c88962ad9185391b6d6c7fc010
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Reproduction:
1. Install Sales and eCommerce, check “Delivery Methods” in Settings ->
Sales
2. Go to Sales->Configuration->Shipping Methods, create a Fixed Price
shipping method with “Free if order amount is above” checked, and set
amount 500. Make this delivery method the only published one
3. Go to the webshop, order something with a price above 500, and
checkout
4. At the backend, check the Sales->Quotations, click the order and
check the confirmation message (or click “SEND BY EMAIL ”, choose the
confirmation email)
5. The Shipping Method still shows the fixed price instead of “Free”
Reason: The confirmation email template doesn’t show the delivery price
based on the actual cost of this order
Fix: Add another condition to the “Free” case. If the amount_delivery is
0, we show the price behind the delivery method as “Free”
opw-2834505
Related PR: https://github.com/odoo/odoo/pull/90880
Related commit: bb032d4e9e535b40692578512c4b37ac9cccedff
closesodoo/odoo#91009
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
PR 91638 introduced a write() on the partner_id after the AML state
was set to 'posted'.
This causes a problem for users who have the journal hash activated.
Fix => move the write() before posting the AMLs.
closesodoo/odoo#91997
X-original-commit: cd3bbeb15983b263ba2ffb419d59575b64a41ca2
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
Set order is not randomized for integers (integer hash is the integers
itself and doesnt use pythonhashseed)
but the output may be ordered or not depending of the values:
In [2]: list(set(range(126,130)))
Out[2]: [128, 129, 126, 127]
In [3]: list(set(range(130,134)))
Out[3]: [130, 131, 132, 133]
This will lead to different results in query count tests depending on
the current value of the sequence.
The proposed solution is to use an Orderedset. We need to keep in
mind that the initialisation/operation on Orderedset may be slower but
this shouldn't represent any significant overhead in this case.
closesodoo/odoo#91962
X-original-commit: da66b8fc008f97680584e266135b7fa7d3dedeca
Signed-off-by: Rémy Voet <ryv@odoo.com>
If `_get_external_ids` is called in an onchange context on a newid
wrapper, the result map uses NewId keys but the assigned data uses
real ids, which leads to a mis-setting, and usually the call blowing
up immediately as `data['res_id']` is not one of the preallocated dict
entries.
Update the code to better handle this possible difference.
closesodoo/odoo#91957
X-original-commit: 5797fd80a63309269f15bcbe4948d4429a53eec2
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
This commit adds the possibility to have a custom placeholder in the
command palette depending on the namespace.
closesodoo/odoo#91947
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Ubuntu Jammy brings some breaking changes for odoo 15.0. Since 15.0 is still the main branch, this pr aims to ensure compatibility if deployed on ubuntu Jammy.
Main changes:
- python 3.10
- werkzeug 2.0+, including vendoring werkzeug's user agent parser in `odoo/tools/_vendor/useragents.py` (= the one from version 0.16) as it is discontinued after v2.1
- currentThread is now deprecated (use current_thread instead)
- default requirement version (based on deb package version)
- new opcode in python 3.10
- distutils.version.LooseVersion is deprecated
- wkhtmltopd version packaged with ubuntu jammy don't have patched qt but will work without headers and footers. Suggested wkhtmltopdf version 0.12.5 doesn't have a build working with jammy yet because of incompatible libssl dependencies. A parallel wip may provide a 0.12.5 version compatible with jammy latter (currently used as testing version on runbot). If this solution is chosen, this build may be provided by odoo latter.
As usual, all changes are made with the spirit to keep compatibility with previous version (Focal)
enterprise PR: https://github.com/odoo/enterprise/pull/26831closes#84097closes#88980closes#89533closes#78020closes#83309closes#87463closesodoo/odoo#91927
Forward-port-of: odoo/odoo#91543
Forward-port-of: odoo/odoo#88803
Related: odoo/enterprise#27601
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
This query count test fails deterministically on runbot when built with
Ubuntu Jammy. After some investigations, it appears that this query
count is very indeterministic and will be fixed in #91386.
Until that, the expected count is bumped.
Part-of: odoo/odoo#91927
As werkzeug.utils.unescape is deprecated in werkzeug 2.0 and the
markupsafe version of unescape just uses the built-in html.unescape [0],
we can use directly the same built-in method.
[0] pallets/markupsafe@c35603a903
Part-of: odoo/odoo#91927
Since Python 3.10, the invalid escape sequence warning use quotes to
display the invalid sequence. Because of that, the filter does not catch
it anymore.
With this commit, they are caught in all supported versions.
Part-of: odoo/odoo#91927
With this commit, the LooseVersion function comes from distutils which
is deprecated [0] in Python 3.10 is replaced by parse_version.
[0]: https://peps.python.org/pep-0632/
Part-of: odoo/odoo#91927
As of werkzeug 2.0, the `posixemulation` compatibility layer for atomic
rename operations is abandoned[1]. In the mean time an atomic,
cross-platform file renaming function was introduced in the stdlib, as of
Python 3.3: `os.replace()`.
By using `os.replace()` instead of `posixemulation.rename()`, we can
ensure compatibility with versions 0.x, 1.x and 2.x of werkzeug.
We've always required Python 3.5+ since the P3 support, so
`os.replace()` is always available.
This is a follow-up of the work for supporting werkzeug 1.x [2]
References:
[1] https://github.com/pallets/werkzeug/pull/1790
[2] vendoring of werkzeug.sessions: odoo/odoo#45931
Part-of: odoo/odoo#91927
In discussing 56fe16bd I was reminded to re-set the `user_id` from
`sub` in case an override / other client would be using it, but we
didn't think that an override might also be *setting* this work key,
which apparently is the case.
Therefore restore the old behavior of *getting* the user_id from the
response object, migration to using `sub` (and removal of compat with
`user_id` and `id`) will be done when the module is reworked and the
flow compatibility, nonce, etc... are all fixed.
closesodoo/odoo#91996
X-original-commit: a787a2f644e9e83dc6320eaf372e657718fd2e22
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When a subtest fails, the failure or error is taken into account and even if
the subtest was silenced the test itself logs an ERROR with the count of
failures.
With this commit, at the first try, the subtest result is not taken into
account.
closesodoo/odoo#91974
X-original-commit: 96ca5bb6d7aeb54dfb8d5453edaf04b2ea903d41
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Currently, only a public user or an internal user can access HR
department information. This is causing an access rights error when
trying to filter job offers on the website if connected with a portal
user, while there is no error if not connected (public user). We should
have the same behavior for the two cases.
closesodoo/odoo#92003
X-original-commit: 689a3aa9bf08bf3567c0fa0cc4cf67cc3d7e0b54
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Alex Thuyls (alt) <alt@odoo.com>
Parent view:
```
<hello>
<world></world>
<world></world>
</hello>
```
Child view:
```
<data>
<xpath expr="/hello/world[1]" position="replace"/>
</data>
```
=> There are two <world/> in the original view, the first one is removed
by a child view.
In that case, the branding was still distributed on the <hello> element.
This is a problem as it meant that in edit mode you were able to edit
the whole content of that <hello/> element... breaking the xpath made by
the child view.
After this commit, in that case, the branding is rightfully distributed
on the remaining <world/> element (just like it would have been if the
inheriting view had added an element instead of just removing one).
This is a follow-up of the parent commit (of the same PR at [1]).
[1]: https://github.com/odoo/odoo/pull/91015
Related to opw-2811674
closesodoo/odoo#91991
X-original-commit: abd9d7a74c91f4632550a376fe566ac28e64377b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When branding was added on items which follow an element that is removed
by an inheriting view, the branding was incorrect. Indeed, it supposed
the removed element does not exist in the original view. E.g.:
Parent view:
```
<hello>
<world></world>
<world></world>
<t t-esc="foo"/>
</hello>
```
Child view:
```
<data>
<xpath expr="/hello/world[1]" position="replace"/>
</data>
```
=> There are two <world/> in the original view, the first one is removed
by a child view. The data-oe-xpath set on the remaining <world/>
should still be /hello/world[2] and not /hello/world[1] to target the
right element in the parent view.
This of course induced edition problems where a saved area was not saved
inside the right element of the parent view or, more likely in normally
complex arch, just crashed on save. As an example, with 14.0 enterprise:
- Install website_appointment
- Go to a page with a calendar to schedule an appointment
- Enter edit mode, try to add something in the area *below* the calendar
- Save => crash
Commit [1] already fixed similar problems when an element was *replaced*
by something (especially, when replaced by an element with the same tag
name). This commit actually reviews what was done to fix both problems
(replacement and removal) at the same time. It also makes it so the xml
that `apply_inheritance_specs` produces has no "Element" part impacted
when used with "inherit_branding=True", which seems better... although
the notion of inheriting branding should probably be independant from
this function (maybe something to do in master).
[1]: https://github.com/odoo/odoo/commit/c077ef05575d9677bce284195683f96c68386788
opw-2811674
X-original-commit: 4ab569933464617444f6150793876ff4eba11690
Part-of: odoo/odoo#91991
When updating the results following a change in the search filter or the
source sources filter (All, Illustrations, ...), the list of media is
regenerated to match the new results. If the user clicks on one media at
the right time after the search is triggered (not too fast but not too
slow either) it is possible to select a media which id is out of sync
with the new state of the widget, thus prompting `_onAttachmentClick` to
provide `undefined` to `_selectAttachment`, which ultimately leads to a
traceback in `_highlightSelected` when accessing either `media.id` or
`attachment.id` depending on the case.
This commit fixes the issue by disabling pointer interactions with
the attachments during the search and rendering update process.
closesodoo/odoo#91985
X-original-commit: bc9db4e5a5559692f461acc7402df969b6236481
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
- Set up an alias to receive vendor bills to company 2
- Forward a mail to this alias from an internal user
- The mail should have the email address of a partner belonging to company 1 in it
Current behavior:
- The partner from company 1 can be set as vendor even tho the vendor bill will be from company 2 (inconsistent)
- This leads to a multi-company error, and you can't open the bill as an user who can see it but not the partner.
Intended behavior:
- Partner from company 1 shouldn't be set as vendor if the vendor bill has been created from email alias of company 2.
As the intended behavior says, the code avoids to set the vendor if the bill is created through an alias.
opw-2587047
closesodoo/odoo#91973
X-original-commit: 4d5bb1fd46546870cd10d8dcd5b229de68a2e284
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Andrea Grazioso (agr-odoo) <agr@odoo.com>
It is now possible to get access to the action context keys when the
search filters are evaluated. This means that a search arch filter like
<filter name="my_filter" domain="[('my_field', '=', context.get("my_value))]"/>
can be safely evaluated if "my_value" is in the action context (or in
the user context or is builtin as before).
closesodoo/odoo#91959
Signed-off-by: Géry Debongnie <ged@odoo.com>
Pierre Masereel