The `_search` is override in `calendar.event` to return both ids and
virtual ids of recurrent events. Calling `.get_recurrent_ids` after the
search is wrong.
The entire request has been copied from the original
`_find_allowed_model_wise` function defined in `mail.message` to ensure
his correctness.
The purpose here is to ensure every virtual event id is mapped to the
real event id so the original function doesn't throw KeyErrors for
virtual ids.
opw-1972563
closesodoo/odoo#33246
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
- Install the 'Maintenance' app
- Create a maintenance request, set a day and a duration of 6 hours
- Go the calendar view, month mode
- Move the maintenance request from one day to another
The duration is changed with a non-sense value.
In month mode, the hours are not represented in the calendar so it is
not possible to compute the `date_delay`. Moreover, when a record is
moved from one date to another (`_onDropRecord`) in month mode, there is
actually no point recomputing the duration; the `date_start` is enough.
Note that `date_delay` is used (at the time of writing) in 2 views and
absolutely not tested.
opw-1984637
closesodoo/odoo#33193
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Have sections order lines on each Sale Order
Have multiple Sale Orders on which the action "invoice order" is triggered
(to make one invoice for all of them)
Before this commit, the real invoice lines were not under their respective
section line
This was because we kept the sequence of the order line when making the order line
which makes little sense in a case where we merge the orders
After this commit, the invoice lines are under their respective section
OPW 1985080
closesodoo/odoo#33219
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The email_compose_message_wizard_form takes a default_composition_mode.
If it is 'mass_mail', the used mail template is not rendered.
Since this is basically unreadable for a normal user, this can be confusing.
Note that this is even the case if the mail is being sent on only one record.
We use the 'comment' composition mode if there is only one target record so that
the template is rendered in that case.
opw 1984381
closesodoo/odoo#33173
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Make a CRM lead, assign it to a portal user
Have an automated action which add followers on create and write
From the portal, edit the lead
Before this commit, it crashed because a portal user doesn't have access to ir.model
(4a18d5744e)
After this commit, the flow works, because we use the stored model name on the action
instead of trying to read ir.model
OPW 1985570
closesodoo/odoo#33211
Signed-off-by: Christophe Simonis <chs@odoo.com>
Steps to reproduce the bug:
- Create a project called "R&D"
- Create two service products P1 and P2 with 'Timesheets on tasks' and
'Create a task in an existing project' for project 'R&D'
- Create a SO1 with 5 P1 and SO2 with 10 P2 and confirm SO1 and SO2
- Deliver 1 hour for P1 and 2 hours for P2 (with timesheets)
- Click on "Project Overview" button
Bug:
The remaining hours for SO1 was 12 hours instead of 4 hours and the remaining hours
for SO2 was 12 hours instead of 8 hours
opw:1981903
closesodoo/odoo#33183
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Following f4fbaf1efa
which changes the label/checkbox structure into:
```
<div class="custom-control custom-checkbox">
<input type="checkbox" class="custom-control-input" id="customCheck1">
<label class="custom-control-label" for="customCheck1">...</label>
</div>
```
So, before this commit, there may have been multiple input with the same Id.
The consequence is that, when clicking on a label, the browser would take the first Id it found
which was erroneous, because all checkboxes in Favorites menu had the same Id
In reality, the use case goes as:
- open a x2m,
- search more
- Favorites > Save current search
> click on one the two checkboxes
> The dropdown closed, without checking the box
After this commit, when clicking on the checkbox in the favorites menu
the checkbox is toggled and the dropdown stays. Also, the checkboxed have now unique ids
OPW 1974587
closesodoo/odoo#33032
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This reverts commit 9c4b52000f.
The fix of opw-1974599 is wrong. As the fix was fixing a corner case, it
is better to revert this one as it is breaking all recurrent events.
opw-1985498
opw-1985552
closesodoo/odoo#33206
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
* order of parameters to translator swapped
* context['meta'] always set, defaulting to None if the document has no
metadata
* [3.0 prep] modifying script_files deprecated, use add_javascript /
add_js_file
* remove deprecated call to l_ (which was useless anyway as the documentation
is not translated)
Fixes#33107closesodoo/odoo#33187
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The status link was duplicated, making it skipped during rendering
Use correct indent
closesodoo/odoo#32843
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Currenly in the digest when you send the template, tips are not being seen.
The reason for this is, we are getting tips from the context but we dont have it in the context.
Instead, we are fetching the tips by calling the compute_tips method and assigning it to 'tips'.
Hence, this commit will remove the usage of context to get the tips as we are getting it
from the method and not from the context.
Task ID: #1918364closesodoo/odoo#33186
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This rev. disables Popper.js 3d transformation for positioning
bootstrap dropdowns in navbar, as this transformation causes a
rendering issue on webkit-based browsers (the text in the dropdown
is blurry).
See https://github.com/twbs/bootstrap/issues/23590
Note that it has already been disabled for the other menu dropdowns
(user menu, debug menu) by rev. 5373db1.
Another solution would have been to override the default value in
our bootstrap.js extension file, but for dropdowns that aren't in
the navbar, the dynamic positionning could be interesting.
Fixes#33096closesodoo/odoo#33174
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Configure google to be synchronized with Odoo, create a contact with a
wrong email address (I used `foo@.test.`), create an event in the
calendar, add the contact as attendee, sync with google. Traceback.
The traceback is a `request.exception.HTTPError` reraise by
`_do_request` in the `google.service` model on several HTTP errors, 400
amoung them. The real error is "Invalid attendee email." but the
information is lost in the error message.
The error hanlding has been rethink so it raise a user friendly error
via the UserError modal with just the error message sent by the Google
API. The logged error has been rethink to pretty print both the request
and the response.
opw-1974295
closesodoo/odoo#33058
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Arabic customers are complaining the Lato font is very odd looking for
Arabic scripts. Furthermore, since #32312 Noto is used as the prefered
font to display arabic scripts.
The classes are used by the "Company Tagline" configured along with the
template in use in the general settings.
opw-1946109
closesodoo/odoo#33141
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Open a record having a chatter, edit a field, add an attachment, leave
the page. The discard warning popup in not shown.
When an attachment is added, it reloads the record to fetch the new
`attachment_message_count`. Reloading the view was discarding the
changes because the `keepChanges` option was not set and defaults to
`false`. The changes were discarded thus the internal `_isDirty` flag
evaluated to `false` thus the popup was not shown as nothing would have
been saved.
The option was set in another `attachment_message_count` reload already,
in `chatter.js@_openComposer`.
opw-1974147
closesodoo/odoo#33180
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Some distributions still bundle chardet 2.3, which have some guessing
divergences / incompatibilities with python (resolved in 3.x):
1. UTF-{16,32} with BOM is guessed as LE/BE, which when used to decode
the string doesn't strip out the BOM. Handle this by checking if
the BOM is present and converting the encoding name to the
non-marked version in that case.
2. The ISO-8859-1 test string is guessed as ISO-8859-2 (TBF the
decoding does make some sense). Allow multiple targets/guesses to
"fix" that.
closesodoo/odoo#33179
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The follower button had a useless fixed width which made it overlap with
other buttons.
Fixesodoo/odoo#29387Closesodoo/odoo#33063
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Because of d5d93474de,
when displaying a quote on the portal, which quote has a product with a website description
containing a long h3
the left sidebar took all the space
After this commit, we limit the width of the anchor to the description in the sidebar
OPW 1974650
closesodoo/odoo#33056
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Because of 5fd19cc
when invoicing an order having a product with no tax
the onchange of invoice line put some default taxes on it
After this commit, the taxes we consider are the one coming from
the order line itself
OPW 1981326
closesodoo/odoo#33059
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
In 6c2b54ff there was an optimization that removed extended addresses
fields syncing on parent_id, or concerning field update or creation.
But the list of fields was also used partly for formatting address which
had been supporting extended addresses fields and now does not.
With this changeset, we have the extended fields back but only for
formatting in a new "_formatting_address_fields".
opw-1984608
closes#33144
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
It's quite common that the `$().text()` method returns lots of random whitespaces at the beginning and end of the string. They're pretty unpredictable (extension views can add or remove them) and invisible to the end user.
This code chunk should allow to select an `<option>` based on its raw text content, but most of them will just fail without this patch. And most chances are that current ones just work equally with this patch.
This will make frontend tours more pleasant to write.
closesodoo/odoo#32718
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The check on the ordered quantity should not apply to services.
opw-1981332
closesodoo/odoo#33138
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The UTM graph data in Website > Dasboard > Analytics is not getting
properly filtered on the basis of values of date_from and date_to on
website_sale dashboard.
The field confirmation date which is of type datetime while date_from
and date_to are of date string in local browser timezone.
Hence date_domain is not perfect as shown below on local date 29th april
2019, we would send:
('confirmation_date', '>=', '2019-04-22'),
('confirmation_date', '<=', '2019-04-29')
But in reality we could want a from midnight of week before the current
UTC day, and to current UTC now or 23:59:59 of current UTC day.
This way, the data sent back matches more what is expected, instead of
the preceding domain, we would then have the following:
- if UTC now corresponding to local now is on '2019-04-29'
('confirmation_date', '>=', '2019-04-22 00:00:00'),
('confirmation_date', '<=', '2019-04-29 23:59:59')
- if UTC now corresponding to local now is on '2019-04-28':
('confirmation_date', '>=', '2019-04-21 00:00:00'),
('confirmation_date', '<=', '2019-04-28 23:59:59')
- if UTC now corresponding to local now is on '2019-04-30':
('confirmation_date', '>=', '2019-04-23 00:00:00'),
('confirmation_date', '<=', '2019-04-30 23:59:59')
And each one will be displayed as days 22 up to 29 in line chart (with
local today 29 being the last day of the chart and contening orders of
the current UTC day).
With these change in the UTM pie chart:
- a local date that is before a UTC date => we see the sales from up to
today UTC instead of from up to before yesterday UTC
- a local date that is the same as an UTC date => we see the sale from
up to today UTC instead of yesterday UTC
And in the line chart (that already had half of the fix in f6fc7c2319):
- a local date that is before a UTC date => we see the sales from up to
today UTC instead of from up to yesterday UTC
- a local date that is after a UTC date => we see the sales of current
UTC day + range of days (eg. for a week 7) instead of current UTC day +
range of days minus 1 (eg. for a week 6).
opw-1971539
closes#33041
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Nicolas Lempereur <nle-odoo@users.noreply.github.com>
Having 4 products and 3 BoMs:
BoM 1:
product = Finished
quantity = 100 units
- Semi-Finished 10 units
BoM 2:
product = Semi-Finished
quantity = 10 units
- Assembly 10 units
BoM 3:
product = Assembly
quantity = 10 units
- Raw Material 10 units (product.product 5$/unit)
Before this commit, the price for 100 units of Finished product was
500$, which is wrong. The price was calculated using 100 units of
Semi-Finished product and not 10 units as it should be.
Now, the price is 50$
opw-1973347
closesodoo/odoo#33115
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Use task-#xxx is wrong since it will refer to an unexising or wrong hash
of github.
closesodoo/odoo#33121
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The action_subtask method adds 'default_parent_id' to the context.
If the creation or edition of a subtasks triggers an email creation,
(e.g. if there is an automated action 'send email')
the default 'default_parent_id' is still in the context.
Therefore, it tries to create the email with an arbitrary foreign key
(since it is an existing record on the project.task model), or crashes.
Similar to 816f3861.
opw 1978498
closesodoo/odoo#33111
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Commit 42530b02fe was fixing a bug in reports that were using the standard
bootstrap fonts instead of the changes we made in $font-family-sans-serif
To solve this, 42530b02fe replicated the change in the file
web_editor/static/src/scss/bootstrap_overridden.scss
which is imported in report_assets_common **before** web._assets_bootstrap
This was solving the issue for the report but had also the side-effect of
changing body font-family in enterprise as the bootstrap_overridden.scss file
is also used in web_editor._assets_backend_helpers and
web_editor._assets_frontend_helpers
42530b02fe had effect only on enterprise where the desired font is Roboto/Noto
Create a new bootstrap_overridden (6th of the name) file only for report
closesodoo/odoo#32902
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In the tree view for account.invoice, two columns are signed
(amount_total and residual) and two columns are not signed
(amount_untaxed and amount_tax).
Now, all the columns with numeric values are signed.
This commit reverts the commit : 622af0b7cc
opw-1964348
closesodoo/odoo#33097
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create 3 products:
C1, no tracking
P1, tracked by lot
P2, tracked by lot
- Create a BOM: to product 1 unit of P1, use 1 unit of C1. It also
produces 1 unit of P2 as byproduct.
- On the Stock location, create a Put Away Strategy to send:
P1 to Shelf 1
P2 to Shelf 2
- Create a MO, validate until then end
P1 is correctly sent to Shelf 1, but P2 is sent to Stock instead of
Shelf 2.
No call is performed to `get_putaway_strategy` at move line creation.
opw-1972130
closesodoo/odoo#33109
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Allow the cancellation of invoices 'In Payment', since there is no good
reason to not be able to do it.
opw-1981682
closesodoo/odoo#33093
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Open a record with a chatter (ie an opw task), add an attachment, enable
debug mode and click on "Set Defaults" in the debug tools, traceback.
The `message_attachment_count` field is a special view added by the
chatter on the form view. This field exists on the view but is absent on
the list of field listed by the XML file. Setting a default value on
that special field is not supported.
opw-1972372
closesodoo/odoo#33044
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When a sale order is free, no transaction are created but you are
redirected to the page '/shop/confirmation' that display a transaction
and lead to bad displaying because there are no transaction.
To fix this behaviour, we redirect to the portal view of this sale order.
We've also added the 'href=#' on the button link to have it written in
white.
closesodoo/odoo#33019
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Steps to reproduce:
- Create a product as user for Company A.
- Set a tax on it for Company A.
- As a user in company B, set a default tax for the account associated with the product and/or company.
- As a multicompany user of Company A and B, in company B, create an invoice with the product.
When the onchange is triggered - no tax.
https://github.com/odoo/odoo/blob/11c950ef23faefb5b826c7fb6eb0dccb8e345ca0/addons/account/models/account_invoice.py#L1644-L1654
Its because first we evaluate product taxes for all companies, if none then the account, if none again then the company.
Then they are filtered by company, but in reality the only taxes that need filtering are product taxes (as account
taxes and company taxes should already belong)
fixes#27696
opw:1963881
closesodoo/odoo#33013
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- Activate Invoice Online Payment
- Set Authorize to pay through Odoo (S2S)
- Create a new customer (do not give portal access)
- Create invoice -> send to them
- Open invoice in incognito mode
- Try to pay invoice online with Authorize
An error is raised:
The transaction cannot be processed because some contact details are
missing or invalid: City, Country. Please sign in to complete your
profile.If you don't have any account, please ask your salesperson to
update your profile.
The error is quite confusing, and the user is missing the main point: he
needs to sign in.
There is no reason to display the fact that contact details are missing
for a public user, so this part is now shown only if the user is logged
in.
opw-1981003
closesodoo/odoo#33116
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Open the bank reconciliation widget
- Throttle the connection
- Click multiple times on the same move line in order to select it
The line is added multiple times to the statement line.
We mitigate the behavior thanks to a `debounce`.
Fixes#33000
opw-1978551
closesodoo/odoo#33020
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, the date_last_stage_update field in fill everytime at task creation. This does not make sense if ther is no project linked to the task or if there is no stages associated to the project/task.
This commit populates the date_last_stage_update field only when needed. So, we can now have newly created task without date_last_stage_update filled.
closesodoo/odoo#31999
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
On write, a check is done that raises
'You can not modify already invoiced timesheets …'.
We put that check in a function so that this behaviour can be extended.
(restricted by an override, or relaxed by not calling the super)
opw 1974968
closes#33057closesodoo/odoo#33092
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Steps to reproduce the bug:
- Configured bank account for CHF with all the ISR related informations
- Click on "Send & Print" on a customer invoice with that bank account
- Save the email template
Bug:
An error was raised because the key 'attachments' didn't exist in the variable
rslt.
opw:1970005
closesodoo/odoo#33042
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Create a model and extend this model using an inherits. Define a
constraint in the inherited model that uses a field of the parent model.
Create a valid element using the inherited model then write an invalid
value. This pass the constraint although it should raise an exception.
The problem resides in the `write` function of `models.py`. It first
write values on the inherited model then write values on the parent
model. The order is wrong, it should write on the parent model first
then on the child model.
The solution is to change the order fields are written: first we update
child references to their parents, then we update the parents, then we
update the child.
opw-1962705
closes#32919closesodoo/odoo#33003
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Julien Castiaux