The commit https://github.com/odoo/odoo/pull/137446/commits/a0b59559
leads to a traceback when clicking on "Download sale report" button
when closing the session.
Traceback:
```
tuple index out of range
Traceback (most recent call last):
File "/data/build/odoo/addons/web/controllers/report.py", line 113, in report_download
response = self.report_routes(reportname, docids=docids, converter=converter, context=context)
File "/data/build/odoo/odoo/http.py", line 697, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/data/build/odoo/addons/web/controllers/report.py", line 42, in report_routes
pdf = report.with_context(context)._render_qweb_pdf(reportname, docids, data=data)[0]
File "/data/build/odoo/addons/account/models/ir_actions_report.py", line 58, in _render_qweb_pdf
return super()._render_qweb_pdf(report_ref, res_ids=res_ids, data=data)
File "/data/build/odoo/odoo/addons/base/models/ir_actions_report.py", line 819, in _render_qweb_pdf
collected_streams = self._render_qweb_pdf_prepare_streams(report_ref, data, res_ids=res_ids)
File "/data/build/odoo/addons/account_edi_ubl_cii/models/ir_actions_report.py", line 58, in _render_qweb_pdf_prepare_streams
collected_streams = super()._render_qweb_pdf_prepare_streams(report_ref, data, res_ids=res_ids)
File "/data/build/odoo/addons/account_edi/models/ir_actions_report.py", line 14, in _render_qweb_pdf_prepare_streams
collected_streams = super()._render_qweb_pdf_prepare_streams(report_ref, data, res_ids=res_ids)
File "/data/build/odoo/addons/account/models/ir_actions_report.py", line 20, in _render_qweb_pdf_prepare_streams
return super()._render_qweb_pdf_prepare_streams(report_ref, data, res_ids=res_ids)
File "/data/build/odoo/odoo/addons/base/models/ir_actions_report.py", line 708, in _render_qweb_pdf_prepare_streams
html = self.with_context(**additional_context)._render_qweb_html(report_ref, res_ids_wo_stream, data=data)[0]
File "/data/build/enterprise/web_studio/models/ir_actions_report.py", line 19, in _render_qweb_html
return super(IrActionsReport, self)._render_qweb_html(report_ref, docids, data)
File "/data/build/odoo/odoo/addons/base/models/ir_actions_report.py", line 895, in _render_qweb_html
data = self._get_rendering_context(report, docids, data)
File "/data/build/odoo/odoo/addons/base/models/ir_actions_report.py", line 910, in _get_rendering_context
data.update(report_model._get_report_values(docids, data=data))
File "/data/build/odoo/addons/point_of_sale/models/pos_order.py", line 1538, in _get_report_values
data.update(self.get_sale_details(data['date_start'], data['date_stop'], configs.ids, data['session_ids']))
File "/data/build/odoo/addons/pos_daily_sales_reports/models/pos_daily_sales_reports.py", line 68, in get_sale_details
user_currency = config_currencies[0]
File "/data/build/odoo/odoo/models.py", line 5901, in __getitem__
return self.browse((self._ids[key],))
IndexError: tuple index out of range
```
opw-3558365
closesodoo/odoo#139128
X-original-commit: 8b19e29e8ead8229cebbb6224979264a59334209
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Signed-off-by: Ahmad Khanalizadeh (khah) <khah@odoo.com>
Steps
=====
- Install hr_timesheet
- Create a project shared (in edition) with a portal user
- Creata a task with a subtask and log timesheets for the subtask
- As a portal user open the parent task form
- Go in the timesheet tab
- Click on the button "Sub-tasks Hours/Days Spent" at the bottom of the
page
Issue
=====
An access error appears for an uom.uom record.
Cause
=====
Portal users have no access to uom.uom records. The method
_apply_timesheet_label uses this model to determine if the time spent
needs to be displayed with an 'hours' or a 'days' label. This raises a
traceback when it is called by a portal user.
Fix
===
The method _apply_timesheet_label is called as sudo, following the fix
that was already done in project sharing (see odoo/odoo#73341).
task-3527521
closesodoo/odoo#139125
X-original-commit: 01b1cf07bc1fb618d34065271cdc07fce561337f
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In this commit we have manage sufficient space between allocated
hour and the percentage.
task-3248965
closesodoo/odoo#139113
X-original-commit: 1722359f1bedd238b162dd8f4c07d648d6d2d114
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
permissions) see Invoices & Bills at /my/account
Issue:
Internal user cannot see their Invoices & Bills at
portal without permissions in the accounting
Fix:
Verify that the read operation is allowed for the current user
closesodoo/odoo#139141
X-original-commit: 5ebab949a06ec338cc28e912317a74bbfb3fe6ac
Signed-off-by: William André (wan) <wan@odoo.com>
attribute style has two apostrophes (') at the begininng and end
this prevents the bold style from being applied
The modification was made in the tax_totals.xml file
while ensuring that it doesn't affect any other element
closesodoo/odoo#139087
X-original-commit: 7414d61e85e38c6159c53337be6c1750d3b7dfcd
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
As mentioned in https://github.com/odoo/odoo/pull/105848#discussion_r1324796532, the ``_getCurrentLocation`` method was called on every page of ecommerce, while it was doing nothing unless if we are on the payement page.
Putting the call in the ``if`` ensures that there are carriers on the page and thus calls it only when on the payment page.
closesodoo/odoo#139086
X-original-commit: 65e7535fc9392e7b9355a31fa8f7c8abc1e3518f
Signed-off-by: Martin Maes (marm) <marm@odoo.com>
When the user has contacts with different websites and tries to create an order,
a traceback will appear.
Steps to produce the error:
- Install 'website_sale' and 'contacts'
- Create 2 websites: 'Website A' and 'Website B'
- Go to Contacts > New > In Sales & Purchase, select 'Website A'
- Create another contact with 'Website B'
- Go to Website > eCommerce > Orders > New > try to enter Customer
Error: A traceback appears:
'Expected singleton: website(6, 16)'
https://github.com/odoo/odoo/blob/1cb866347eed8c43d1da225f441cc3b3ce9c5a01/addons/website/models/res_partner.py#L42
Here, instead of partner, self is used.
So when the user tries to create an order,
it will lead to above traceback.
sentry-4545021252
closesodoo/odoo#138929
X-original-commit: b053805d96c5fd8a9579e49b4f842f488c4adf60
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Renilkumar Kajavadra (reka) <reka@odoo.com>
Before this commit, when an internal user attempted to open
profile of a user from dropdown menu of private chat window
with that user, there was crash.
Steps to reproduce:
- install `test_l10n_be_hr_payroll_account` with demo data
- connect as Laurie Poiret
- Open chat window with Marc Demo
- Click chat window header => "Open Profile"
It happens because the action to open the profile was attempting
to open "hr.employee" form, which require specific access rights
(hr manager). The current user is not necessarily an hr manager,
so the action fails.
This commit fixes the issue by opening the public form view of the
employee, which is accessible to all internal users.
opw-3555889
closesodoo/odoo#139134
X-original-commit: bdce8c72cd06cb783973beb62382bfd8a8ae249e
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The command palette has the priority when useAutoFocus is call.
Like that, the command palette will not lose focus when clicking
on an app on the home menu and then directly opening the command
palette before the app mounting
TASK ID: 3338117
closesodoo/odoo#139124
X-original-commit: 660d27ac38c225559ea3697a24a34ac70ede8ec1
Signed-off-by: Florent Dardenne (dafl) <dafl@odoo.com>
(Introduced in 16.3, 86c6266)
--- ISSUE
From there, partner_ids and partner_all_ids m2m fields became computed
fields in order to return only active records as we read them from
the slide.channel.partner table, not checking the active field of that
table (not supported by framework).
Ir rules of records check if current user's partner is inside partner_ids,
or partner_all_ids of a given course. (joined the course for partner_ids,
invited or joined the course for partner_all_ids)
The issue is that all ir rules searching on these fields lead to very
slow loading of slides (channel, slide, homepage) and forum pages (as
soon as we have a forum linked to a course). This comes from the fact
that in some templates, we read records and evaluate rules on the spot,
in python. (for instance tags of courses on homepage)
As some courses have tens of thousands of attendees, this evaluation is
very slow in python, and there is no quick solution at framework level.
Therefore, computing thousands of partners for each access rule linked
to a course is too slow.
--- SOLUTION
The existing fields is_member and is_member_invited are used inside ir
rules instead. _search methods are added and we check whether course
is inside courses of current user's partner ones. It improved all times
a lot, see BENCHMARK below.
Tests already exist to assert the search methods indirectly.
--- LOCAL BENCHMARK (16.3) - IntelCore i5-8265U CPU 1.60GHz - Firefox
ROUTE BEFORE (s) AFTER (s)
/slides 5 <0.15
/slides/all 7.6 <0.15
/slides/course_c 4.2 <0.2
/forum 5.5 <0.15
/forum/forum_c 6 <0.25
/forum/forum_c/post_y 4.4 <0.25
/forum/forum_c/post_y/edit_answer 2.5 + 2.5 <0.3 total
/forum/forum_c/post_y/edit 2.8 <0.2
/forum/forum_c/post_y/reply 3 (+6 post) <0.35 total
/profile/user/id 2.3 <0.4
DETAILS
- course_c: 43k attendees
- forum_c: forum of course_c
- post_y: 2-3 answers
- logged user: 'portal', with 7 courses
- deactivated GC cron as many populated invited attendees were
to be removed, and it can take a lot of time
POPULATIONS
- 20k forum.forum (avg 2 answers)
- 20k mail.message (about 2 answers per post)
- 10 forum.forum (+20 on courses)
- 20 slide.channel (half 'members' visibility)
- 300k slide.channel.partner
- 'large' for other models
--- LINKS
UPG PR: odoo/upgrade#5246
Task-3444633
closesodoo/odoo#139104
X-original-commit: 019d9d4808994cd819d13fab2d6ddfdffeb621e7
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit does some preparation work to allow the appointment type to specify
a custom mail template to send when an appointment is booked/canceled.
It simply adds a hook method to be able to customize the behavior when sending
the invitation email as well as removes some parts of the current invitation
template that will be rendered useless.
See enterprise counterpart for more details.
Task-3547269
closesodoo/odoo#138547
Related: odoo/enterprise#48874
Related: odoo/upgrade#5269
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Fixes a few issues in `jsvat`:
- Since the end of 2022, valid Belgian VAT numbers starting with `BE1`
have been attributed, the regex had to be adjusted.
- Since Brexit, Northern Ireland has to use the `XI` prefix instead of
`GB`.
- Removes the default country code logic. As Odoo is used worldwide, it
didn't make sense to use `GB` as the default country code when no
country code is mentioned.
closesodoo/odoo#139098
X-original-commit: f486a41f729ea7e934c81671972b3b1162986860
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Suppose the following configuration:
- 1 BOM
- 2 Lines with the same product_id , same uom_id
- Enough stock for the first line
- Incoming PO for second line, with date_order=today
Currently the line will be displayed as "Available" because
the availability_delay of the second component is also 0.0.
Changing > to >= marks the second line as "Expected", which makes
more sense. This also fixes the same issue for "Estimated" lines.
closesodoo/odoo#139067
X-original-commit: 249f331f9524860bbf0f0a7b092cbd26ebdb6840
Signed-off-by: Aurélien van Delft (avd) <avd@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Currently when showing a BoM Overview, the stock_availability
is computed for each bom's component. This means that there will
be one read_group on report.stock.quantity by component. As this
is a postgresql View, querying it too often can degrade the overall
performances.
This commit tries to improve on that by computing the stock_availability
of all components without bom at the same level at the same time. Let's say
there is a BoM with 4 components, none of which has a bill of materials
of their own. Before this commit there would have been 4 read_groups, one
by component. Now there will only be 1 read_group.
Example speedup: customer database with 7M stock.moves,
7M stock.move.lines. BoM Overview with 33 nodes in the component
Tree: 3min30s -> 1min30s
X-original-commit: 8fa7a11bf41152a06537144c20d04921d3643272
Part-of: odoo/odoo#139067
Set the default value of provider's `journal_id` to the first compatible
bank journal, if such exists, to improve the user experience.
Part-of: odoo/odoo#138466
Before this commit:
- project.task > list view: Currently, the progress is displayed
in purple if less than 100% and in red if above. The two colors
don't contrast a lot, making it hard to read. In addition, it
is not coherent with the color we usually apply for the remaining
hours in the rest of the app.
- onbording tour: the manual saving step is no longer necessary
as records are now automatically saved. In addition, showing it
doesn't provide a wow effect and is an extra opportunity to lose
people in the process
After this commit:
- the following color code was applied for the progress bar:
*if progress < 80 -> green
*if progress is between 80 and 100 included -> orange
*if progress > 100 -> red
- step removed.
task-3475170
closesodoo/odoo#132854
Related: odoo/enterprise#46162
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, when the Database is using an enterprise Azure account/environment which has a configuration of
'Multifactor authentication', the users gets pop-up asking for approval.
See https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/application-sign-in-unexpected-user-consent-prompt
The solution is to remove the parameter 'prompt': 'consent' from the authentication URL which is not considered a good practice by
the Microsoft support (see attachment in task).
closesodoo/odoo#139075
Taskid: 3463417
X-original-commit: 1e1f84531b37f7f256f8a8670ed7efddae6fe1ba
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Steps to reproduce
==================
- Install purchase_product_matrix,web_studio
- Go to purchase
- Click on a record
- Open studio
- Click on the "Products" tab > Edit List view
- Edit the product field
- Widget: Many2one
- Disable creation: enabled
- Close studio
- Create a new record
- Add a new line
- Type some random text in the product field
-> The option create is available
Cause of the issue
==================
When the can_create attribute is not passed, the `canCreate` ends up
undefined. This means the default value of true is used and the
`no_create` option is ignored.
The can_create attribute should actually be passed and there is a bug in
python in the `_editable_tag_field` function, but it is not something we
can change in stable due to the fact it it requires an explicit change
in some views to pass the validation and thus, this requires an addon
upgrade (`-u ...`).
See https://github.com/odoo/odoo/pull/138032
opw-3432903
closesodoo/odoo#139068
X-original-commit: 4b6756e1775488e230bc25767adf5744f0ea9149
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Before this commit, when the locale was not in english, the following
traceback was observed:
```
Uncaught (in promise) Error: The following error occurred in onWillStart: "res[employeeId][((intermediate value) + "_location_id")] is undefined"
OwlError owl.js:87
wrapError owl.js:2604
onWillStart owl.js:2647
useModelWithSampleData model.js:165
setup calendar_controller.js:48
setup attendee_calendar_controller.js:10
setup appointment_calendar_controller.js:15
setup google_calendar_controller.js:11
setup hr_homeworking_calendar_controller.js:12
setup microsoft_calendar_controller.js:11
```
closesodoo/odoo#139052
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#138918
Forward-port-of: odoo/odoo#138460
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The Chilean Peso and Colombian Peso don't have a minor unit. MercadoPago
requires amounts be expressed as integers. Failing to send such amounts
as integers results in an error.
opw-3292798
closesodoo/odoo#138859
X-original-commit: 75fa1e55207050e57b8b912b5e0607c8a3e31515
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
https://github.com/odoo/odoo/pull/138042 reworked how we define quick create in
calendar views. Before we had to specify only a single attribute, but now they
were split into two (a boolean and a form view id). This commit fixes the
calendar view definition in the calendar module to add also the boolean
attribute.
task-3551177
closesodoo/odoo#138838
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Before this commit, the highlight added on a focus record, that styling
added was useful when we displayed only the first result in the search
to be able to build a tree but since now all the records found with
the search made by the user are shown without building a tree if it
is not possible then it is no longer needed to highlight the records
found.
This commit removes the highlight added on the focused record, the one
found by the search since it is not really needed.
task-3556262
closesodoo/odoo#138803
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Before this commit, the style added in `o_hierarchy_icon` class
was only on the button in view switcher.
This commit changes the selector to be sure to apply the same style
on any icon with `o_hierarchy_icon` class.
task-3556262
Part-of: odoo/odoo#138803
Before this commit, the hr presence status icon is displayed in kanban
view of `hr.employee.public` model but not in form view.
This commit adds the icon in the form view of `hr.employee.public`
at the same place than the icon in form view of `hr.employee` model.
task-3556262
Part-of: odoo/odoo#138803
Before this commit, when the employee is off (because he is on leave)
then the presence status icon displayed in org chart, kanban and form view
should be `fa-plan`. It is not the case because `fa-circle` is also added
by mistake.
This commit changes the patch made in `hr_holidays` module to correctly
replace the icon by the `fa-plane` when the employee is on leave.
task-3556262
Part-of: odoo/odoo#138803
Before this commit, in the form view of employee, the presence status
icon displayed in the top right of the avatar image is hidden if there
is no last activity or no user linked to the employee.
This commit changes the visibility condition to have the same
visibility condition defined in the kanban view for the same icon.
task-3556262
Part-of: odoo/odoo#138803
*point_of_sale, pos_self_order, pos_self_order_epson_printer
In this commit we introduce the functionality that allows
the pos_self_order module to generate receipts.
At the moment, this is possible by using Epson Printers via HTTP.
This is done through the use of the newly added bridge module
`pos_self_order_epson_printer`.
In order to generate the data required for the receipt we add more data
on the first load of the kiosk ( such as company information ) and
also in the `_export_for_self_order` method.
Printing is done through the `printer` service from POS.
closesodoo/odoo#137397
Task: 3487638
Related: odoo/enterprise#48304
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
pos*: l10n_co_pos, l10n_fr_pos_cert, l10n_gcc_pos,
l10n_in_pos, l10n_sa_pos, point_of_sale,
pos_epson_printer, pos_loyalty, pos_mercury,
pos_online_payment, pos_restaurant, pos_sale
There is a need to print pos receipts in new environments,
such as the kiosk. In this commit we simplify the steps to
generate the receipt data and introduce a portable mechanism
for printing.
Changes:
- removed the `getOrderReceiptEnv` method; this method
was returning a lot of data that the receipt was not
actually using; we now simply use the data from
`Order.export_for_printing`. This means that it will be much
easier to recreate this data in other environments, such
as in the kiosk.
- removed the error prone `generate_wrapped_product_name` method.
It's aim was to split the orderline name, but this task is much
better accomplished by declarative css.
- removed the `Orderline.export_for_printing` method; instead,
we simply use the existing `Orderline.getDisplayData`;
- removed the `AbstractReceiptScreen` component and replaced
it's functionality with the new `printer` service;
- using this service means that we were free to remove
the `pos-receipt-print` div from the root of the pos app;
- made the receipt be a standalone component. It thus benefits
from all the advantages of components, such as prop validation
and usage of slots;
- replaced the `OrderLinesReceipt` template with the generic
`OrderWidget` component'; this greatly simplifies the code;
- created the `renderer` service. It's goal is to do for components
what `renderToElement` does for templates; we use this service to
render the receipt component for printing;
- removed jquery from the EpsonPrinter class, such that it can be
imported into projects that do not rely on jquery;
- created the `ReceiptHeader` component. This unifies the header
between all the different receipts; ( before, each receipt was
implementing it's own header )
Task: 3547597
Part-of: odoo/odoo#137397
pos*: point_of_sale, pos_online_pay
In this pr we remove the custom generation of qr codes and
adapt the codebase to rely on the `/report/barcode` api.
Task: 3550015
Part-of: odoo/odoo#137397
The current Send and Print dialog doesn't let you
generate the XML without sending it.
An additional checkbox will be added to allow that.
It can be useful in all those cases in which the XML
is not yet 100% compliant or feature-covered to let
the Odoo customer download the XML,
modify it and send it manually through the Italian
Tax Agency web portal.
closesodoo/odoo#137034
Signed-off-by: Josse Colpaert <jco@odoo.com>
When the assets are still uncommitted (new PDF printing)
then there is a context key `commit_assetsbundle` that
commits the assets in the database before the template
that generated them actually uses it. Otherwise the
PDF will be rendered without the assets.
By putting `create` here we make the record non-virtual
and it won't be recomputed.
Part-of: odoo/odoo#137034
A previous commit(ea8acc17b4)
added a compute on invoice_user_id fields to
guess the Sale Person. The problem is that by adding the compute
on the field, the readonly default value changes for True.
It causes that user can't change the sale person anymore.
no task id
closesodoo/odoo#139035
X-original-commit: af5e3eedf90d64462afc625b30dec742361389f5
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Reproduction:
1. in Website, enter Editing mode, drag a block with a button, for
example, banner
2. click on the button then click on the text above the button
3. the selection should be around the text paragraph, but it's on the
button
Note the behavior is only for the first time of clicking on the element,
e.g. when dragging and dropping a new block
Fix: The selection restoration when destroying the link tools should be
done on the spot instead of binding to the destroy of linkToolsInfos.
Without this fix, the selection restore in link tool is done after the
full selection step for o_default_snippet_text element
task-3514638
closesodoo/odoo#139031
X-original-commit: 6dcc33c6c85b605f43e8f42a5d4013eca9e0ef7a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Reproduction:
1. install website, drag a block with button
2. click at the beginning of the button text
3. type something, it will be outside of the button area
Reason:
The contenteditable is reset depending on the o_editable and
o_not_editable class in the _onPostSanitize function.
Fix: don’t do the resetting when we have the _fixLinkMutatedElements key
in OdooEditor as it indicates that the link isolation trick is executing
task-3514628
closesodoo/odoo#139030
X-original-commit: 1727317f258d184432b01b6295d01f688e298257
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Steps to reproduce:
1) Create loyalty program with default settings (10% discount on all
orders above $50)
2) Create quotation with amount >50, all products must be invoiceable on
delivered quantity, not ordered quantity
3) Add promotion with 'Promotions' button
4) Confirm order
5) Order has invoice status 'Nothing to invoice'
6) Add shipping
7) Order now has invoice status 'To invoice'
An order with shipping and no promo, or no promo with shipping, would in
both cases have nothing to invoice as long as the 'real' products are
not delivered. But when you have both a promo and delivery line, the
order is 'to invoice'.
The '_compute_invoice_status' methods of sale.order in the delivery and
sale_loyalty modules are not compatible, as the delivery compute filters
out delivery but not reward lines.
OPW-3357289
closesodoo/odoo#139014
X-original-commit: 201a4fc7144935947cd2909e4830a666bbdac02d
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Steps to reproduce:
-------------------
- being in a multi-company environment;
- have one product made that is first in alphabetical
order of "Internal Reference" throughout the database (e.g. [AAA]);
- make this product specific to one of the companies
(set the "Company" field on the product template)
- go into a different company within the database
(not the one set on this product);
- create a new discount & loyalty record, and set
the "Program Type" to "Discount Code".
Issue:
------
An access rights error occurs.
Cause:
------
When creating a `promo_code` program, we use the first product
that can be sold in the default reward values.
Solution:
---------
Take into account the company in the domain that retrieves
the default product.
opw-3538516
closesodoo/odoo#139008
X-original-commit: d80c28c78bf3237e2526a6370f9c6c0b0f8dc232
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Update the eas list in preparation for the Peppol PINT format
that will come to 17 in the near™ future
closesodoo/odoo#139005
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Issue:
Typing '@' in a chatter and waiting for the partner suggestions can
sometimes be really slow for some users, even freeze some users
browsers.
Analysis:
Since 12152279a5 the sorting on
partner suggestions has been generalized to take an arbitrary amount
of functions to apply sequential filtering. One particular of those
is `partnerCompareRegistry['discuss.recent-chats']` which makes a
call to `getRecentChatPartnerIds` which makes multiple checks for
each pair of partners in the thread to order them based on their
`lastInterestDateTime`. This property is actually quite heavy, as it
involves deserializing datetime objects and making calls to libs and
regex matches, creating a lot of garbage memory in the process.
The complexity of this machinery is atrocious:
- First `sortPartnerSuggestions` loops over all the current partners
we fetched from the backend, and in a `sort` callback we call
*each* filtering method (we shortcut on the first filtering that
succeed). So we call at worse each filter `O(n*log(n))` times.
- Since `partnerCompareRegistry['discuss.recent-chats']` is the
lowest sequence in the filtering array, we will *always* go
through it for those partners `O(n*log(n))` times, inherently calling
`getRecentChatPartnerIds`.
- This function in question gets it's list of partner from the
thread in the store, and sorts those partners with a callback
again. So again we have `O(m*log(m))` callbacks. This callback makes
8 calls to `lastInterestDateTime`, which as mentioned previously
is actually an expensive function if called frequently as it
generates a lot of garbage.
- All this garbage that is generated triggers multiple calls to the
browser GC, and it's being frequently called, either stalling the
browser for a few seconds, and for some users (as the problems
scales over quadratic for the number of partners in the
suggestions/thread) completely halting it.
Solution:
- Correct implementation of `getRecentChatPartnerIds` to not call
`lastInterestDateTime` so frequently, it was unnecessary.
- Dependency inject the call to `getRecentChatPartnerIds` outside of
the initial sorting callback, as it's independent of the sorting
parameter and can be hoisted outside of the routine and injected
into the filter.
Reference:
task-3556235
closesodoo/odoo#138988
X-original-commit: ba31d252c0738811cfe80a70bbbd7d489a45cf03
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Commit [1] changed a method to be asynchronous instead of synchronous
but did not care about where it was called or overridden. That code and
its surrounding needs to be refactored when fully switching to OWL.
Meanwhile this extracts the asynchronous part of the method to be done
once in all cases at initialization for now.
This is probably a cause of race condition or bugs but this was mainly
discovered during a master task development, preventing to code the new
feature properly.
[1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997closesodoo/odoo#138985
X-original-commit: e26c007dd14de9d0cbf76181e8054a3498e67bd9
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since https://github.com/odoo/odoo/pull/104287 the GS1 separator defined
in the nomenclature is no more used in `BarcodeParser`
`gs1_decompose_extanded` but it is used in `barcodeService`
`cleanBarcode` instead. The issue with that is `cleanBarcode` is not
called in every case.
It will if the barcode is actually scanned but it won't if the barcode
is decoded from a picture (using the device's camera) or triggered
through an event directly (thanks to the debug console and the manual
entry available in the Barcode App.)
That means if we want to support custom separators, we have to clean the
barcode also in `parse_gs1_rule_pattern`.
How to reproduce:
- Activate `stock_barcode` and chose the GS1 nomenclature;
- Create a product and set a valid barcode (right checksum, eg.:
00000000012348);
- In the Barcode App, create a new receipt and scan a GS1 barcode for
this product containing also a quantity and using a custom separator
(`#` can be use aswell by default, eg.: 3008#0100000000012348 for 8x
this product) with using the device camera or by trigger the event
through the console:
odoo.__WOWL_DEBUG__.root.env.services.barcode.bus.trigger(
"barcode_scanned",
{ barcode: "3008#0100000000012348" },
);
-> Issue: the barcode is not recognized.
With this commit, the parser will get the nomenclature's separator and
will use it like before in `gs1_decompose_extanded`.
Also, this commit slightly changes the separator regex (from '\x1D?' to
'(?:\x1D+)?') in case multiple separators follow each other.
OPW-3439905
closesodoo/odoo#138420
X-original-commit: 39ecbf9d93d465533619aa32e127331a0307c3a9
Related: odoo/enterprise#48811
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
Create a new model mixins that allow other model to
activate the history feature on html fields.
This history automatically track the changes
on the related html field and allow the user
to revert to a previous version at any time.
This also introduce a new component that can be used to :
* List the recent history
* See a previous version of the document
* Compare a previous version to the current one
* Revert the document to a previous version of it
task-3039787
closesodoo/odoo#112957
Related: odoo/enterprise#37211
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
In the context of branches, you need to be able to select taxes of
an ancestor company on an invoice/bill, even when you don't have access
to the ancestor company.
In order to do that, we relax the restriction when searching with a
`parent_of` or `child_of` on a related field, so that it also includes
ids of related field records you don't have access to. This should not
be a problem, since in the end the search will return records of a
model restricted by its own access rules.
task-3503204
closesodoo/odoo#138942
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
When a user only has access to a branch and not to the parent, he can
not create a new customer invoice or vendor bill, since we need to check
the lock date on all ancestor companies (where the user might not have
access to).
This fix allows the user to create a new customer invoice or vendor bill
again when only having access to a branch.
Furthermore, in the above case we are also unable to assign a partner on
the invoice/bill, since we are checking properties that might belong to
an ancestor company we don't have access to. We also fixed that here, so
a partner can be selected.
task-3503204
Part-of: odoo/odoo#138942
Ahmad Khanalizadeh