This commit removes the module "web.dom_ready" and
adapts the modules that imported it.
This module was used to wait for the content to be
loaded to manipulate the dom after that.
The goal is to remove async modules and simplify the
module loader in the future.
task id: 3265979
closesodoo/odoo#119158
Related: odoo/enterprise#40051
Signed-off-by: Géry Debongnie <ged@odoo.com>
The employment type and first contract date were made available on the
public employee, however those fields but don't need to be publicly
available.
odoo/upgrade#4539
task-3252610
closesodoo/odoo#118333
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Current behavior:
If you add a sale description to a product, it will not be added to the
invoice created from the PoS.
Steps to reproduce:
- Add a sale description to a product
- Create a PoS order with this product
- Create an invoice from the PoS order
- The sale description is not added to the invoice
opw-3221481
closesodoo/odoo#119516
X-original-commit: 37538c876f30fb1b3a9368f12a16edb1806777f8
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Steps to reproduce the bug:
- Open an empty page (e.g. the home page) in Website edit mode.
- The "DRAG BUILDING BLOCKS HERE" message is missing in the '#wrap'.
Since the commit [1], we have made modifications to the
'%o-editor-messages' mixin, which is used on the '#wrap' element, to
hide the editor message if the element is not the only child. However,
another commit [2] was added afterwards, which introduced a new div
called '#o_shared_blocks' next to the '#wrap' element. As a result, the
'#wrap' element is no longer the only child, and the message is never
displayed again.
To fix this, we took the rule out of the mixin to only use it where we
need to (for '.oe_drop_zone').
[1]: https://github.com/odoo/odoo/commit/6ee778fdbcd92dbefd08c8551ea654d352ad0dc0
[2]: https://github.com/odoo/odoo/commit/6007264afb83dcfed1693d72179cb156ff2254b6
task-3270409
closesodoo/odoo#119621
X-original-commit: d4b7a9e877804cd6bbdc0d15b1ab1c03561a4a86
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, a domain of the form "[(.., .., -1)]" would be
incorrectly represented in the domain selector as .., .., undefined.
The root cause was that py_js view the sub expression -1 as the
application of the operation - to 1 and thus create an AST of type 6 for
it. The domain selector did not expect to get such an AST but did not
crash either. Here we make it extract the intended value from the AST
for -1. More complex expressions like 3-1 are still not supported.
closesodoo/odoo#119620
X-original-commit: f9604da60c6650ad46aafe08e9fad118654a149b
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Before this commit, when loading discuss app with
`active_id=discuss.channel_1` in URL, the discuss app did not
auto-select the conversation.
This happens because the code did not parse model and id part of
"discuss.channel_1": it split into `discuss.chann` and `l_1`,
instead of `discuss.channel` and `1`. This comes from splitting
the same way as legacy `mail.channel`, starts with 13 characters,
although there are now 16 characters in `discuss.channel`.
This commit fixes the issue by simplify the way the active thread
of discuss is deduced from active_id.
closesodoo/odoo#119559
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Enforce strict types for returned values for
* create
* write
* unlink
* default_get
to make those methods more consistent and reliable.
Also make sure they can be called with empty self/values,
i.e. that they follow the same behavior as the base methods
defined in the main orm Model.
closesodoo/odoo#116809
Related: odoo/enterprise#38880
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Clicking on an emoji from the emoji picker while holding down the Shift
key now prevents the emoji picker from closing, allowing users to easily
select multiple emoji in one go.
Task-3288704.
closesodoo/odoo#119598
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
To reproduce on runbot:
- go a to an existing task
- clear the "Analytic account" field
- add a timesheet line
- save
It then crash with the following error:
```
RPC_ERROR
Odoo Server Error
Traceback (most recent call last):
File "/data/build/odoo/odoo/http.py", line 1698, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/data/build/odoo/odoo/service/model.py", line 134, in retrying
result = func()
File "/data/build/odoo/odoo/http.py", line 1725, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/data/build/odoo/odoo/http.py", line 1922, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/data/build/odoo/addons/website/models/ir_http.py", line 234, in _dispatch
response = super()._dispatch(endpoint)
File "/data/build/odoo/odoo/addons/base/models/ir_http.py", line 154, in _dispatch
result = endpoint(**request.params)
File "/data/build/odoo/odoo/http.py", line 715, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/data/build/odoo/addons/web/controllers/dataset.py", line 28, in call_kw
return self._call_kw(model, method, args, kwargs)
File "/data/build/odoo/addons/web/controllers/dataset.py", line 24, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/data/build/odoo/odoo/api.py", line 461, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "/data/build/odoo/odoo/api.py", line 448, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "/data/build/enterprise/industry_fsm_stock/models/project_task.py", line 101, in write
result = super().write(vals)
File "/data/build/enterprise/helpdesk_fsm/models/project_task.py", line 45, in write
res = super().write(vals)
File "/data/build/odoo/addons/project_sms/models/project_task.py", line 25, in write
res = super().write(vals)
File "/data/build/enterprise/project_enterprise/models/project_task.py", line 288, in write
res = super().write(vals)
File "/data/build/odoo/addons/hr_timesheet/models/project.py", line 385, in write
res = super(Task, self).write(values)
File "/data/build/odoo/addons/project/models/project.py", line 2050, in write
result = super().write(vals)
File "/data/build/odoo/addons/mail/models/mail_activity_mixin.py", line 241, in write
return super(MailActivityMixin, self).write(vals)
File "/data/build/odoo/addons/rating/models/rating_mixin.py", line 101, in write
result = super(RatingMixin, self).write(values)
File "/data/build/odoo/addons/mail/models/mail_thread.py", line 311, in write
result = super(MailThread, self).write(values)
File "/data/build/odoo/odoo/models.py", line 3813, in write
field.write(self, value)
File "/data/build/odoo/odoo/fields.py", line 4168, in write
self.write_batch([(records, value)])
File "/data/build/odoo/odoo/fields.py", line 4189, in write_batch
self.write_real(records_commands_list, create)
File "/data/build/odoo/odoo/fields.py", line 4369, in write_real
flush()
File "/data/build/odoo/odoo/fields.py", line 4325, in flush
comodel.create(to_create)
File "<decorator-gen-368>", line 2, in create
File "/data/build/odoo/odoo/api.py", line 410, in _model_create_multi
return create(self, arg)
File "/data/build/odoo/addons/hr_timesheet/models/hr_timesheet.py", line 142, in create
vals_list = self._timesheet_preprocess(vals_list)
File "/data/build/enterprise/helpdesk_timesheet/models/analytic.py", line 61, in _timesheet_preprocess
return super(AccountAnalyticLine, self)._timesheet_preprocess(vals_list)
File "/data/build/odoo/addons/hr_timesheet/models/hr_timesheet.py", line 331, in _timesheet_preprocess
account = account_per_id[account_id]
KeyError: False
The above server error caused the following client error:
null
```
closesodoo/odoo#119597
X-original-commit: b86fa6a72cc5eaeb0245cf2092eefde09226aa12
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This PR complete the type definition for the props of the composer and replace
the custom Object by Ref type in the relevant place.
closesodoo/odoo#119593
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit adds two autoresize hooks for text inputs and textareas to
make it adapt their size (width for text inputs, height for textareas)
depending on their content.
The commit therefore solves the issue of several form view task titles
being restricted to 1 line while it can be annoying if the title is too
long. The autoresizeTextarea feature was moved from TextField to the
autoresizeTextarea hook and the autoresizeInput feature was moved from
the AutoresizeInput mail component to the autoresizeInput hook.
The TextField component has a new option for disabling linebreaks.
task-3138826
closesodoo/odoo#117355
Related: odoo/enterprise#39493
Signed-off-by: Géry Debongnie <ged@odoo.com>
*: l10n_fr_pos_cert,portal_rating,pos_adyen,pos_epson_printer,pos_loyalty,
pos_mercury,pos_restaurant,pos_restaurant_adyen,pos_restaurant_stripe,
pos_sale,pos_six,pos_stripe,web
This is part of the continuous effort of refactoring pos addons towards using
more modern modules and programming patterns (such as services). After this
commit, point_of_sale addons are now left with the use of the legacy
`web.concurrency` module because of the `MutexedDropPrevious`. It's okay to keep
it because it's relatively an independent module compared to other legacy web
module.
The following summarizes the changes in this commit.
- import `_t` from `@web/core/l10n/translation`.
- convert `PosDB` to js native class
- remove use of `format` in `TicketScreen`
- To determine the cached orders are up-to-date, we now deserialize the dates
coming from the server using web's `deserializeDateTime` function. Then,
instead of initiating `cacheDate` as native js Date, we use the luxon's
`DateTime` which is supported by the web date utility methods.
- There is no need for the `format` function from `web.utils` legacy module.
- convert `PaymentInterface` to native class
- remove use of `web.config` module
- remove use of `web.time` module
- use `serializeDateTime` from web.
- remove use of `web.rpc`
- remove use of `web.utils` module
- introduce simple check for email address input
- Replace use of `web.utils.Markup` with `@odoo/owl.markup`.
- 'web.utils'.{round_decimals,round_precision,float_is_zero} copied to
'@web/core/utils/numbers'.{roundDecimals,roundPrecision,floatIsZero}.
- These helper functions are not removed from the web addon because they
are also used from other addons that are not linked to pos.
- `floatIsZero` is now computed by directly comparing the result of
`roundDecimals` to zero. This works because rounding a decimal number
which will result to zero will exactly give zero.
- remove use of `web.field_utils`
- Replace `web.field_utils.parse.float` with
`@web/views/fields/parsers.parseFloat`.
- Replace `web.field_utils.format.float` with
`@web/views/fields/formatters.formatFloat`.
- Replace `web.field_utils.format.date` with
`@web/core/l10n/dates.formatDate`.
- Replace `web.field_utils.format.datetime` with
`@web/core/l10n/dates.formatDateTime`.
- convert `PrinterMixin` and dependents to native class
- `PrinterMixin` is converted to `BasePrinter`.
- `Printer` is converted to `HWPrinter` (extending `BasePrinter`).
- `EpsonPrinter` retained its name and is converted to extend `BasePrinter`.
- Moreover, we also removed the convoluted `PrintResultGenerator`, replaced by
simply creating object with the following signature:
```js
{ successful: boolean; message?: { title: string, body?: string } }
```
- remove use of `web.Session`
- replace use of `qweb.render`
- We use `renderToElement` as replacement to templates that produces valid
html.
- Note that `renderToElement` is introduced in `@web/core/utils/render` module
which is extracted from the original `renderToString` method.
- For the epson printer template, we kept the xml layout and manually add
required xml element to contruct the xml that will be sent to the epson in
making print requests.
- use `Mutex` from `@web/core/utils/concurrency`
- remove use of `Markup` when rendering receipt info (`ticket`) in order to
render new lines.
- Remove use of `jquery` in `htmlToImg`.
closesodoo/odoo#117231
Related: odoo/enterprise#39078
Signed-off-by: Samuel Degueldre <sad@odoo.com>
The said method is no longer present since
45d08db3c4. No need to replace it -- it can just
be removed -- because the customer_display already relies on the reactivity
which automatically recomputes the html when dependencies changed.
Part-of: odoo/odoo#117231
To enable VAT validation (VIES/ simple), the base_vat module needs to be installed.
base_vat extends models where the validation should apply. This means it only works with models in account, unless the module is added as a dependency (base_vat depends on account)
To avoid this dependency (in account reports - see enterprise PR odoo/enterprise#34068), two methods required for VAT validation are added to res.partner so that the enterprise module is able to use this feature with/without base_vat.
closesodoo/odoo#106046
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Before this commit:
The AceField component used the ace library to provide the user a code
editing field
After this commit:
The AceField component is now using the CodeEditor component and the usage
of the ace editor lib is now abstracted behind the component.
closesodoo/odoo#117782
Related: odoo/enterprise#39365
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit:
When using the native ResizeObserver, we might get "ResizeObserver loop
limit exceeded" errors but these can ignore, see [ResizeObserver Errors](https://developer.mozilla.org/en-US/docs/Web/API/ResizeObserver#observation_errors).
This error was wrongly handled and would cause another when running tests
involving the ResizeObserver.
After this commit:
The error is now properly detected and ignored when running tests.
Part-of: odoo/odoo#117782
This component was created as an easy way to add a code editing field
without needing a record (unlike the AceField component). It also
completely abstracts the use of the Ace Editor library.
The CodeEditor has been moved to web core as it was needed in other
places.
The name "CodeEditor" was purposely chosen to clearly state what the
component is used for and abstract the use of Ace.
Part-of: odoo/odoo#117782
Current behaviour:
In the project update section, if the project has only draft
invoices linked to the analytic account of the project, the invoices
smart button isn't present. But once we have at least 1 posted
invoice, the button is shown, and when triggering the action, we see
both the posted invoice and all the draft invoices that were not
shown previously.
Expected behaviour:
The button should be visible, even if the only invoices linked to
the analytic account of the project are only in draft.
Steps to reproduce:
- Install Project, Sales, Accounting
- Activate Analytic Accounting in the Settings
- Create a Project and make sure it has an analytic account linked to it
- Create a new invoice in draft, make sure on the line you have set
the analytic account of the project we just created. Save.
- Go to the project update page, there is no smart button that will
go to the invoice we just created.
Reason for the problem:
The Invoices smart button is shown only when the `invoice_count` is > 0.
`invoice_count` is a related field to the same field name of the
analytic account, which is a compute. In that compute we explicitly
only take invoices that are posted, since in the context of an
analytic account, it only makes sense to take actually posted
invoices, since those are real revenues. So the button is shown only
when we have at least 1 posted invoice. The action itself is just
fetching all the `in_invoice, out_refund` invoices that are linked to
this analytic account.
Fix:
Transform the `invoice_count` in `sale_project` module from a
related to a regular compute and do a query with the same heuristics
for the action of the invoice smart button.
Affected versions:
- 16.0
- saas-16.1
- saas-16.2
- master
opw-3227421
closesodoo/odoo#119578
X-original-commit: 1b45e22530cb07ca437d2fd53bda3af2c918c223
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit put the same field description between 'sale.order.template.line'
and "sale.order.line"
closesodoo/odoo#119576
X-original-commit: 811cf78ee1e63a7c41efe578fb64ee2deeca1dde
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
With the refactoring of the mail API, use the new
`message_post_with_source()` to ensure the message content is visible
in the chatter
To reproduce:
- Create a quotation template with a confirmation email
- Create and confirm a sale order using that quotation template
=> We expect that confirmation email (content) to be visible in the
chatter, currently the email (mail.mail) is ok but the message
(mail.message) has no body which make it not/partially visible in the
chatter.
closesodoo/odoo#119566
X-original-commit: 6b3d74cde697ea655d5101d9ea426dc814ce2fa1
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
With commit (1), the clear button is only displayed when a selected
value is found from the available choices. But since we used
shallowEqual to find the corresponding choice, we couldn't use objects
containing objects in its values, since a simple comparison was made
in the utility function. This was a wrong usage of the SelectMenu and
we don't want to support objects and arrays as values. The value
attribute should only be a string, and it's the parent responsability
to handle any object related to this string.
The test using an object and an array as values has been removed since
it had no purpose after the removal of this partial and wrong support.
With this fix, an assertion for the presence of the clear button has
been added instead for the import action.
(1): d760b81271closesodoo/odoo#119298
Related: odoo/enterprise#40177
Signed-off-by: Géry Debongnie <ged@odoo.com>
This commit fixes the property field tag components and sub-components by
ensuring that the ".bind" function of the component always receives a function.
As the "checkDefinitionWriteAccess" prop is optional, it could crash because
OWL would try to call ".bind" on an undefined function.
The new code will pass an empty function instead as a fallback.
(When it's not passed, it's never called, as it is in a display context and we
do not create tags, e.g: when showing the tags in a kanban view).
Task-3280847
closesodoo/odoo#119565
X-original-commit: 7d52600263bfd911156a2d94041fc522e2baff8a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Steps to reproduce:
- Open any listview (e.g Sales order listview)
- select records from the listview, go to Favorites, and click on 'Insert list in spreadsheet' option
- Once the spreadsheet is created, Reload your browser.
Current behavior:
- Spreadsheet goes to an infinite loading.
opw-3284058
closesodoo/odoo#119561
X-original-commit: 6993d3e36d2f2540100e1bd248b629cc9e191659
Related: odoo/enterprise#40234
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Before this PR, the filter on account root was present 2 times in the journal
items views. By removing one of the two, the problem is solved.
opw-3275279
closesodoo/odoo#119544
X-original-commit: bffa837a3b11144a53300e93249767ce4e9374d2
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
Steps to reproduce:
- create a time off type;
- select 'Extra Days Requests Allowed' for 'Employee Requests';
- select 'Approved by Time Off Officer' for Approval;
- choose a Responsible Time Off Officer;
- change the select for 'Employee Requests' and select 'Not Allowed';
- create an allocation for an employee with this type.
Issue:
The allocation is blocked at step 'TO APPROVE'.
Cause:
Even if we choose `no` for `employee_requests`,
the `allocation_validation_type` always contains `officer`.
Solution:
We have to test the `employee_requests` field during the
validation action
opw-3264758
closesodoo/odoo#119542
X-original-commit: a270267c34d42bba79190422143673f585e554d7
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Before this commit, the bus service was starting worker at page
load, regardless on whether the user interacts with chat features.
This commit starts bus worker only when it's really useful, e.g.
when adding a new channel to subscribe. Functionally, on livechat,
the worker does not start before the livechat is open.
Task-3266973
closesodoo/odoo#119528
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
this commit removes unnecessary modal that does not let users create
a new users from apps like crm, sale, etc. Now instead of giving requests
that lack email redirectWarning, we open user creation form where user must
set email up.
Reason behind this change is the fact that login is required at the model level,
so the manual checks for this value is not necessary anymore.
task-3262468
closesodoo/odoo#119508
X-original-commit: 7796e8ca971167a96b23baa4b57056c2007ea8b4
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit:
After selecting the text of shift+enter which is styled and pressing any key
the new hideous child gets born.
After this commit:
Now, The new input will replace the selected text.
Task-3209969
closesodoo/odoo#119506
X-original-commit: f15d5ad27c6b764f54904f6ea8f6a714974b7bd0
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When your pricelist item price is based on an other prcicelist in
another currency, the wrong currency is given to the function
_get_product_price. we sould give the currency of the base_pricelist
instead of the target one.
Here is a example:
We have a priclist in INR based on a pricelist in USD. And the company
currency is euro.
When we go for the first time in '_compute_base_price', where we'll call
_get_product_price to get the price from the base pricelist (the $ one)
We get as src_currency the USD and target the INR. Since we are calling
_get_product_price with INR as currency, when _get_product_price will
call _compute_base_price, we'll get EUR as src_currency and INR as
target.
This will lead to apply on the EU price (the one on the product) the
rate of EUR->INR then apply over it USD -> INR. Instead of EUR -> USD
and then USD -> INR
closesodoo/odoo#119505
X-original-commit: 8ace9942368688dc1183133f451ea788a03e0f14
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Masereel Pierre <pim@odoo.com>
The goal of this commit is to fix the race condition introduced by
[this commit]. Here were the problematic steps:
- Open the mega menu.
- When then mega menu is opened, scroll up.
- Open the mega menu after scroll.
Before this commit, what could happened was that the mega menu did not
have enough time to be closed after the scroll. Clicking on it would
then actually close it rather than open it as wanted. This commit adds
a step to ensure that the mega menu is closed before open it.
[this commit]: https://github.com/odoo/odoo/commit/9b1de9e28697edbb6e1fa88665294f983f60e37f
runbot-20660
closesodoo/odoo#119438
X-original-commit: abd0038de73a057eb9c34dc8d316b67d96fac409
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
# Steps to reproduce
- install l10n_mx_reports
- switch to a mexican company
- create a Vendor Bill, confirm it and register a payment for it
- create a Credit Note for that bill, confirm it and register a payment
too
- go to the DIOT report (called `Transactions with third parties
[ DIOT ]` in the menu )
The amount in the column "Refunds" should be the tax amount, and not the
base amount.
opw-3107102
Enterprise PR: odoo/enterprise#39628closesodoo/odoo#118887
X-original-commit: 8c9cde34ac1fb74a42997b0a1d847ae1c9bb1312
Related: odoo/enterprise#39929
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
This commit adds YTD (year to date) filter to global period filters in
dashboard.
YTD filter gets the data from Jan 1st of the current year to
today (included). The unit of its offset is year.
task 3215947
closesodoo/odoo#118466
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Activate Multicurrency (USD company curr, EUR foreign currency, 1 EUR = 2 USD)
Have a Bank account in both currencies.
Create an expense of 100€, paid by company
Create report, set EUR journal as Bank Journal
Send To manager > Approve > Post Journal Entries
Open created payment
Issue:
- Payment amount is 200€
- In journal items, amount_currency and balance is 200$
Do the same with "Paid by employee".
Open the vendor bill
Issue:
- Invoice lines are expressed in the wrong currency
opw-3269009
closesodoo/odoo#119490
X-original-commit: 5eab4469d87a4d1ca80916ca5790691ffed68e38
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Missing `nextTick` for this `tap` (compared to other similar calls).
closesodoo/odoo#119479
X-original-commit: 7ff8c563edf1b32ecf8222399637c294b5f58e9d
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Reproduction:
1. Install Project, Helpdesk, go to Project -> Configuration -> Activity
Types-> Upload Documents
2. Type a super long text in Default Note, the text overlaps the EN
button
Reproduction 2:
1. Go to Helpdesk -> configuration -> Helpdesk Teams -> Customer Care
2. Type a super long text in the description of the team, the text
overlaps the EN button
Fix: we set concrete padding to the right to make sure the translation
button is not overlapped. The fix needs to be done in enterprise too
Note: The reproduction 2 is another sub-issue found when fixing the
first one. Reproduction 1 is for the note field with oe-bordered-editor,
and reproduction 2 is for the note field without it.
Related Previous Commit:
Odoo:
https://github.com/odoo-dev/odoo/commit/26ecbc16bc8079c7bb08095f1b27b4f68ca0e947
Enterprise:
https://github.com/odoo-dev/enterprise/commit/e2ca9d5a113bc3adbe085057eff778b24abf5ddc
task-3047773
closesodoo/odoo#119475
X-original-commit: ac5e9681b47787aafeab1a1a3f748801821d66c8
Related: odoo/enterprise#40170
Signed-off-by: Liu Jinjiu (jili) <jili@odoo.com>
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
On a model X, where there is a field related x_related
(related= 'y_id.y_translate') towards a translate field y_translate
on Model Y.
When you unlink at least 1001 records of X
(r1, r2, ... , r1000, r1001) (cr.MAX_IN + 1), you get a traceback
(`RecursionError: maximum recursion depth exceeded in comparison`).
The stack looks like:
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3609, in unlink
self.env.flush_all()
File "/home/odoo/Documents/dev/odoo/odoo/api.py", line 732, in flush_all
self._recompute_all()
File "/home/odoo/Documents/dev/odoo/odoo/api.py", line 728, in _recompute_all
self[field.model_name]._recompute_field(field)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 6179, in _recompute_field
field.recompute(records)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1348, in recompute
self.compute_value(record)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1368, in compute_value
records._compute_field_value(self)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 4209, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 100, in determine
return needle(records, *args)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 689, in _compute_related
values = [first(value[name]) for value in values]
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 689, in <listcomp>
values = [first(value[name]) for value in values]
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 5874, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 2771, in __get__
return super().__get__(records, owner)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1186, in __get__
recs._fetch_field(self)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3162, in _fetch_field
self._read(fnames)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3214, in _read
self.flush_recordset(translated_field_names)
...
-> Extra info:
translated_field_names = ['x_related']
`self = X(r1001, r1, r2, ..., r999)`
...
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 5585, in flush_recordset
self._recompute_recordset(fnames)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 6162, in _recompute_recordset
self._recompute_field(field, self._ids)
...
-> Long recursion starts here but first records to be recomputed will be r1, then r2, then r3, ...
But the maximum recursion depth error will be triggered earlier at the
end of the recursion, because the stack limit in Python is 1000
by default.
...
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 6179, in _recompute_field
field.recompute(records)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1348, in recompute
self.compute_value(record)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1368, in compute_value
records._compute_field_value(self)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 4209, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 100, in determine
return needle(records, *args)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 689, in _compute_related
values = [first(value[name]) for value in values]
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 689, in <listcomp>
values = [first(value[name]) for value in values]
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 5874, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 2771, in __get__
return super().__get__(records, owner)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1186, in __get__
recs._fetch_field(self)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3162, in _fetch_field
self._read(fnames)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3214, in _read
self.flush_recordset(translated_field_names)
...
------ Extra info:
translated_field_names = ['x_related']
`self = X(r1, r2, ... , r999)`
...
Since 9c3b9a4926, the `x_related` is
flagged to be recomputed at the end of the delete
loop of `unlink`, but it shouldn't be, because records are deleted now.
The problem is in these lines:
```python
with self.env.protecting(self._fields.values(), records):
self.modified(self._fields, before=True)
```
The `records` are only a part of `self` (batch of 1000), so the
`protecting` call only protects the current batch and not `self`.
Then, the second batch (here with only one record), will flag to recompute
`x_related` of the first batch records. Then, later on, the `flush_all`
will generate the recursion error trying to resolve
these `to_recompute`.
To fix it, only move the modified call (+ protecting) before
the batch loop and executes it on `self`.
This issue shouldn't exist in master, because having a
related translate field triggers a warning (`Translated stored related
field (<field_name>) will not be computed correctly in all languages`).
Also `https://github.com/odoo/odoo/pull/100472` fixes the issue in
master, but it generates one SQL request by record, which isn't great.
Then in master, we should forward this commit (but test will be remove
because it generates the warning message).
closesodoo/odoo#119471
X-original-commit: 78450cae5900e267de439e4988b314aa644e76bd
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Rémy Voet <ryv@odoo.com>
The `read_group` of `calendar.event` sends a danger notification when
the user groups by any field in the list view. It is because the
security reenforcement done in 2c0b3ab670168a155b3974d5a5b39aa1f1df3452
is too strict. It checks all `fields`, even the ones that are filtered
out by the `read_group` (`fields` without aggregation specification
nor `group_operator`).
closesodoo/odoo#119459
Signed-off-by: Raphael Collet <rco@odoo.com>
Before 916c9c46f58f27c68c5558a2a57fdca43a89fe89, we could
groupby several times on the same relational field with `read_group`
Example: `read_group(..., groupby=['product_id', 'product_id'], ...)`.
Now, it produces a traceback:
File "/data/build/odoo/odoo/models.py", line 2583, in read_group
self._read_group_format_result(rows_dict, lazy_groupby)
File "/data/build/odoo/odoo/models.py", line 2396, in _read_group_format_result
ids = [row[group].id for row in rows_dict if row[group]]
File "/data/build/odoo/odoo/models.py", line 2396, in <listcomp>
ids = [row[group].id for row in rows_dict if row[group]]
AttributeError: 'tuple' object has no attribute 'id'
It is because `_read_group_format_result` try to convert the record
into tuple (id, display_name) twice (one for each groupby).
Fix this issue introduced by the refactor of `_read_group`.
Part-of: odoo/odoo#119459
Since Bootstrap was updagraded to 5.1.3, `ev.clickEvent` is no longer a
`JQuery.Event`. Therefore, the `originalEvent` property does not exist
anymore, and `__isColorpickerClick` can be accessed directly from
`ev.ClickEvent`.
By checking for the non-existent `originalEvent` property, the mechanism
that enables the colorpicker to remain open when clicked was being hindered.
Note that this handler's `ev` remains a `JQuery.Event`, and if a handler
returns `false`, it will prevent the default action and stop the event
propagating.
task-3274987
closesodoo/odoo#119429
X-original-commit: 6db128f7f859d7bb0f96b15b4e6a38955932f7cf
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
There was two issues regarding the slides public views counter
1. If the `public_views` is set to `NULL` in database,
`increment_fields_skiplock` wasn't properly incrementing the count.
Indeed, in SQL, doing NULL + 1 returns NULL
```sql
16.0=# SELECT NULL + 1;
?column?
----------
(1 row)
```
To have the result we expect, COALESCE must be used
```sql
16.0=# SELECT COALESCE(NULL, 0) + 1;
?column?
----------
1
(1 row)
```
2. There is a mechanism, using the session,
supposed to prevent incrementing the public views
counter when a same user visits multiple times the same slide.
However, since 84d17e57e8
the visited slide was never actually added in the session,
because it was adding the slide id in a copy of the set
in session rather than adding in the set from the session.
Or, as this commit does, to re-assign the new set in the session.
closesodoo/odoo#119370
X-original-commit: fa5962d6f08979017842985004b3ec43416ee181
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
It is only used there.
In preparation of splitting discuss and mail modules.
Part of task-3265211
closesodoo/odoo#119306
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, when hovering the shopping cart in the "Boxed" and
"Centered Logo" header templates, the cart popover was not appearing.
This happened because the `websiteSaleCartLink` public widget was never
started with these templates and so, hovering the cart had no effect.
This is due to this widget selector which targeted a cart link located
inside an element with id `#top_menu`, which is not the case in these
templates where the cart link is located outside of it.
This commit fixes this widget selector, in order for the cart link to be
reachable in all header templates.
opw-3267114
closesodoo/odoo#119277
X-original-commit: ecefa679b224ce0e4a5a7e91ce28936321132d9c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This module allows to add secret key to add the turnstile captcha on
each snippet website_form.
Cloudflare Turnstile
--------------------
A friendly, free CAPTCHA replacement
Turnstile delivers frustration-free, CAPTCHA-free web experiences to
website visitors.
Turnstile stops abuse and confirms visitors are real without the data
privacy concerns or awful UX that CAPTCHAs thrust on users.
closesodoo/odoo#119246
X-original-commit: 4aca39a533e9d41f5f452f36a1ffc001f586b4f4
Signed-off-by: Jérémy Kersten <jke@odoo.com>
This commit makes sure that fields without widget
in kanban are properly formatted using the rawAttrs.
Steps to reproduce: create a float kanban field without
widget, set the digits to anything other than default and
see if the digits attrs are applied to the field.
opw-3263583
closesodoo/odoo#119161
X-original-commit: 1e635154654efcea59fe1f8bae679fb6bac41809
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
__Current behavior before PR:__
The size of an image field is guessed using the field name. For instance, an image field with `field_name = "XXXX_123"` is resized to 123 pixels when fetched.
This is can be an issue if a user creates an image field using studio in a form view.
If the user sets the label of the field as "Image 1", the technical name will become `x_studio_image_1`. Therefore, the image field will be resized to 1 pixel width.
__Description of the fix:__
Refactor the `image_guess_size_from_field_name` method to return `(0, 0)` when the field name starts with `x_studio_`.
__Steps to reproduce the issue:__
1. Open a form view (of any model)
2. Open studio
3. Add an image field with label "Image 1" (notice the technical name becomes in `x_studio_image_1` in debug mode)
4. Close studio
5. Upload an image on the created field
6. Save... The image is resized to 1 pixel width
opw-3242084
opw-3249632
opw-3253133
closesodoo/odoo#118960
X-original-commit: 3318f0e67da40983f52595aba933d8c8fd0f5cc5
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Michael (mcm)