Do not exclude the current partner from the partner search so that you
can easily start a chat with yourself.
Task-2844917
closesodoo/odoo#90663
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
+ Rename the CSS class `o-mobile` to `isDeviceSmall` in order to match the name
of the field tested to conditionnaly add or remove the class.
+ Remove unused classes (o-downloadable and o-isMobile).
+ Rename CSS class `o-has-multiple-action` to `o-hasMultipleActions` and
introduce a new field on AttachmentCard to express more declaratively the
condition used to add or remove the class
closesodoo/odoo#90643
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit introduce a macro system, to allow code to automate user
actions. For now, this is useful for the knowledge application. But in
general, this may be used by any code that want to interact "as a user"
with the web client. For example, we may consider rewriting the tour
system using macros.
Sample macros:
```js
const testMacro = {
name: "test_macro",
onStep: (el, step) => {
console.log("macro step activated", el, step);
},
timeout: 5000,
steps: [
{
trigger: '.dropdown-toggle[title="Home Menu"]',
action: "click",
},
{
trigger: ".wrong-selector",
action: "click",
},
],
};
const testMacro2 = {
name: "test_macro2",
interval: 1000,
steps: [
{
// Open contact application
trigger: '.dropdown-toggle[title="Home Menu"]',
action: "click",
},
{
trigger: '.dropdown-item:contains("Contacts")',
action: "click",
},
{
// click on create button
trigger: () => document.querySelector('button[title="Create record"]'),
action: "click",
},
{
action: () => console.log("we are here..."),
},
{
// input name
trigger: 'div[name="name"] input',
action: "text",
value: "Aaron B.",
},
{
// save
trigger: 'button[title="Save record"]',
action: "click",
},
],
};
/**
* Infinite macro! This also illustrates that macros can be used to do non
* linear sequence of steps.
*/
const testMacro3 = {
name: "test_macro3",
steps: [
{
// Open contact application
trigger: "button.o_form_button_cancel",
action: "click",
},
{
action: () => activateMacro(testMacro3),
},
],
};
const testMacro4 = {
name: "test_macro4",
onError: (error, step, index) => {
console.log(`an error occured at step ${index}`);
console.log(step, error);
},
steps: [
{
// Open contact application
trigger: '.dropdown-toggle[title="Home Menu"]',
action: "click",
},
{
action: () => {
throw new Error("boom");
},
},
],
};
```
closesodoo/odoo#88994
Related: odoo/enterprise#27010
Signed-off-by: Samuel Degueldre <sad@odoo.com>
When triggering an inter-warehouses reordering rule, the partner of the
receipt is incorrect. When triggering several inter-warehouses
reordering rules, it will remove the partner of both receipt and
delivery
To reproduce the issue:
(Let C be the current company)
1. In Settings, enable "Multi-Step Routes"
2. Let WH01 be the existing warehouse. Edit WH01:
- Set a new address ADD01:
- Type: Individual
- Company: C
- Address Type: Delivery Address
3. Create a new warehouse WH02:
- Set a new address ADD02:
- Type: Individual
- Company: C
- Address Type: Delivery Address
4. Edit WH02:
- Resupply From: WH01
5. Create 2 products PA, PB:
- Type: Storable
- Routes:
- WH02: Supply product from WH01
6. For product PA:
- Update the quantity:
- 10 in WH01/Stock
- Add a reordering rule:
- Location: WH02/Stock
- Trigger: Manual
- Min = Max = 1
7. Run the scheduler
- It generates a delivery D and a receipt R
8. Open R
- Error 01: the field "Receive From" is incorrect (ADD02 instead of
ADD01)
9. Repeat step 6 for PB and run the scheduler again
- Error 02: R and D have no more partner
Error 01: see diff
Error 02: we have two SM (one for PA, one for PB) that have a different
origin (one per reordering rule). Therefore, we remove the origin of the
pickings. However, we also remove the partners while we shouldn't
OPW-2733989
closesodoo/odoo#90706
X-original-commit: 20e0ad13afa2a0ff85d555ab57a6800d3db30341
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Current behavior:
When authorized employees is activated is activated for a PoS if you
go back to the login screen and do nothing for like 1 minutes you would
go back to the PoS logged as the previous employee
Steps to reproduce:
- Have PoS installed, create a PoS restaurant wiht authorized employee
- Start a PoS session
- Click on the lock button to go back to the login screen
- Wait for 1 minute
- The screen go back to the PoS
opw-2792531
closesodoo/odoo#90698
X-original-commit: e1741d904f5ae206dff767ff215e0568a7ef008e
Signed-off-by: Masereel Pierre <pim@odoo.com>
Currently we can not add Manufacturing orders Report (graph view) to the
board because of missing context keys (`allowed_company_ids`)
We just have to add the key in the context of `mrp_production_report`
opw-2813295
closesodoo/odoo#90688
X-original-commit: ef789170ce2f1553b325b379aac4452e473de1e9
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Achraf <abz@odoo.com>
`res.users` has virtual fields which are emulation of the real fields.
It requires extra check to ignore such fields. BEFORE there was the following
error:
```
undefined is not an object (evaluating 'fieldInfo.depends.length')
```
STEPS: Go to a User record and use the Dev settings to 'Set Defaults'
---
opw-2731081
closesodoo/odoo#90677
X-original-commit: 6320f38332345ca61d472cae87d1e512b95b84c3
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Steps to follow:
- Switch the current lang to mongolian
- Go to a list view
- Add a custom filter on a date type field
-> locale() locale mn-MN is not loaded from moment locales!
Cause of the issue
- moment.js tries to use the mongalian locale but it is not present
Solution
Add the mongolian locale (from moment 2.29.2)
opw-2829233
closesodoo/odoo#90704
X-original-commit: 179a4b2f31d8e2e0e2be308917725a05c5b78058
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Steps to reproduce the issue:
1)Inventory > Configuration > Settings > Activate "Reception Report"
> Activate "Show reception report"
2)Choose a non english language
3)Sales > Choose SO > Delivery > Allocation
4)Click on the Assign/Unassign equivalent in the new language
Current behavior:
The word in the Assign/Unassign button is in english
Expected behavior:
The word in the Assign/Unassign button is in the new language
Explanation:
When clicked the button starts a function in js that changes the
button text context without translating the new text. We also modify
the text in javascript and the problem is solved.
Issue 2:
The button had fixed size specific to the english language, if a longer
translation in another language was used it was cut leading to make it
unuderstanble in some languages (e.g. german).
opw-2827247
closesodoo/odoo#90705
X-original-commit: 260f433f5600e568db59c82a9c2fc807c1204b5f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
PURPOSE:
This commit adds a min-height property to event pages so that
the footer does not take the entirety of the screen when a page
has little content.
To not have a strange empty space on the booth event page when no booth
is set or when the event is finished, the related error messages are
now displayed below the cover instead of inside it.
It also removes the default grey background on some templates,
so that the theme background color is used instead.
Task-2831951
closesodoo/odoo#89602
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If we had a product as an option to multiple products and we want to stop selling it we'll set sale_ok to `False`. We won't be able to add it to the sale lines but it will keep showing up in the products options popup and we'll be able to add it to the order that way. It must be prevented to keep a coherent behavior.
Description of the issue/feature this PR addresses:
- Add a product as optional product A to several products (B, C, D).
- Set that product to `sale_ok` = False
- Create a sale order
Current behavior before PR:
- Product A can't be selected from the order lines (👍 )
- Add either product B, C or D and the optional products popup shows up allowing us to add Product A to the sale lines.
Desired behavior after PR is merged:
When a product is discarded from sale, we should not be able to add it as an option. Removing it as option in the affected product is not a proper workflow, as the product could be simply temporarily out of sale due to multiple commercial reasons.
cc @Tecnativa TT36178
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#90708
Forward-port-of: odoo/odoo#90593
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Current behavior:
When selling a product in PoS that is tracked by lot number and using
the options to shop it latter and 3 steps delivery.
The move lines associted to the different pickings would have wrong
quantity reserved
Steps to reproduce:
- Activate multi-step routes and Lot/SN in inventory
- Operation types Pos Orders tracability check marked
- Activate Ship later options in PoS
- Set 3 steps delivery in the warehouse settings
- Create an item tracked by lot number and set a quantity
- Open POS session
- Select created item
- Do NOT input a lot number
- Set quantity to 1
- Proceed to payment screen
- Select "Ship Later" on the payment screen.
- Finish Sale.
- Close POS session.
- View the picking orders of the session.
- Select the picking order that is "Ready".
- The reserved quanities in the pickings are not correct
opw-2779462
closesodoo/odoo#90699
X-original-commit: b18710a20eb4b1fc0de79c82c885a677b84a7a70
Signed-off-by: Masereel Pierre <pim@odoo.com>
This commit introduces models that define records being 1:1 map with components,
as a step to move further to having essentially all business code in models.
Having code in models is desirable to have very maintainable code, thanks to
robust and declarative code with an ORM-like architecture.
Task-2831082
closesodoo/odoo#90635
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Since #83550, the sale.report model is not a stored SQL view anymore,
but a query generated depending on the context, to show the amounts in
the currency of the current company.
Therefore, the table sale_report does not exist anymore in database, which led
to a traceback when opening the crm.team view in sale (Sales/Orders/Sales Team).
This commit makes sure that the graph content correctly uses the contextual query
instead of trying to read the sale_report table.
closesodoo/odoo#90602
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Now that the method is deprecated, we think it's better to
keep showing it in the doc, but with a clear deprecation notice
in the docstring (instead of hiding it).
closesodoo/odoo#90634
Related: odoo/documentation#1908
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Reproduction:
1. Select an event, then set a certain maximum amount sold on a paid
ticket, set as 2 for simplicity
2. Go to the Event webpage, then buy all paid tickets
3. Fill out information and attempt to confirm the order
4. The shopping cart is cleared
Reason: We check the event ticket availability in function
_cart_update(). In V14 and V15, we added a new step to update the
pricelist when confirming an order, which will trigger _cart_update().
In V13 update_pricelist is False by default. In V14 and V15, it is
always set to True. The change is to make sure the pricelist is not
changed once the customer chooses the pricelist. As a result, for each
SO, it checks the ticket availability twice. First at when click
register or check out. Second at when submit the address information.
When selling the last ticket, the second check fails and leads to an
empty cart because the seats_reaserved is updated already at the first
step
Fix: add new checking conditions increased_quantity = new_qty > old_qty
to function _cart_update. We only check the availability again when
these new conditions are satisfied.
Current issue: This fix will restore the normal workflow for the last
ticket. But the workflow has its original issue, e.g. it doesn’t update
seats_reserved when increasing the number of tickets.
A solution in SaaS-15.3 is to forbid the customer to manually raise the
event ticket amount
For example:
1. Register 1 ticket, fill in the attendee form and click continue
2. Click review order, increase the number of tickets, then continue
3. The seats_reserved is not updated (can refresh the event page,
seats_reserved is the column confirmed)
If first register 2 tickets and then change to 1, seats_reserved will
change from 2 to 1
This is because seats_reserved is computed from the number of
registration. No new registration is needed when increase the ticket
number, but the registration will decrease when decrease the ticket
number. A solution for it is popping new registration form when the
ticket registration increases.
opw-2784720
closesodoo/odoo#90648
X-original-commit: 8e7867371c66fb7500f13157ada84aadad1d46d6
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Liu Jinjiu (jili) <jili@odoo.com>
The route used by the sale portal to update an option qty didn't check that
the modified SOline was effectively an option.
On the portal, only the optional lines were editable through the interface,
but through xmlrpc, a portal user could be able to remove/update the qty
of non optional lines from a quotation.
This is not a true security failure since only the quantity could be modified
through this route, but it makes sense to add a check to ensure this kind
of modification cannot happen.
closesodoo/odoo#88366
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
On the portal, if you 'spamclick' to reduce the quantity of an optional
line on the portal, when the quantity hits 0, the line is removed, but
you might receive a MissingError saying the record doesn't exist anymore
(if you clicked more times than the qty of the optional line).
To avoid showing this error to the customer, we check the existence of
the option before trying to read its content (and checking it belongs to
the right order).
Part-of: odoo/odoo#88366
Currently, when the quantity of an optional SOline is modified on the
portal, only the quantity and order/line amounts are updated.
This raises two problematic situations when the pricelist is
configured to give discount when a certain number of products is
reached:
1) If the pricelist is configured to include the discount in the price,
the price is not refreshed, which means you see a line total which is
not the result of unit price * qty
2) If the pricelist is configured to show the discount, you won't see
it even if there is one (and you won't see the column if there was
no discount in the SO before your qty modification).
This commit makes sure the order details are refreshed when the quantity
of an option is modified. To do so, we simply need to use the previous
code used to refresh the content when an option was added to the order.
Since we now do a full refresh of the order details whenever the quantity
is updated, the old code updating part of the order details (qty & amounts)
is unnecessary and can be safely removed.
While this code & logic is modified, a cleanup & some documentation of
the code was also made.
task-2180180
Part-of: odoo/odoo#88366
Co-authored-by: Victor Feyens <vfe@odoo.com>
When an activity is created with a very long description, the avatar of the
user is squeezed.
Step to reproduce the issue:
1. Install the Sale module
2. Create an activity (e.g.: a To Do) with a long description (e.g.: using
the Lorem Ipsum paragraphs).
You will see that your avatar is squeezed.
Solution: In the refactoring of the SCSS of the activities (commit [1]), the
sidebar (where the avatar is shown) did not had a minimum width and as the
parent `div` is using `flex` the sidebar is squeezed. Previously, the squeeze
was prevented using `flex: 0 0 36px;` on the sidebar.
[1]: https://github.com/odoo/odoo/commit/da5d9e745fbb755745a1005ed91924ab7b79b741
opw-2799603
closesodoo/odoo#90616
X-original-commit: 355b435e688f42f04536ea6ea3f9f774a7e395f6
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
In a 2-steps configuration, trigger a reordering rule with the vendor
defined will raise an error
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Edit the existing warehouse:
- Incoming Shipments: 2 steps
3. Create a product P:
- Type: Storable
- Add a vendor V
- Routes: Buy
4. Create a reordering rule R for P:
- Trigger: Manual
- Min = Max = 1
5. Open the Replenishment page and edit R:
- Preferred Route: Buy
- Vendor: V
6. Trigger the orderpoint
Error: An Odoo Server Error is displayed "AttributeError:
'product.supplierinfo' object has no attribute 'name'"
When triggering the orderpoint, it leads to
https://github.com/odoo/odoo/blob/c75a1a8ac9eef6c7d7c95b7bbbb22d919b952e26/addons/purchase_stock/models/stock_rule.py#L331
However, since [1], the `name` of a `product.supplierinfo` has been
renamed to `partner_id`
[1] f3fe2d50d9
OPW-2780562
closesodoo/odoo#90597
X-original-commit: bda8b0e610f7ec9b0bcb76de3bb52fb6049f62ff
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
*: sms, snailmail, test_mail.
This PR helps reducing the noise in the one introducing the new environment in
the discuss app. Indeed, we won't rely on the bus anymore to listen to do actions,
we will instead use the action service. The diff is awfull because the indentation
has changed as well as the parameter names. Changing the indentation and the parameters
now will ease the review of the main task.
task-2582313
closesodoo/odoo#90581
Related: odoo/enterprise#26970
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
- Create two extra warehouses (B and C):
* Warehouse B: Resupply from San Francisco
* Warehouse C: Resupply from San Francisco
- Create a new Product:
* Storable
* Inventory > Routes: select only Warehouse B and Warehouse C
- Create a new Move:
* From WHC to a Customer
* Confirm the order
Issue:
In replenishment, the defined prefered route will be Warehouse B
Cause:
When the replenishment view is loaded, in
https://github.com/odoo/odoo/blob/5757502a79c920e1aa4c7ca1c581c533907ce674/addons/stock/models/stock_orderpoint.py#L427
The preferred route (route_id) is defined as the first element of the routes defined for the produc which is wrong.
Solution:
Filter the route_ids by selecting the route for which the supplied warehouse is equal to the warehouse selected for the orderpoint.
Note:
1) The test in "test_bom" has been modified because it was using the wrong flow (a route should have been set by default)
2) In Master we only use the _set_default_route method
opw-2815462
closesodoo/odoo#90560
X-original-commit: 15b04d616a5196192a96e6bf2114698b34654348
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
When the user cancels a SO, if there is an associated PO, there won't be
any activity logged on the PO about the SO cancellation.
To reproduce the issue:
1. Unarchive the MTO route
2. Create a product P:
- Type: Storable
- Routes: MTO & Buy
- Add a vendor V
3. Create and confirm a SO with 1 x P
- Note: a PO is generated
4. Cancel the SO
5. Open the PO
Error: There isn't any information about the cancellation of the SO. An
activity should be added to the PO.
Since [1], if the PO is a draft, we no longer log an activity when the
quantity of the related SO is reduced:
https://github.com/odoo/odoo/blob/3bd9b7a77a1e0e05ea479945d5cd8085f6981feb/addons/purchase_stock/models/stock.py#L103-L105
However, when cancelling a SO, we call the activity logger:
https://github.com/odoo/odoo/blob/846ad1f978fe36db892a9902bb4657c2079d1756/addons/sale_stock/models/sale_order.py#L184-L189
So, since the PO is not yet confirmed, we ignore it and do not log any
activity
[1] bda3225c6cc27bb2c2933eda3cc68c6f9708daf3
OPW-2820242
closesodoo/odoo#90553
X-original-commit: de485a39c9ee88aa31f9330a468ad31cc05842bc
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
From 450 to 1.5 ms
closesodoo/odoo#90609
X-original-commit: 045d80187c10c74747a3fd35b931cfe0c9862c08
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Since 43463a1 it was not possible anymore to trigger hotkeys
from an editable element excepted through
the hotkey option "bypassEditableProtection".
But there are cases where the editable element may want to always
allow any hotkey: e.g. the command palette search input.
Before This Commit
Impossible to trigger hotkeys from the command palette.
After This Commit
The command palette search input now allows any hotkeys.
closesodoo/odoo#90578
X-original-commit: 72dfe16ec8453ff299c2525431db619ccfdbfdec
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi <boi@odoo.com>
the patchDate function had these issues:
./addons/web/static/tests/helpers/utils.js
29:5 error Read-only global 'Date' should not be modified no-global-assign
58:21 error 'date' is already defined no-redeclare
Part-of: odoo/odoo#90578
This PR helps reducing the noise in the one intorducing the new environment
in the discuss app. Indeed, there won't be widget anymore since createWebClient
will always be used. createXXXComponent methods were relying on widget.el to
mount the components. Let's already replace it by target.
task-2582313
closesodoo/odoo#90526
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When viewing tasks for a specific project, the "Projects" filter in the
calendar view is useless, since there can only be a single project.
This commit removes the filter in that case.
Task-2741733
Part-of: odoo/odoo#86008
This commit moves the 'Customer Ratings' warning to be right under the
Rating Email Template field in the task stages settings view.
It also slightly reorders other fields and fixes a typo.
Task-2741733
Part-of: odoo/odoo#86008
This commit colors the project filter checkboxes on the right side panel
of the task calendar view with the color of the corresponding project.
It also changes the color of the events in the tasks in the calendar so it
uses the color in the project in the view "All Tasks", and the color of
the tasks in a calendar view of a specific project.
Finally, it adds some colors to tasks in demo data to better showcase
that feature.
Task-2741733
Part-of: odoo/odoo#86008
To make it more clear that the calendar view of the project tasks
only shows the deadline of the tasks, this commits appends
" - Tasks by Deadline" to the title of the view
Task-2741733
Part-of: odoo/odoo#86008
This commit uses params.displayName instead of params.action.name for calendar views titles.
This allows us, among other things, to use the project name as a title
for the project's tasks calendar view, which is more consistent with other views.
Task-2741733
Part-of: odoo/odoo#86008
This commit changes the project status column in list view to copy
the behavior of the kanban status column for tasks, by removing
the column label and show the status text on hover.
Task-2741733
Part-of: odoo/odoo#86008
In the fullcalendar library, you can by default resize events with the mouse
to alter the start and end dates. However, since for project tasks, we use
the calendar to show deadlines, it wouldn't make sense to resize them.
This commit therefore disables the ability to resize tasks.
Task-2741733
Part-of: odoo/odoo#86008
Purpose of this commit to improve generic UX of timesheet app.
So, in this commit:
- make tree view editable bottom.
- ensure that all non private tasks can be selected in timesheet
tree view.
- add job_title non store field to add custom filter on job_title.
- show unit_amount in red in tree view when it's value is less
than 0.
task-2784776
closesodoo/odoo#87630
Related: odoo/enterprise#25762
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Prior to this commit branded UI components were styled exclusively in
raw SCSS using the '$o-brand-odoo' variable.
This leaded to unnecessary code repetitions since, to achieve the same
visual result, each module defined its own classes.
Visual inconsistencies were frequent too since each module defined its
own variations for interactive states (eg :hover).
This commit injects '$o-brand-odoo' into bootstrap's default
'$theme-color' map, allowing the framework to automatically generate
odoo utility/contextual classes.
These classes can be used to handle text, backgrounds, borders and
buttons wherever needed.
Part of the overall v16 SCSS optimization/restyle, task-2704984.
task-2800721
closesodoo/odoo#87448
Related: odoo/enterprise#25700
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
This commit improves consistency between jQueryUI dropdowns and the
overall UI. It also address inconsistencies between versions allowing
to remove 'dropdown_extra.scss' [1].
Part of the overall v16 SCSS optimization/restyle, task-2704984.
[1] enterprise adaptations: https://github.com/odoo/enterprise/pull/25700
task-2800721
Part-of: odoo/odoo#87448
Yannick Tivisse