The /web/webclient/translations route's `lang` argument has had some
changes in the last year:
- before june 2020 (a9a756cf): very often it was set to null
- after june 2020 (a9a756cf): it was more often correctly set or had
en_US as fallback so never null
- after 31 march 2021 (8cc06617) in saas-14.3: lang is not sent to
server if it is null (which should never happen)
- after 15 april 2021 (a93a0a3): en_US fallback is removed to prevent
overriding server language if another language is better
But the fix in 31 march and 15 april are not compatible because the
route /web/webclient/translations require a lang argument.
With this changeset, lang argument is always sent to the server.
closesodoo/odoo#69487
X-original-commit: 0604dce996882fb93cd71885f7eb4d0749eb357f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This commit slightly reworks the "event_track_template_new" template to format
it a little better and get rid of unnecessary blank sections.
The "subject" param was removed from the "message_post_with_view" call as we
don't want the chatter to contain the name of the track twice.
Indeed, since #61570, the "subject" is displayed in the chatter if it differs
from the thread name (which is the case here).
This causes a small regression for emails that will state "Re: EventName" in
their subject instead of the track name, but it's deemed acceptable to have a
nicer chatter message.
We also remove the description of the "mt_event_track" mail.message.subtype as
it's only used with a custom template and is redundant with that template's
content.
Task-2496444
closesodoo/odoo#68864
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, There would be Expected singleton error
on changing Credit/Debit for multile account in single call.
Now, We are proocess one record to set `_set_opening_debit_credit`
closesodoo/odoo#69474
X-original-commit: 8fe9f552ed4591795b449f4d1e32e1563ce43ca2
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, the currency_id field has the same compute method
than the price_unit field in the employee mapping. When the
industry_fsm_sale module is installed, the price_unit is recomputed
because of the currency_id and then the user cannot manually edit the
price_unit in fsm project form view.
This commit adds a compute for the currency_id field to not
unnecessarily recompute the price unit in the employee mapping.
Related PR: odoo/odoo#66181closesodoo/odoo#69458
Related: odoo/enterprise#17770
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Before this commit, the top position of a modal in website was always
the height of the main menu navbar. Even if the main menu navbar was
not displayed when the user is not logged.
That bug was introduced in 6ef622772f
After this commit, the top position of a modal is the height of the
main menu navbar but only if that navbar is displayed.
task-2507949
closesodoo/odoo#69391
X-original-commit: 00ab01d05b3876c5d926e16b9a5d65ace4df7360
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
On initialization, the website configurator makes a
call to an external service (api_website) hosted on
iap-services.odoo.com to retrieve a list of industries.
This call might fail if the external service is done.
This potential failure is now correctly handled:
On '/api/website/1/configurator/industries' call
failure, the configurator is silently skipped and the
user is redirected to the view website.theme_view_kanban
closesodoo/odoo#69465
X-original-commit: 35311608197ec77bafed82505639314ca693fb19
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Have a large number of attachments with res_field set
Then go to Settings -> Technical -> Attachments -> add a filter "Res
Field" is set.
You will have traceback. This occur because the `_search` function will
omit from results records with res_field set, forcing recursive calls
until either we scan the whole table (80 records at a time) or we hit
max recursion limit
opw-2463634
closesodoo/odoo#69459
X-original-commit: 08fb44a1f8af9684c28c0dd5e82121193d9bef9a
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit, when the user wants to create a timesheet in the
list or form view of this model, the user can quick create a project and
a task if he wishes. The problem is when the user wants to quick create
a task without defining a project in the form view of timesheet, because
the default_project_id of the task will be false and a task without
project will be created.
This commit checks when the user clicks on the task_id field if the
default_project_id exists in the context and if the default_project_id
is not false, then we allow to the user to quick create a task for this
timesheet, otherwise he can just select a task.
Moreover, the js file is updated to fit with the new syntax.
closesodoo/odoo#69420
X-original-commit: d3693ad15eae23829e5ed6ef6dfa915eeab5c8cc
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
1. Create a new user with only "Administration / Access Right"
2. Login as the user
3. Turn on debug mode (via plugin or by editing url)
4. Go to "Settings -> Users and Companies -> Groups"
5. Open any group form / Press "Create" button.
Bug:
Error "You are not allowed to access 'View' (ir.ui.view) records."
A user who is managing "Access Right" must be able to create/edit groups
opw:2492803
closesodoo/odoo#69332
X-original-commit: e179011b3118fe355ea33be194585f674d40df3f
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Co-authored-by: mart-e <mat@odoo.com>
Steps to reproduce the bug:
- Install manufacturing app
- Create a product A
- Create a Bill of Materials for product A
- Archive Product A (Only the final product not any of the components)
- Print BOM or Print BOM Structure & Cost
Bug:
A traceback was raised
opw:2447514
closesodoo/odoo#68116
X-original-commit: 81ee677bd52db388e29c26e255ccab27a286cf94
Related: odoo/enterprise#17186
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When the pos session can't be balanced, a balancing account
is used. First, we take the company balancing account,
but if it is not set, we need to take the property.
Here, it was the wrong method used to get the property.
opw:2439889
closesodoo/odoo#65817
X-original-commit: 550906d48682996cb47142bb0d519fdbfac69642
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Co-authored-by: simongoffin <sig@odoo.com>
This commit fixes two issues encountered during the visitor lifecycle.
1. When a visitor arrives on the website on a non tracked page, a
website.visitor is not created yet, but the visitor can still start a livechat
session. When navigating to a tracked page, a website.visitor is created but the
lifechat session already started is not recovered and the discussion is lost at
visitor's side. This commit links the already started livechat session to the
newly created visitor to ensure that the conversation can still continue
normally.
2. When a visitor logs in, his attributed visitor is linked to the partner. But
there can be only one visitor per partner. If there was already a visitor linked
to the partner, the later visitor's livechat session are updated with the
partner and the visitor is then deleted. But the visitor's livechat sessions are
not linked to the main partner visitor. So when looking at all the session the
partner had, we can only see the main visitor's livechat session.
This commit copy the livechat session of that later visitor to the main partner
visitor to ensure keeping the complete livechat history for each partner.
Task ID: 2460892
closesodoo/odoo#69402
X-original-commit: 4e1034ff2f08fa20bcdc9ac39eb2489d34a9715d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this fix, the runbot would fails randomly during the nightly multi-build in test_accept_meeting_unauthenticated and test_accept_meeting_authenticated.
```py
odoo.addons.calendar.tests.test_calendar_controller:36
FAIL: TestCalendarController.test_accept_meeting_unauthenticated
Traceback (most recent call last):
File "/data/build/odoo/addons/calendar/tests/test_calendar_controller.py", line 36, in test_accept_meeting_unauthenticated
self.assertEqual(self.event.attendee_ids[1].state, "accepted", "Attendee should have accepted")
AssertionError: 'needsAction' != 'accepted'
- needsAction
+ accepted
: Attendee should have accepted
```
There was a hard coded index of a record in a many2one field and sometimes, the record order changed. The asserted value was not the one expected and therefore, the test failed.
closesodoo/odoo#69263
Taskid: 2497816
X-original-commit: 4632ee9a02e366dcb7da6b46f23a3cd367412ccb
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Detailed Operations tab of a stock.picking was duplicated for style
purpose in 30f2ad8c4. But this caused issue eg. in studio because the
same field with very similary path was being edited.
Since having duplicate fields with same path is not very well supported,
this commit remove the duplication after a CSS fix has been done in
web_enterprise after which it is no longer required.
opw-2480311
closesodoo/odoo#69070
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When generating field completion, if there are no o2m or suggested fields,
the method was returning the list of values without adding the regulars fields.
This commit returns correctly the complete set of values.
Task ID: 2508902
closesodoo/odoo#69423
X-original-commit: 134b0f28a43042b22bed1c5f657344544e0f8d22
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Without the f-string literal the XML ID is not printed.
closesodoo/odoo#69419
X-original-commit: d0cbe52c111af923f0df5d0d231b164a150bf2db
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit, `WidgetWrapper` tried to redirect the call to
`updateState` on its wrapped component but it can happen that the
wrapper is not mounted yet and thus calling a function on its wrapped
component will crash.
This commit changes the implementation of `WidgetWrapper.updateState`
to redirect the call to `this.update` which will update the props of
the wrapped component and not directly its state.
task 2504521
closesodoo/odoo#69421
X-original-commit: 67f09b9a9df248fec26f53758e76070ab3171435
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- Hide "A second payment will be created automatically in the destination journal." message when
a payment is posted. Used to only check if payment has a paired_internal_transfer_payment_id,
but posted pre14.3 do not have a value for this field.
- Render "destination_journal_id" only required when payment is draft. As it might be NULL on
pre 14.3 payments, and trigger “invalid fields” error when the user interacts with the view.
closesodoo/odoo#69410
X-original-commit: f942e132dc3b5a37f649e0ab2c11627b497d641c
Signed-off-by: William André (wan) <wan@odoo.com>
When one or more vendor bills in Italian e-invoice format were sent to the registered PEC mailbox, nothing happened.
The e-invoice related vendor bill should be automatically created when the xml file is fetched from the PEC mailbox instead.
- There was a traceback when account_move.l10n_it_einvoice_name was searched because it's a non-stored computed field.
- Also, the field name account_move.source_email was used, but it was renamed to invoice_source_email.
- The xml parsing etree.fromstring() was incorrectly used with string arguments instead of bytes.
- The context was mistakenly initialized twice on invoice creation.
Tests have been provided for the email reading methods.
opw-2460485
closesodoo/odoo#69347
X-original-commit: da64c1eec4b66a28ec4327f30d15352c2f109b29
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: Paolo Gatti <lordkrandel@users.noreply.github.com>
This commit fixes multiple bugs related to the new link popover edition [1].
Those bugs mostly comes from new editor integration [2] conflicts, as those
where merged almost at the same time and needed a quick fix of rebase
conflicts.
- The navbar & footer link would not load the popover link edition anymore,
as it was only targetting `#wrap`.
- Double click on links was re-introduced but it was supposed to be gone.
- Tooltip from Edit and Unlink inside the popover remained open after popover
was closed.
- Some leftover code that were not related to popover but kept during the
rebase.
[1] Commit 8fcf930a6b
[2] Commit 740168ce8dclosesodoo/odoo#69389
X-original-commit: e13966cc8e04111a9e18a344132546c6baa79fea
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
When creating a recurrent event, an SQL contraint requires the field
`day` to be correcly defined. However, if the recurrence rule is like
"every last Monday of the month", the field becomes useless and may be
undefined. As a result, the SQL constraint will prevent the creation of
such a recurrent event.
For example, the situation will happen when the user creates this
recurrent event on Microsoft Calendar and then tries to sync with Odoo.
The recurrent event data will contain:
```python
{
'rrule_type': 'monthly',
'day': 0,
'byday': '2',
'month_by': 'day',
'weekday': 'TU',
# ...
}
```
OPW-2439814
closesodoo/odoo#69387
X-original-commit: 02886f65e9026e1f7617c8b23c3d87edd358b168
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
The following two points are necessary adaptations for
the correct functioning of the configurator with the
module deployed on iap-services.
- The routes of the api_website module deployed on
iap-services.odoo.com use model converters to retrieve
the industry selected by the user. The configurator
has been updated accordingly. We now use industry id
instead of industry name. Using id instead of name make
record retrieval faster and model converters handle
exception if the record doesn't exist.
- 'homepage' is now added to the requested pages by
the client. Previously, this page was added by the iap
module to the requested pages.
The following two points are changes to the configurator
route handling:
- multilang=False has been added to the route rendering
the configurator in order to avoid having the lang in
the url.
- If no step is specified in the url, the implicit step
is 1. Therefore /website/configurator/1 has been changed
to /website/configurator.
closesodoo/odoo#69370
X-original-commit: b6efa4caf6514484c254869cb2f1965d207e7c65
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Sébastien Mottet <smottet@users.noreply.github.com>
Purpose
======
With the fixs we've made in project, the difference between the various rates grows thinner. Currently, the only thing that makes a difference is whether an SO is defined on the project or not. We should simplify these very similar concepts for the user.
In fact, the user will not choose the pricing type anymore, he will configure what he wants and the pricing_type is computed based on it.
## Details
- Simplify the pricing type in the project settings, as said before, the pricing_type is no longer stored and visible in the project.project form view. This field will be computed based on the configuration made by the user in the 'Invoicing' of project form view.
- Remove the filter on the selection list for SOL in project.task, when the SO is defined in the project. Now a task can have a partner different than the one defined in its project. And this filter blocked the choice of the SOL in this case because the partner is different.
- Update the sale_timesheet_tour since the pricing_type is not visible, this tour need an update to correctly work.
- Remove the pricing_type in contrains of _check_sale_line_type method. Since the pricing_type is not compute, this field must no longer be in the constrains.
- When the customer of the task is different then the one in the project, the SOL determined in the timesheet of the task is the SOL of the task (That is the task rate as pricing type).
- Remove the link_selection in create SO wizard of project. Because the fix done in stable, hide this field and thus this wizard only create a new SO. That's why this field is deprecated and unused, so it is removed.
- Remove related pricing type field in the create SO wizard. Since the pricing type is no longer choose by the user, this field is useless in this wizard. That's why, this field is removed.
- Remove the warning displayed when the user unchecked the allow_billable checkbox in project.project form view. Because this warning is no longer useful and very annoying for the user each time he has this warning. The user should be conscious the impact of this changes.
task-2442683
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#66181
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, the user can define some employee mappings and let
the default sales order item of the project empty.
This commit adds a default SOL when the first employee mapping is added
by the user in the project form view. This default SOL is either the one
with a service product and remaining hours is greater than 0 for the
same customer than the SOL choose in the first employee mapping or the
SOL given in the first employee mapping.
task-2442683
closes#66181
Before this commit, the user can choose any SOL for any customer in the
sale_line_id field of the project and also in the employee mappings.
The problem is when the user create a task for a customer A, the default
SOL of the project can be no selected if this SOL is not for the
customer A. Also, some employee mappings can be unused for this task if
the SOL of the employee mapping is not for the customer A.
Moreover, if the customer selects a customer in the project, the SOL
initially choose in this project can be removed if the customer is not
the same.
For these reasons, the commit adds a compute for the partner_id field in
the project.project model. This compute is trigger when the user select
a default sales order item (SOL) for the project or select an SOL in the
first employee mappings for this project. With this changes, the SOLs
choose will be for only one partner (customer) in a project.
task-2442683
closes#66181
Before this commit, when the user configures his project and wants to
set a default SOL, he must first define the customer of the project
before setting the SOL. Same process for the SOL in employee mappings.
This commit allows the user to choose a SOL as default SOL or the one in
the employee mappings in his project even if no customer is defined into
it.
task-2442683
closes#66181
When the user uncheckes the allow_billable field in the project, then we
need to remove the SOL in the tasks of this project.
This commit removes the SOL when the task is in a non billable project.
task-2442683
closes#66181
This commit adds some tests to check the value of the pricing_type based
on the value of the allow_billable, sale_order_id, sale_line_id and
sale_line_employee_ids fields in project.project model.
task-2442683
closes#66181
Before this commit, the user can select the SO in the project to filter
the SOLs in its tasks and in SOL fields in the project form view. But
since, the user can now select any SOLs of the customer defined in the
project or task. Then this field is useless to defined in the project
form view.
This commit converts the sale_order_id field into a related field of
the one in the sale_line_id field of the project. Moreover, the
sale_order_id field is now invisible in the view, the user just need to
select the default sales order item in the project and the SO of the
project will be the SO of the default sales order item.
Then, some unit tests have been updated to essentially remove the
sale_order_id in the using of create and write methods of
project.project model.
Finally, the sale_timesheet_tour has been updated in this commit to
remove the step when the user selects the default sales order of the
project.
task-2442683
closes#66181
Before this commit, when the SO is defined in the project, the user can
only select the SOLs defined in this SO.
This commit removes this filter to select all service SOLs with their
state is equal to 'sale' or 'done'.
task-2442683
closes#66181
Before this commit, when the user creates a task in a project in which
the partner is defined, the partner in the task is the one in the
project. If the user changes the partner in the task, then the SO in
this task should not be the one in the project since the partner is
different.
This commit removes the SO if the partner in the task is different than
the one in the SO.
task-2442683
closes#66181
Before this commit, the "create sale order" button on project form view
is visible when the project is billable, the partner is set and the
pricing_type is different than 'task_rate'. But since the pricing_type
changes we need to update this condition to display this button when the
pricing_type is equal to 'task_rate'. Because the others pricing types
mean the project has already had a SO.
This commit changes the visibility condition of this button to display
it when the project is billable, the partner is set and the pricing type
is equal to 'task_rate'.
task-2442683
Before this commit, when the user unchecks the allow_billable, we
display a warning to alert him the impact of this changes.
This commit removes this warning because we don't need it now, the user
knows the impacts of this changes.
task-2442683
Since the pricing_type in the project is a compute non-stored field and
the user edits no longer this field. The condition on this field is not
valid.
This commit removes this related field in the
'project.create.sale.order.line' wizard and change the condition using
this field to keep the initial behaviour.
task-2442683
closesodoo/odoo#66181
Before this commit the link_selection is no longer used because this
field has recently been rendered invisible in the view.
So, in this wizard we can only create a SO.
This commit removes this field in the wizard and also the code about the
link the project to an existing SO.
task-2442683
closesodoo/odoo#66181
Before this commit, we search the last prepaid service SOL in which the
remaining hours is greater than 0 and it is in the SO of the project.
The problem is when the customer of the task is different than the one
in the project. No SOL is found as default SOL in the task because the
SO in the project is not for the customer in the task.
This commit checks if the customer of the task is the same than the one
in the project, if yes, then we the search in the prepaid service SOL
with the remaining hours is greater than 0 in the SO of the project.
task-2442683
closes#66181
Before this commit, when the partner_id is set in project and the
partner_id in the task is different, if the user changes the SOL in the
task, the SOL of each timesheets keeps the SOL defined in the employee
mapping.
This commit gives the SOL of the task if the partner_id of the task is
different than the one in the project.
task-2442683
closesodoo/odoo#66181
Since the pricing_type is compute non_stored field and the fixed_rate
value of this is set when the sale_line_id is defined in the project.
The condition checks if the pricing_type='fixed_rate' is useless.
task-2442683
closesodoo/odoo#66181
Nicolas Lempereur