The amount of cash present in the POS may be incorrect
To reproduce the error:
1. In POS settings, enable "Advanced Cash Control"
2. Start a POS session
3. Make an order of 70$, payment in cash
4. Close the POS session (correctly set the closing cash)
5. Start a POS session, close it (correctly set the closing cash)
Error: Back to kanban view, the information about the POS are incorrect:
the cash balance is equal to zero, it should be $70
The value of the cash balance is computed in `_compute_last_session`:
https://github.com/odoo/odoo/blob/5ea1d31df9041ca7b25fbea6178e798e62bebca0/addons/point_of_sale/models/pos_config.py#L276-L291
This method gets the last session and extracts the information. However,
in the above case, there were no sales during the last session (step 5).
In such situation, the bank statement of cash is deleted. As a result,
in `_compute_last_session`, `last_session_closing_cashbox` will be
defined to `False`. This is the reason why the cash balance will be
equal to 0
The deletion of `cash_register` has been introduced in case the user
closes a session that does not contain any SO. This fix suggests keeping
such a bank statement and automatically posting it.
Linked to OPW-2507394
closesodoo/odoo#72663
X-original-commit: dae9ba62d98d4238600ccd637dd5e879f1cac903
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Since odoo/odoo@1971bf3 the customised dropdown in the pivot view (the one that opens its submenus horizontally) cannot open at all its submenus.
As the correct behaviour cannot be restored without reintroducing the +300 scss lines that has been removed, this commit applies a temporary fix that *changes* the design of this dropdown. Now, its submenus will open vertically, like for the groupby menu near the search bar.
The final dropdowns design is currently ongoing within the taskid: 2578926
closesodoo/odoo#72640
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Stefano Rigano <sri@odoo.com>
This could save some time when `_compute_quantity` is used thousands times in
request and there are thousands UOMs in the system
* if qty is zero, then result is zero
* if to_unit is the same, then result is `round((qty / factor) * factor) = round(qty)`
---
opw-2549026
closesodoo/odoo#72582
X-original-commit: a122db226cdf801675daaee5a69bcb47a47ab174
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
When consulting a delivery slip, a portal user won't see the lots/serial
numbers used.
To reproduce the error:
(Need demo data)
1. Create a product P
- Product Type: Storable
- Tracking: By Lots
2. Update its quantity
3. In Settings, enable "Display Lots & Serial Numbers on Delivery Slips"
4. Create + Validate a SO:
- Customer: Joel Willis
- Lines: 1 x P
5. Validate the delivery
6. Log in DB with 'portal' (Joel Willis)
7. On SO, open the Delivery Slip
Error: The product's lot is not mentioned
Here is the condition to display the lot:
https://github.com/odoo/odoo/blob/c61db20204700a375f7005f50f95b44a60c3bb70/addons/stock/report/report_deliveryslip.xml#L77-L79
Problem is that portal users are not part of
`group_lot_on_delivery_slip`
When enabling the option, the groups are updated here
https://github.com/odoo/odoo/blob/adccb562209c2431a49438d36794f0765f1bc86d/odoo/addons/base/models/res_config.py#L570-L576
`implied_group` (which is `stock.group_lot_on_delivery_slip` in our
case) is added to `groups.implied_group`
The variable `groups` comes from `classified`, which is defined thanks
to method `_get_classified_fields` (see L553 in above code block)
And here is an extract of how this method works:
https://github.com/odoo/odoo/blob/adccb562209c2431a49438d36794f0765f1bc86d/odoo/addons/base/models/res_config.py#L460-L462
At some point, it checks if the field `group_lot_on_delivery_slip` has
an attribute `group`. In case `group` is not defined, the group
`base.group_user` is used. This is the reason why, by default, the
option is enabled for internal users only instead of all users.
Therefore, we just need to define the attribute `group` to the field
`group_lot_on_delivery_slip`
OPW-2558761
closesodoo/odoo#72656
X-original-commit: 475b35397b7254012a082a1206c478084c069857
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Before this commit, the template of some dynamic classes (usually as WOWL to legacyAdapters)
were registered at each definition of the class which is potentially at every doAction/switchView
After this commit, they are all registered only once, as early as possible.
closesodoo/odoo#72476
Related: odoo/enterprise#19199
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Before this commit, when clicking on menus or debug items or use menu items
the URL briefly changed pushing an unwanted history entry.
We do want those to be links (tag `a`) with an href to be able to open in a new tab.
But we don't want the current url hash to change because of it.
This commit fixes this.
on a legacy form view, do an action in target new
The view in target new should, during its onchange, trigger a ValidationError
Before this commit, the dialog_container was stuck in an error loop.
This was because the received error was never an instance of Error, rather it was
a legacy error event. So it was never transmitted upstream were the ErrorHandler could remove
the dialog in error from is dialog array.
After this commit, the ValidationError mesage is displayed.
This commit additionally fixes another issue:
An action in target main that failed to render erased the whole DOM. This is not what we want,
at least for now. Imagine a list view, open a record, this record fails to load. We still want to be
on the list view, not in a blank state.
Before this commit, the error service bound its listeners onto window.
This may create pollution when executing more than one test instanciating an error_service
After this commit, we bind the handlers onto browser, which is fully in our control in tests.
Open a action in target new that you'll know will fail to open.
Make sure you put an onClose callback when executing doAction.
Open another action in target new, that will succeed.
Before this commit, the onClose of the first dialog is executed, while it should not.
Indeed, if the dialog fails, the whole business flow is invalid altogether
and no more business operation (in the onClose) should be executed
After this commit, the onClose callback of the failing dialog is not executed.
Steps to reproduce the bug:
- Go to website app > configuration
- Set the visibility of all the blog to Website A (So that it's not visible on Website B)
- Go to the Blog menu of Website B
- A traceback is triggered
Problem:
The `all_tags` function calls an SQL query to get the tags related to the website blog
with a where condition based on the blog_id. But since there is no blog linked to the site.
The request fails and an error is raised.
Solution:
Do not load the tags, if there is no blog for the website.
Opw-2545315
closesodoo/odoo#72636
X-original-commit: 4d8fc86e4e6beb2171e3bebbabd532086d884d59
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
closesodoo/odoo#72548
X-original-commit: bfa7c9e78037cd0abda3e8f0a9a519a600988e9c
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
The company is needed in the context to get the paper format for
instance because of `get_paperformat`
X-original-commit: a1526eb4e5b1eb7cada603d7fcee7bb77c64bbac
Steps to reproduce the bug:
- Go to settings > create a new company :
- Choose the country : `Mexico`
- fill in the VAT field : ESA2005273X1
- save
- Validation error is triggered
Problem:
The Mexican VAT can be on the format: "MXESA2005273X1" or "ESA2005273X1".
But only the "MX .." format is accepted for the moment,
and it fails in the case of "ES.." because the function checks if it is a valid Espganol VAT number.
In the case of failure, we use the `partner.commercial_partner_id.country_id` to get the country code.
The problem is when creating the res.company, we also create a res.partner
with a few fields within `VAT` except `country_id` field
while we use it in the `check_vat` function : https://github.com/odoo/odoo/blob/7a7aacedde81998ec0f1a7f3283337236e56de42/addons/base_vat/models/res_partner.py#L167
Opw-2573557
closesodoo/odoo#72633
X-original-commit: a6a46c95e4947997892b21f407132574da1c7ff1
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
Add mapping rules to enable the electronic invoicing of document types
"CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" (60) and
"CUENTAS DE VENTA Y LIQUIDO PRODUCTO B" (61).
closesodoo/odoo#72619
X-original-commit: 9fb221459e1137c0622c14a57ec408b3b5f65fe6
Signed-off-by: William André (wan) <wan@odoo.com>
The purpose of this task is there are several places where the
duration is expressed in hours even though the encoding unit
is in Days. This creates inconsistencies.
In this commit, we convert hours into days when the encoding
unit is in Days. Also, we changed the string of the fields
according to the encoding unit.
closesodoo/odoo#70512
Task-id: 2512950
Related: odoo/enterprise#18197
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Before this commit, a traceback would occurs in sale_management calendar view when the user would try to display the popover of a sale_order.
```js
basic_model.js:2399 Uncaught (in promise) Error: for modifier "readonly": Unknown field state in domain
at Class._evalModifiers (basic_model.js:2399)
at calendar_popover.js:203
at Function._.each._.forEach (underscore.js:145)
at calendar_popover.js:180
at async Promise.all (index 1)
_evalModifiers @ basic_model.js:2399
(anonymous) @ calendar_popover.js:203
_.each._.forEach @ underscore.js:145
(anonymous) @ calendar_popover.js:180
Promise.then (async)
_renderEventPopover @ calendar_renderer.js:861
eventClick @ calendar_renderer.js:416
Calendar.publiclyTrigger @ main.js:6981
EventClicking._this.handleSegClick @ main.js:6462
realHandler @ main.js:385
```
It would happen because the domain of the partner_id is ["state", "not in", ['draft', 'sent']] but the state field is invisible="1" in the view.
state was absent during of the evalContext in the _evalModifiers function.
closesodoo/odoo#72617
Taskid: 2524993
X-original-commit: 0d636c0f8dbcfb4b7adda26c0edc02a12b0c7e44
Signed-off-by: Michaël Mattiello <mcm-odoo@users.noreply.github.com>
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
When buying a product on website shop, after the payment with SIPS, the
page is redirected to an Error message: "We are not able to find your
payment, but don't worry. You should receive an email confirming your
payment in a few minutes. If the payment hasn't been confirmed you can
contact us."
To reproduce the error:
1. In Payment Acquirers, enable Sips
2. Go on website shop
3. Add a product to the cart, Checkout
4. Pay with Sips
- Visa card number: 4100000000000000
5. Back to Web-shop, if the payment has been successfully processed,
repeat steps 2 -> 4
Error: The message "Your payment has been successfully processed. Thank
you!" is not displayed. Instead, the message "We are not able [...] you
can contact us." is displayed.
This message is displayed when:
https://github.com/odoo/odoo/blob/5945806c151b13d9d4cc13aa0a6c96a6b1bbad5f/addons/payment/controllers/portal.py#L65-L69
i.e., when the transactions list is empty. Here is how to get the list:
https://github.com/odoo/odoo/blob/5945806c151b13d9d4cc13aa0a6c96a6b1bbad5f/addons/payment/controllers/portal.py#L38-L42
It uses the session of the request. The cookie `session_id` is used to
identify the current session. However, after the payment on SIPS, the
page is redirected to `/payment/sips/dpn` with a POST request. Since the
session cookie has the attribute `SameSite=Lax` and the HTTP request is
a POST, the cookie will be filtered out:
https://drive.google.com/file/d/1xfx3YWkfonO3nK-8Rew45uSoR4lkpjpY/view?usp=sharing
(Browser information: This cookie didn't specify a "SameSite" attribute
when it was stored and was defaulted to "SameSite=Lax," and was blocked
because the request was made from a different site and was not initiated
by a top-level navigation. The cookie had to have been set with
"SameSite=None" to enable cross-site usage)
As a result, the server creates a new one. This is the reason why the
transactions list is empty: the list is based on a new session.
Adding the attribute `save_session = False` to the route will prevent
the server from creating a new session cookie and add it in the POST
response.
OPW-2518377
closesodoo/odoo#72611
X-original-commit: 9637a287923c6b82acfd487ed32d6bbc1fdf74b6
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Before this commit, the clickEverywhere test was run for the demo
user on all apps available for the admin. It thus crashed on the
apps that aren't available for the demo user.
closesodoo/odoo#72430
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Before this commit, when we wanted to select first level menus
inside an app (i.e. menus available in the navbar), we could by
mistake select sub-menus if the dropdown was opened (e.g. if it
was previously tested). For instance, it happened in the 'Apps'
app. It then led to wrong index computation, and a traceback. As
a consequence, the nightly build failed as the clickEverywhere test
didn't pass.
Steps to reproduce :
- Install `CRM` and `Sales` modules
- Go to Settings, activate "External Email Servers" and
set an alias.
- Edit 'Sales Team Europe' : add an alias
(ensure alias end with the "External Email Servers" alias)
- Send a mail to the europe sale team alias email with a
base64 image in the html body
ex: <img alt="" src="data:image/png;base64,ABCDE123....789">
Issue :
- Traceback is raised.
("ValueError: Wrong value for ir.attachment.type: 'opportunity'.")
Cause :
Both `crm.lead` and `ir.attachment` have a `type` field.
When creating the thread, in this case of crm.lead model,
it will add the 'default_type' and 'default_team_id' to the
context.
The context will be inhrited and used on the creation of the
ir.attachment (in this case its the base64 encoded image
inside the body).
Since no `type` was provided while creating the ir.attachment,
it will set the type from `default_type` in context since
available.
Solution :
- Clean the context (in this case, it will remove `default_X` values)
when creating the ir.attachment .
opw-2551461
closesodoo/odoo#72613
X-original-commit: 4504c9d8069082c9542226fbafdbf309089cf7a9
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the "Edit View" debug item only worked for
kanban, list and form views. For the other views, it opened a
blank form view. The reason is that for the other views, it didn't
correctly get the id of the view to edit.
Bug reported in the wowl-bugs pad
closesodoo/odoo#72523
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit the doAction method of the action_service did not support
to pass props directly to the Component. Only a few ad-hoc options were passed though.
After this commit, doAction can take a key "props" in options, that will be passed to the Component
(a View or a ClientAction)
the new API becomes
```ts
interface Options {
props: { [key: string]: any };
...
}
doAction(action: ActionRequest, options: Options);
Note that some props (like withFilters) are set by the action service
and cannot be set via the key "props".
Alongside the change mentioned above, we take the opportunity to align the
terminology used in action service to the one used server side: we know use
the terms resModel, resId, and resIds instead of model, recordId, and recordIds.
```
closesodoo/odoo#72397
Related: odoo/enterprise#19127
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
PURPOSE
Make crm.team deletion effect explicit on main models (excluding wizards
or reports). Purpose is to ensure deleting a crm team has known side
effets.
SPECIFICATIONS
Update PLS frequencies of "no team" leads when unlinking teams. Instead
of loosing those statistics merging them with "no team" is probably better even
if not completely right. Removing teams with a lot of PLS information is
something that is not a primary use case.
M2O on crm.team set to CASCADE
* crm.lead.scoring.frequency: as we remove the team no need to keep the
PLS data -> change to "cascade";
* crm.team.member: when removing a team, remove its members as it prevents
from unlinking the team;
M2O on crm.team set to SET NULL
* account.move: void team_id field but track it to keep history;
* crm.lead: void team_id field as it will be taken back into assign
process (either manual or automatic), and will therefore be managed
by other sales persons. In case of archived / lost leads setting to
void has no real issue;
* crm.stage: void team_id and set stage as shared to avoid loosing stage
information for existing leads in that stage;
* res.partner: void team_id taking care of this customer as this field
is mainly informative anyway;
* crm.iap.lead.mining.request: void team_id as it only impacts generated
leads. Those will be created with a void team which is ok;
* crm.reveal.rule: void team_id as it only impacts generated leads. Those
will be created with a void team which is ok;
* event.lead.rule: void lead_sales_team_id as this impact generated leads.
Those will be created with a void team which is ok;
* pos.config and pos.oser: void crm_team_id field. It is optional as it is
not a core field of this model. Pos configurations and orders are still
valid without team assigned on it;
* sale.order: void team_id field but track it to keep history;
* website: void salesteam_id field;
Prevent unlink when having more than 5 SO not canceled. If more than 5 active
SOs in the team, we consider this team to be actively used. 5 is some random
guess based on "user testing", aka more than testing CRM feature and less
than use it in real life use cases.
LINKS
Task ID-2507750
COM PR odoo#70645
ENT PR odoo/enterprise#18266closesodoo/odoo#70645
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Purpose is to avoid loosing frequencies and also avoid rebuilding the whole
frequency table. We choose to merge frequencies from team about to be unlinked
with "no team" frequencies.
SPECIFICATIONS
Update PLS frequencies of "no team" leads when unlinking teams. Instead
of loosing those statistics merging them with "no team" is probably better even
if not completely right. Removing teams with a lot of PLS information is
something that is not a primary use case
LINKS
Task ID-2507750
COM PR odoo#70645
Fix a small glitch where archived ribbon is a bit bigger than its kanban
card, leading to a suboptimal display.
Task ID-2507750
COM PR odoo/odoo#70645
ENT PR odoo/enterprise#18266
PURPOSE
Make crm.team deletion effect explicit on main models (excluding wizards
or reports). Purpose is to ensure deleting a crm team has known side
effets.
SPECIFICATIONS
M2O on crm.team set to CASCADE
* crm.lead.scoring.frequency: as we remove the team no need to keep the
PLS data -> change to "cascade";
* crm.team.member: when removing a team, remove its members as it prevents
from unlinking the team;
M2O on crm.team set to SET NULL
* account.move: void team_id field but track it to keep history;
* crm.lead: void team_id field as it will be taken back into assign
process (either manual or automatic), and will therefore be managed
by other sales persons. In case of archived / lost leads setting to
void has no real issue;
* crm.stage: void team_id and set stage as shared to avoid loosing stage
information for existing leads in that stage;
* res.partner: void team_id taking care of this customer as this field
is mainly informative anyway;
* crm.iap.lead.mining.request: void team_id as it only impacts generated
leads. Those will be created with a void team which is ok;
* crm.reveal.rule: void team_id as it only impacts generated leads. Those
will be created with a void team which is ok;
* event.lead.rule: void lead_sales_team_id as this impact generated leads.
Those will be created with a void team which is ok;
* pos.config and pos.oser: void crm_team_id field. It is optional as it is
not a core field of this model. Pos configurations and orders are still
valid without team assigned on it;
* sale.order: void team_id field but track it to keep history;
* website: void salesteam_id field;
Prevent unlink when having more than 5 SO not canceled. If more than 5 active
SOs in the team, we consider this team to be actively used. 5 is some random
guess based on "user testing", aka more than testing CRM feature and less
than use it in real life use cases.
LINKS
Task ID-2507750
COM PR odoo/odoo#70645
ENT PR odoo/enterprise#18266
For the unit price (field l10n_latam_price_unit), we need the number
rounded based on the product price precision.
To compute it we use the method compute_all that rounds using the
currency accuracy, so to fix this we multiply and divide for
10^(decimal accuracy of product price) to get the price correctly rounded.
Steps to replicate the error:
1) In a base with l10n_ar localization installed change the decimal
accuracy of "Product Price" to 5 digits (keeping the currency
precision in two digits).
2) Create an invoice with a product with price $10.12345
3) Print the invoice and check the column price unit.
Before this commit, the price unit would be $10.12000.
closesodoo/odoo#72579
X-original-commit: 17e19c6bf787fd2bf77476ffcfa1d934058aa7ec
Signed-off-by: William André (wan) <wan@odoo.com>
Warn the user in case of unfilled or invalid google map API key.
task-2427575
closesodoo/odoo#72580
X-original-commit: f338d52e110bd6fa557169d370976ee35f5b56a5
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
As it is possible to hard-code the DirectLink URLs used by Odoo in the
backend of Ogone, some users might encounter payment issues after
migrating to 14.3+ if they did not replace those URLs by the new ones.
This commit adds back the URLs that were used by DirectLink prior to
14.3 and allows requests to target both the new and the old URLs.
task-2494916
closesodoo/odoo#72566
X-original-commit: 16ee2651ba7f537e3644da2fd80595896e3421fc
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Co-authored-by: Toufik Ben Jaa <tbe@odoo.com>
Before this commit, rainbowman message was displayed using
`t-raw` in template.
Now, the message is escaped by default and needs to be marked as
HTML to be displayed as well.
closesodoo/odoo#72392
Task-id: 2575435
Related: odoo/enterprise#19121
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Prior to this commit, the spaces in the template were transformed into
non-breaking spaces by the html editor while editing the html field
content.
The unordered list with icons as list item also failed to be compatible
with the editor.
With this commit, we remove the indents in the templates to prevent this
behavior.
It now also uses the css class defined by the editor to generate the check
lists.
closesodoo/odoo#72571
X-original-commit: ce9c39125da9ebe3e19dbb325fc4488a8b689ad1
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
It seems some terms are no translatable so purpose of the task is
to find those terms ans update to make them translatable.
So in this commit, translate the text attribute when the node is field
tag and this node contains widget='url' in its attributes. and
also make the project name as translatable.
closesodoo/odoo#71406
Taskid: 2487710
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Co-authored-by: xavierbol <xbo@odoo.com>
In order to also match ir_http.py and qweb files inside auth modules,
the generic rules for those now also notify rd-security.
closesodoo/odoo#72537
X-original-commit: cf50e37992381d0db8ff886900e154d3f57eadd8
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Introduced with 7fb016f9966b
[0] access could crash, recordset could be empty after `filtered`.
Step to reproduce:
- Add admin group to website top level menu (Website > Debug > Menu)
- Try to access frontend as non admin
opw-2573763
task-2574346
closesodoo/odoo#72535
X-original-commit: 759d920d799d332220d86467d83aeb9334b61ce2
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Purpose
=======
In 14.3 we added the possibility to upload attachments when logging
an email. In the commit, we add the translation for the corresponding
error message.
Task 2545048
See odoo/odoo/pull/71543
See odoo/mail-client-extensions/pull/11
closesodoo/odoo#72530
X-original-commit: ba747ed81631cca549a380446cd8f05e711bdf76
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes the multi_company access error when the user is attempting to
see a record belonging to another company then the one he is logged in to from
the plugins, upon login, it returns all the company ids related to the user so
that the plugin redirects the user to the record with all companies ticked.
Task-2541205
closesodoo/odoo#72529
Plugin-pr: https://github.com/odoo/mail-client-extensions/pull/10
X-original-commit: 92972fa16920e070e533040439243a0257357aad
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, all actions, even those executed in target
"new" (i.e. in dialogs) updated the document's title. Actions in
dialog should not do that.
closesodoo/odoo#72526
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Resupplying a product with a purchase order ask to choose the suitable
supplier to put on the purchase order. Another search is perform on top
of that to compute de date to order in order to respect the lead days
promise by the supplier. The issue is that the first search is done with
the orderpoint company into account but not the second one.
This commit passes the company to _select_seller when computing the total
lead days required for an order.
opw : 2557125
closesodoo/odoo#72466
X-original-commit: c1bd985ef6a77c8848c4a2a8b92508511d9d8638
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
The import logging (ish) assumes that if an exception has at least 2
args the second arg is metadata added by the callee.
As it turns out, `UnicodeEncodeError` has *five* arguments, none of
which is added by us. So if encoding something fails during the
process (e.g. because the file contains a lone surrogate, which leads
to the database insert failing when psycopg2 tries to encode the query
to UTF8), then the `_log` function itself will fail, yielding a very
unhelpful error of:
dictionary update sequence element #0 has length 1; 2 is required
(because we tried to update a dict using a string).
This issue occurs only during *field conversion* and most fields have
no need to interact with the database (so don't need to encode the
value, which is what fails), however it is a problem when the invalid
string is used as a record name to look for (e.g. an m2o).
Further improve the experience by converting the UnicodeEncodeError to
a ValueError using the stringified UEE: `_log` assumes the first
argument to the exception is an error message of some sort, but for
UnicodeError subclasses it's just the encoding involved in the
error (here `utf-8`), which doesn't really serve as an error message.
Stringifying the exception generates a complete error message which is
quite a bit more helpful.
Specific update notes:
* avoid modifying the exception in-place, doesn't seem useful
* not sure why `field_name` was added as part of the augmentation
rather than up-front when `record` is created
Issue 2480064
closesodoo/odoo#72517
X-original-commit: 6c3c500929cd463cd3a1749f4ede8f3a8afd5748
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
If a user has no accounting permission, when he opens/closes a POS
session (without any sale), he will not be able to close the session
To reproduce the error:
(Use demo data)
1. Remove all Marc Demo's permissions for the Accounting module
2. Login with Marc Demo
3. Open a POS Session
4. Close the POS Session
Error: "Sorry, you are not allowed to delete documents of type 'Journal
Entries' (account.move) [...]"
Note: if the user processes at least one order during the POS session,
he will be able to close it thanks to sudo mode:
https://github.com/odoo/odoo/blob/369331dfdc144cf852c80c99d00ce8d5da843be1/addons/point_of_sale/models/pos_session.py#L302
OPW-2523187
closesodoo/odoo#72516
X-original-commit: 766d03c84c1e51e000494d49265c32ab096d602e
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Purpose
=======
Allow to upload the attachments of the email when logging it on the
partner / lead / ticket.
Technical
=========
The attachments posted on this new endpoint are base 64 encoded and
added in the JSON data in a list (name, encoded content).
Links
=====
Task 2545048
See odoo/mail-client-extensions/pull/11
closesodoo/odoo#72515
X-original-commit: 71626ad727fd573fd98e595e0ae964ce0559e547
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The activities systray item didn't work anymore. Nothing happened on
click.
It was because the do action event was never caught. The systray item
logic had a different flow and didn't go through the ViewAdapter code.
We fix this by adding a listener on window (through legacy service
provider) to execute this code when the do_action bubbles up.
Instead of using the legacy service provided, we could have done this
in the SystrayItemAdapter, but we then have the legacy environment and
would need more work for the same result.
closesodoo/odoo#72406
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In commit adf34b9001eb34e, we remove unused token param.
These token's parameters are still a leftover of the previous cleaning.
This commit fixes the export in Xls in view form that crash with:
closesodoo/odoo#72499
Typeerror: index() missing 1 required positional argument: 'token'
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit: when writing something in signture field in stock.picking
and enable signature field in listview throws traceback.
After this commit: when signature field is set and enabling it in list view
will not throw traceback, traceback was generated because boolean field
was applied on Image field, to fix it simply remove boolean widget on
signature field.
task-2570929
closesodoo/odoo#72479
X-original-commit: 2679b6721f74ad26f790285855102a44e30fac71
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Adrien Widart