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
Before this commit, when the pricing type of the project is either
project rate or employee rate, the list of possible SOLs in sale_line_id
is filtered to have only the SOLs in the SO.
This commit removes this filter because we just want to use the SOL set
in the project as a default value.
task-2442683
closesodoo/odoo#66181
Before this commit, the user must choose a pricing type and configure
it.
This commit changes the pricing type to a compute non-stored field and
now the user will configure what he wants for his project and the
pricing type changed according it.
That is, the SO, SOL and employee mappings fields will always be visible
in the basic project. When the user set the SO and SOL the pricing type
becomes project rate and if he add an employee mapping, then the pricing
type becomes employee rate.
task-2442683
closesodoo/odoo#66181
PURPOSE
Improve the quality of the Calendar application by updating the user interface
and using a multi-calendar like display.
SPECIFICATIONS
Prepare calendar view for the changes listed below in order to ease them and
fix some issues. Check commits for more details.
Modify the design of the event card based on the invitation status and the
owner of the event. If the status needs an action for the user or is uncertain
only the outline of the event is displayed. If the event is accepted or the
user is the owner, the display is the same as before (card is filled).
If the event is declined, the card is filled but the opacity is decreased and
the text is crossed.
Save filters of the calendar view for the user. We now save the status of each
filters to avoid the user to do the same operations if he go elsewhere in the
meantime.
Improve the way the events are displayed to the user. Now, an event is
displayed for each attendee of the event that are selected in the filter.
These events are displayed correctly based on the status of the attendee
in the event. The colors displayed for the events now represent the attendees
and not the organizer anymore.
If an attendee edits an event, it is edited for all others attendees.
Also, when an attendee that is not the organizer try to delete the event,
then the event is now declined in place of being deleted. If the organizer
deletes the event, it is deleted for all attendees.
In case of an event where all attendees have declined it but the organizer,
the organizer see now a danger icon before the name of the event and it's
outlined and not filled with color, no matter of the actual status of the
organizer in the event.
Some other changes include
* remove organizers filter from the sidebar
* rename "Responsible" into "Organizer"
LINKS
Task ID-2196775
closesodoo/odoo#55190
Related: odoo/upgrade#1532
Related: odoo/enterprise#12196
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When loading translations from Session, if no lang is defined in context or html,
it is loading translations of en_US lang by default.
No default should be used to fallback on the language of the current user.
opw-2501708
closesodoo/odoo#69336
X-original-commit: 0b9ab4efcf66d4c5099a9f33d2fb1b4dd814eb5c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
With this commit we try to improve the way the events are displayed
to the user. Now, an event is displayed for each attendee of the event
that are selected in the filter. These events are displayed correctly
based on the status of the attendee in the event.
The colors displayed for the events now represent the attendees and not the
organizer.
If an attendee edit an event, it is edited for all others attendees.
Also, when an attendee that is not the organizer try to delete the event,
then the event is now declined in place of being deleted. If the organizer
delete the event, it is deleted for all attendees.
In case of an event where all attendees have declined it but the organizer,
the organizer see now a danger icon before the name of the event and it's
outlined and not filled with color, no matter of the actual status of the
organizer in the event.
task-2196775
COM PR: odoo/odoo#55190
ENT PR: odoo/enterprise#12196
UPG PR: odoo/upgrade#1532
The calendar renderer used a template for events.
Now moved as a configurable template to ease futur calendar changes.
This commit adds also a custom event to the calendar renderer so that custom
implementations have a way to re-render the event items within the calendar
after making internal changes to the event records.
We introduce also a new option for a field "filter_field" which allows to specify
the field of the model in which we will save the status of a filter.
This is preliminary changes in order to make the calendar view able to modify
the attendance status of a meeting and refresh the events to visually display
if the user is attending or not.
Task ID 2196775
COM PR: odoo/odoo#55190
ENT PR: odoo/enterprise#12196
UPG PR: odoo/upgrade#1532
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: jeh-odoo <jeh@odoo.com>
This commit is to fix two problems when transpiling an @odoo-module file.
1. When a file exports an object with a long name, the regex EXPORT_FROM_RE will cause catastrophic backtracking. The regex will take a long time to resolve.
Example:
```js
export {a, aReallyVeryLongNameElement};
```
2. When a file exports an object without ending the line with ';'. The regex EXPORT_OBJECT_RE will remove spaces and line breaks that follow this kind of export.
Example:
Input:
```js
export {a}
xxx
```
Output:
```js
Object.assign(__export, {a})xxx
```
Output after this commit:
```js
Object.assign(__export, {a})
xxx
```
closesodoo/odoo#68868
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
When an auto-validating reconciliation model is defined for matching
bank statement lines to invoices, it was possible to get a traceback
when the bank statement lines were in a certain order and matched in a
certain way.
In particular, if the first bank statement line is priority 3
(communication_flag True) and the amount is an exact match with the
invoice, it will be instantly reconciled. If there's a second line
that's a priority 5 match, it crashed because _filter_candidates didn't
take into account that candidates_by_priority could be empty if the
candidates were already reconciled.
Instead we just return an empty list of candidates and priorities when
this happens.
closesodoo/odoo#69331
Ticket: 2507189
X-original-commit: e9538d9cee092e034b85187a2eae857349f42ce7
Signed-off-by: William André (wan) <wan@odoo.com>
When we deactivate the work orders in the settings, new MOs still
use operations that were assigned to the BoM, it just does not show the
Operations tab. We fix that by archiving the operations when work orders
are deactivated in the settings.
closesodoo/odoo#66108
Related: odoo/upgrade#2344
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Beforehand, users could configure an account as non reconcilable
even when it was configured as a payment credit or debit account
in a journal. This prevented journal items to be reconciled
Now, when a user tries to set an account as non reconcilable,
we check if there is no journal with a payment credit or debit account
set to this particular account. If there is at least one journal,
then we display an error message stating the journals names and ids
that the user would have to modify before changing the account
configuration.
closesodoo/odoo#69317
X-original-commit: 87c207f3a408abb93d9b8378ef4aa1744935d86d
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Julien CHEVREAU <Julien-CHEVREAU@users.noreply.github.com>
Antoine Guenet