Steps to reproduce:
- Get Marketing Automation module and mass_mailing module
- Go to Marketing Automation > Configuration > Favorite filters
- Create a new filter with for example, Recipient Model as Contact and
the domain to be 'Name contains test'
- Now we go back to Campaigns (Inside Marketing Automation) and create a
new campaign with the filter that we have just created.
- Create a new activity for this campaign with any mail template and
save it.
- Now just pres "start" to start the campaign.
- After that you can also use "Launch a test" to see the trace-back.
Issue:
We receive a trace-back when we try to access to a value of a undefined
object. That it is launch whenever we have a campaign with filters.
Solution:
Added the handling of the case when the inputElement is undefined.
opw-3146908
closesodoo/odoo#117185
X-original-commit: b5b0d665ef2ea492bf7f9823da7f7982b0ddefa6
Signed-off-by: Thiry Renaud (reth) <reth@odoo.com>
Before this PR it was not possible to disable the link preview by setting
`mail.link_preview_throttle` to 0. This feature was lost in the refactoring.
This PR reintroduce this feature.
closesodoo/odoo#117101
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
make clear for the user that the keyboard can be used for the search
task-3175239
closesodoo/odoo#116546
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Using o-spreadsheet features and functions is done using
the same import module as if it was installed from npm.
Additionaly, by adding the library as dev dependency in package.json[1], IDEs can
now leverage Typescript types for autocomplete and type checking.
The "alpha" release tag is always the lastest master version.
[1] enable web tooling `addons/web/tooling/enable.sh` ;)
closesodoo/odoo#115972
Related: odoo/enterprise#38471
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
When importing a vendor bill/invoice, a matching partner is searched. If
no match is found, a new partner will created.
task-3141337
closesodoo/odoo#117168
X-original-commit: 08a6bbd92276f92f215d3225f3f14ae8a908f034
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
The aimf of this commit is to make the query of a specific tag with a
specific sign easier by avoiding all the filtering in
`expression._get_tax_tags().filtered(lambda t: t.tax_negate)`
With this commit, we just leverage the existing filtering on domain to
only get the desired tag.
no-task
closesodoo/odoo#117167
X-original-commit: 6eb53a3802d24e283b8334b6f245ffe87dddcbe8
Related: odoo/enterprise#39044
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Current behaviour:
The project profitability panel doesn't take into account the AA
distribution of the project's AA for solo invoices and bills.
Expected behaviour:
It should take the distribution set into account.
Steps to reproduce:
- Install Accounting, Sales, Project, Purchase
- Settings > Activate AA
- Create a new project with a new AA for it.
- Create a new bill or invoice, on the line set the 2 AA, one with
the project's AA with some X%, and the other AA is irrelevant (the
sum of all AA on the line should be 100%)
- Confirm the invoice/bill
- Go to the project profitability report (project updates), see that
we have 100% of the line value that contributed, when it should have.
Reason for the problem:
The contribution of the AA was not taken into account when computing
the project profitability for solo invoices/bills (invoices/bills
w/o SO/PO respectively)
Fix:
Additionally get the analytic_distribution when fetch the
account_move_lines to compute the project's profitability.
Affected versions:
- 16.0
- saas-16.1
- saas-16.2
- master
opw-3246199
closesodoo/odoo#117163
X-original-commit: c3c66d05d039514c9dd02ebdede20a3dff757728
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Settings>Accounting, activate analytics
Create an Analytic Plan:
- Default Applicability: Optional
- Add 1 applicability line:
- Domain: Vendor Bill
- Product Category: All / Saleable / Office Furniture
- Applicability: Mandatory
Create a vendor bill, fill partner, billdate and create a line without
product
Save and Confirm
Action will be blocked with message:
"One or more lines require a 100% analytic distribution."
This should not occur as the mandatory applicability should not match
the bill
opw-3189829
closesodoo/odoo#117162
X-original-commit: c4f90cf7b116fbec8516659475c4e1160a00b2f1
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
When editing an action using the dev options, one may need to update the
action helper of the current action. Currently, the html field used to
edit the action helper does not have the "codeview" option. As a result,
the raw html of the action helper can not be edited easily. To solve
that problem, this commit will simply add the "codeview" option on the
html field.
task-3252414
closesodoo/odoo#117032
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
before this commit, open a pos session form, click on
cash register smart button and if you click on view
button, traceback is shown.
* open a pos session
* click cash register smart button
* click view button under ID column
* traceback is shown
after the commit, on clicking view button traceback wont
be shown and view will get opened.
closesodoo/odoo#116897
X-original-commit: 5ce6bdb3ba0f098177022fcdd7dfad3f1c27aae6
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
This commit adds a new service "overlay" that will be used as a base
for other service which displays a component on foreground like
"popover" or "dialog". The services "popover", "dialog" and "effect"
already uses this new service to have a common container.
The "overlay" service also fix a stacking context issue that could
happen when a popover opened a dialog and this dialog then opened
another popover thanks to the common container.
task id: 3233266
closesodoo/odoo#115308
Related: odoo/enterprise#38786
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Currently there is no way of knowing who changed the address
of a partner. This field is of high importance and should be
tracked to be able to follow who is editing it.
As addresses are represented with a bunch of fields, tracking
them individually would result in weird-looking tracking
messages with each value stacked on top of the other.
To avoid this, we take advantage of the fact that tracking can
be used on non-stored compute fields to log any change as a
change over the full address.
The full address is derived from the contact_address field to
take advantage of the existing regional formatting of addresses.
It is however modified to replace return to lines with commas to
accomodate the formatting of tracking messages in the front-end.
task-3165293
closesodoo/odoo#114695
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Steps to reproduce
==================
- Access a company with no records in transfer model (IT Company, SE Company, etc.)
- Go to transfers menu
- Click Studio
- Click form view button
- Click view tab on the left
- Click Show invisible elements
- Error "The requested change caused an error in the view. It could be because a field was deleted, but still used somewhere else"
Cause of the issue
==================
Since we are not editing an existing record, the PopoverWidgetField
component is loaded without a field value (it is an empty string).
This means that JSON.parse will fail
opw-3249161
closesodoo/odoo#117148
X-original-commit: ddb36467b401ec401b813182d172f5aab329baa7
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Before this commit, in the form view dialog of an x2m, resequencing an
x2m will cause a crash.
Why:
The basic_relatonal_model passes the wrong view type to the basic_model
when resequencing. In this case, we want to use the form view.
How to reproduce:
- Going into a form view with an editable x2m
- Open a record of the x2m in a form view dialog with an x2m containing
a handle field
- Change the order of the records using the handle field (resequence)
Before this commit:
A crash is displayed
After this commit:
The records have been resequenced correctly.
closesodoo/odoo#117145
X-original-commit: 003e6f27db767cd80758b868c8afbf73b78f1abe
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Reproduction:
1. Switch to French, create a /heading 1, and input nothing
2. The placeholder “Heading 1” is not translated
Fix: add translate function around the terms and manually add the
translations in pot
Note: since OdooEditor.js is under web_editor/static/lib/web-editor,
only the js code under /static/src/ is considered for translation export
The translation is manually added with specific path. In Odoo 16, the
path is changed to /static/src/ and translations can be exported
correctly. The translation code paths added here should be changed in
Odoo 16
Related PR adding translations: https://github.com/odoo/odoo/pull/93272
opw-3224482
closesodoo/odoo#117142
X-original-commit: 5f297854348e073a3915bca5cec13066f6abe90e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Install german localization
Select DIN5008 for the document layout
Print an invoice
After 5030a0c199
In the report header information about the partner are replaced by
company info
opw-3208615
closesodoo/odoo#117065
X-original-commit: bed793c82cd8810ba3fe3aac9ee67691a1b39122
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
This commit refactors the current model structure of spreadsheet-related
module. Data fields are integrated into an abstract model
`spreadsheet.mixin` and all sub-models are inherited from it. This way
we can group all decode/encode logics into one place.
task 3222572
closesodoo/odoo#116498
Related: odoo/upgrade#4473
Related: odoo/enterprise#38692
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
1. Display no result when having no matched results.
2. Hidden when clicking outside of the field.
3. Be visible when clicking inside the field.
4. Add related tests
task-3208033
closesodoo/odoo#116214
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
All write operations on the `project.task` model are slowed down significantly
by a dict comprehension mapping tasks to their user_ids because of the access
rules checks. By adding a sudo to that dict comprehension, this commit makes it
bypass those checks and speeds it up.
Task-3164004
closesodoo/odoo#115037
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
*: pos_epson_printer, pos_restaurant, pos_six
This commit continues the work of reducing the reliance of the pos
modules on legacy features from the JS framework, such as core.Class and
mixins, by converting the ProxyDevice class to ES6 (and renaming it
HardwareProxy, to avoid confusion with DeviceProxy from iot). It also
makes it available as a service in the new environment so that we can
hopefully get rid of the legacy environment in the near future.
closesodoo/odoo#114821
Related: odoo/enterprise#37991
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Purpose:
- In the project, My Tasks and All Tasks menu are related to the task model so
having two main menus for the same model which display almost the same
thing would not be great for UI and it'll not look good if we add another menu
in the future or via customer customization.
So in this Commit:
- We have added a menu named Tasks which has 2 sub-menus My Tasks and All Tasks
which would be great to display tasks
task-3180910
closesodoo/odoo#113335
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Purpose of this commit to improve generic usage of project app.
So in this commit done the following changes:
- the sequence field should not be optional for project.task.type list view
- move the fa-play icon next to the remaining hours widget in kanban view
- add filter and separator for burndown chart search view
- transform the 'milestones' stat button into 'x Milestones /n y Reached
- change the recurrence banner
- add the placeholder for the label_tasks field 'e.g. Tasks'
task-2947481
closesodoo/odoo#99528
Related: odoo/upgrade#3872
Related: odoo/enterprise#31047
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit total time on timesheet for projects and
invoices computed according to user's access to timesheet and
security rules on account.analytic.line are quite complex.
So, in this commit compute those fields with sudo to ease the
perfomance of project and sale apps.
task-2890184
closesodoo/odoo#99372
Related: odoo/enterprise#30950
Related: odoo/upgrade#3843
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This PR add a populate command for models `mail.channel`, `mail.channel.member`
and `mail.message`.
It will only create channel of type `channel` and `group`.
I used this bash function to quickly delete/create a database and populate it.
```bash
# Quickly drop the current db (it use the git branch name as database name) and
# create a new one that will be populated.
# usage: odoo-populate model_name size
odoo-populate() {
dropdb $(git branch --show-current)
odoo -i mail --stop-after-init
./odoo-bin populate --models $1 --size $2 -d $(git branch --show-current) --addons-path=~/projets/pro/odoo/addons,~/projets/pro/enterprise --c ~/projets/pro/.odoorc
}
```
closesodoo/odoo#115827
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The allow_group_range_value option is used in one arch of a kanban in
CRM. We therefore believe that this is not standard behaviour.
So we decided to move this logic to the custom view that uses it.
Part of Task: 3179751
closesodoo/odoo#117023
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Quotation templates feature simplifies creating Sale Order on backend.
To make the process even faster, Odoo allows set up Default Quotation Template,
which is applied automatically on every new quotation. However, it doesn't make
sense to apply quotation templates for orders created by eCommerce users.
Particularly, it leads to an error if quotation template has recurrence.
Fix by ignoring default quotation template on eCommerce sale orders.
STEPS
1. Create a sale template with a recurrence
2. Set this sale template as the default sale template in settings
3. Go to /shop page and add any product to cart that is not recurring
-> The sales order will be created with the default template's recurrence
4. Try to pay & confirm the order
-> Error when trying to make an order with recurrence and no recurring product
opw-3115232
closesodoo/odoo#116913
X-original-commit: 1d083cad6fe9a5e2356e53ac922c8ff9e75d52f6
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
In order to be able to see all quotes linked to a crm lead,
we now allow cancelled quotes in the domain of leads of the
stat button action. The cancelled ones are not shown
until the 'quotations' filter is removed in the search.
Also, cancelled ones are not accounted for in the counter.
To do that, we create a specific domain method for the action,
and override it in sale_renting_crm to exclude rental orders.
The _get_lead_quotation_domain is not directly modified as one
would also need to exclude cancelled quotes in _compute_sale_data.
Also, we cannot add an expression.OR method in the action
code, because the domain is extended in sale_renting_crm and the
domain order of operation could include cancelled rental orders,
which is not desired.
Task-3237734
closesodoo/odoo#115864
Related: odoo/enterprise#38957
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Bigger and centered emojis in grid
- Better visual clue of focused input from search icon
- No search screen with icon + text
- Consistent sizing of emoji picker in case of failure
- Added basic test for active highlighted category
closesodoo/odoo#117001
Signed-off-by: Debondt Didier (did) <did@odoo.com>
Before this commit, no default date filter was set on the report.
For older databases, it results in a systematic heavy query.
opw-3134913
closesodoo/odoo#116770
X-original-commit: b8b75d5bdd8901d2c8fcd54d63c78c0d36254933
Signed-off-by: nda-odoo <nda@odoo.com>
Fixes an issue with the tax total computation that would happen
if the tax of type group has the same tax_group_id as one of the
children taxes.
This would lead to a tax total computation where the other child
of the tax will be summed into the child sharing the same tax
group.
As it is no longer possible to set a tax group id on a tax of
type group, we do not need to take it into account when computing
the tax total anymore.
To reproduce before the fix:
- Make a bill with the Australian tax au_tax_purchase_10_service_tpar_no_abn.
- Save.
- You will notice that the amount in the tax total widget for the tax
"GST 10%" is wrong as it takes into account the amount of the other
tax.
After the fix, the amount will not be wrongly grouped anymore. And the
tax total will correctly represent what is in the line_ids.
Task id # 3252271
closesodoo/odoo#117093
X-original-commit: aa736d7d0189784e6ff81b7acfcd0ac0e1cbe6b7
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Use case
--------
If the a user has partner_share set to NULL not to 'false'
he will not receive any notification
The orm consider False and NULL value as False for boolean field,
the query that fetch the recipient data should have a consistent
behavior
closesodoo/odoo#117083
X-original-commit: a50fbd1f9404fd05eb576474eb3d10c94d37aa52
Signed-off-by: Thibault Francois <tfr@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
While presenting a survey, sometimes it is good to know what content
will be next. However, this is not possible currently.
This commit improves the behavior to display a tooltip msg on the right
arrow so that the presenter/speaker knows what is next.
Task-2791000
closesodoo/odoo#97713
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the invoices were marked as sent only when
sending them via email or post.
After, it is mark as sent once the PDF is being generated via the
send&print wizard, as it becomes computed based on the presence of
the PDF.
Rational, we want to consider a generated invoice via the
send&print wizard as being sent as it can be printed/downloaded.
This also makes the invoice available in the portal.
closesodoo/odoo#117085
X-original-commit: 9e656aabe4f6840ee5c200a21832dad958ea6892
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Detry Thomas (det) <det@odoo.com>
When creating analytic lines from bills or invoices, the category is not put on them.
opw-3214062
closesodoo/odoo#117056
X-original-commit: 7729b5bf006d0a988ce84e2f953749866fae7b16
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
When creating an invoice from e-commerce, the invoice is not sent by mail but the user must be able to see it from the portal.
closesodoo/odoo#117033
X-original-commit: 61d3b9d7186eb82b3227c65c26f629672f99d446
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
The computation of `<account.move>.made_sequence_hole` on the list view
takes a non negligible time (about 1/4 on test server), for instance on
* Accounting > Vendors > Bills
* Accounting > Customers > Invoices
* Accounting > Accounting > Journal Entries
The less sequence resets there are (yearly reaset instead of monthly, or
even no reset at all), the worse this gets.
For instance, the plans below are generated on a journal with ~35k
`account.move.line` (and 10M in total) using the same sequence prefix,
you can see that the first plan needed to remove everything after the
index scan whereas the second plan has the right row directly.
Plan Before
===========
```
Nested Loop Left Join (cost=198.96..1160.00 rows=1 width=4) (actual time=3557.525..3557.528 rows=0 loops=1)
Output: this.id
Filter: (other.id IS NULL)
Rows Removed by Filter: 80
-> Merge Join (cost=198.53..271.00 rows=41 width=21) (actual time=0.360..0.873 rows=80 loops=1)
Output: this.id, this.journal_id, this.sequence_prefix, this.sequence_number
Merge Cond: (company.id = this.company_id)
Join Filter: ((company.fiscalyear_lock_date IS NULL) OR (this.date >= company.fiscalyear_lock_date))
-> Index Scan using res_company_pkey on public.res_company company (cost=0.26..81.53 rows=16 width=8) (actual time=0.007..0.013 rows=2 loops=1)
Output: company.id, company.fiscalyear_lock_date
-> Sort (cost=198.27..198.46 rows=76 width=29) (actual time=0.350..0.474 rows=80 loops=1)
Output: this.id, this.company_id, this.journal_id, this.sequence_prefix, this.sequence_number, this.date
Sort Key: this.company_id
Sort Method: quicksort Memory: 31kB
-> Index Scan using account_move_pkey on public.account_move this (cost=0.43..195.89 rows=76 width=29) (actual time=0.029..0.329 rows=80 loops=1)
Output: this.id, this.company_id, this.journal_id, this.sequence_prefix, this.sequence_number, this.date
Index Cond: (this.id = ANY (...))
Filter: ((this.sequence_number <> 1) AND ((this.name)::text <> '/'::text))
-> Index Scan using account_move_sequence_index on public.account_move other (cost=0.43..21.67 rows=1 width=21) (actual time=0.076..44.451 rows=1 loops=80)
Output: other.journal_id, other.sequence_prefix, other.sequence_number, other.id
Index Cond: ((other.journal_id = this.journal_id) AND ((other.sequence_prefix)::text = (this.sequence_prefix)::text))
Filter: (this.sequence_number = (other.sequence_number + 1))
Rows Removed by Filter: 34298
Planning Time: 2.250 ms
Execution Time: 3557.579 ms
```
Plan After
==========
```
Nested Loop Left Join (cost=198.96..371.96 rows=1 width=4) (actual time=0.607..0.608 rows=0 loops=1)
Output: this.id
Filter: (other.id IS NULL)
Rows Removed by Filter: 80
-> Merge Join (cost=198.53..271.00 rows=41 width=21) (actual time=0.336..0.359 rows=80 loops=1)
Output: this.id, this.journal_id, this.sequence_prefix, this.sequence_number
Merge Cond: (company.id = this.company_id)
Join Filter: ((company.fiscalyear_lock_date IS NULL) OR (this.date >= company.fiscalyear_lock_date))
-> Index Scan using res_company_pkey on public.res_company company (cost=0.26..81.53 rows=16 width=8) (actual time=0.007..0.010 rows=2 loops=1)
Output: company.id, company.fiscalyear_lock_date
-> Sort (cost=198.27..198.46 rows=76 width=29) (actual time=0.325..0.329 rows=80 loops=1)
Output: this.id, this.company_id, this.journal_id, this.sequence_prefix, this.sequence_number, this.date
Sort Key: this.company_id
Sort Method: quicksort Memory: 31kB
-> Index Scan using account_move_pkey on public.account_move this (cost=0.43..195.89 rows=76 width=29) (actual time=0.026..0.305 rows=80 loops=1)
Output: this.id, this.company_id, this.journal_id, this.sequence_prefix, this.sequence_number, this.date
Index Cond: (this.id = ANY (...))
Filter: ((this.sequence_number <> 1) AND ((this.name)::text <> '/'::text))
-> Index Scan using account_move_sequence_index3 on public.account_move other (cost=0.43..2.45 rows=1 width=21) (actual time=0.003..0.003 rows=1 loops=80)
Output: other.journal_id, other.sequence_prefix, other.sequence_number, other.id
Index Cond: ((other.journal_id = this.journal_id) AND ((other.sequence_prefix)::text = (this.sequence_prefix)::text) AND ((other.sequence_number + 1) = this.sequence_number))
Planning Time: 2.766 ms
Execution Time: 0.648 ms
```
closesodoo/odoo#116973
X-original-commit: 1a1742cd825ef9c44ac185ce076cce5f1f789c01
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
1) `survey_user_input.slide_partner_id`: this is a sparse column (so using
`btree_not_null` means a very small footprint). But it makes a ton of
difference when trying to delete a slide.slide.partner entry.
e.g. on a db with 500k survey inputs, the deletion of 1000
`slide.slide.partner` records goes from 40s to 100ms (400x speedup)
2) `survey_user_input_line.survey_id`: this is the inverse field of the
`survey_user_input.user_input_line_ids` O2M field, so the index is
always useful to retrieve the O2M lines. It will also marginally help
for cascading the deletion of any `survey_user_input` record from
case 1).
closesodoo/odoo#116875
X-original-commit: 2dc929cd530ba4fd80c17f91af2bfad02a819dd6
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Before this commit, the margin in the sale_total group was following the total.
It was preventing putton another field before the margin. This commit allows putting
another field before the margin without depending on the installation order.
closesodoo/odoo#116820
Taskid: 3232957
X-original-commit: 03286dffa8693edce846c064795e8a26d5b61890
Related: odoo/enterprise#38886
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Arnaud Joset <arj@odoo.com>
textwrap does the ellision and we don't need to replace newlines characters.
It is done for us already (except that multiple newlines will be replaced by
a single space).
closesodoo/odoo#116778
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Avoid search_count in a loop using a filtered_domain.
Also removed a sudo, as anyway this method is already called in sudo in
most cases.
Part-of: odoo/odoo#116778
before this commit, there is typo in unit of measure
after this commit, the typo will be corrected and
unity of measure will be updated to unit of measure
closesodoo/odoo#116764
X-original-commit: 11b89fcffe748e6119648dbc32594f0c0bdcf064
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Purpose of this commit when a project is billable, it is likely to be for one
specific customer. The goal is to allow users to directly set a partner from
the project creation wizard instead of having to navigate to the configuration
menu to get access to the full project form view.
So this commit add customer in project simplified view.
task-3185880
closesodoo/odoo#112602
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Purpose of the commit is to do the generic improvements for project.
So in this commit did the following changes:
- add a space between 'access to:' and the name of the course in SOL nameget.
- hide the 'remaining hours' value if the nb of 'initially planned hours' is
equal to 0 in task list view.
- hide the 'initially planned hours' and 'hours spent' values if they are equal
to 0 in task list view.
- hide the 'milestone' and 'assignees' fields if they are false task calendar
popover
- hide the 'remaining hours on SO' value if there is no SOL set on the task
list view
- use the progressbar widget for the progress field update list view
task-2949984
closesodoo/odoo#112265
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
First issue (functional)
------------------------
Steps to reproduce:
- create a type of leave
- create an allocation for X days for month A without end date
- create an allocation for Y days for month B without end date
- create a leave of X + Y days for month A
Remark:
Months A and B do not have to be consecutive.
Issue:
If allocations have not end date, it is possible to use allocation
in an other interval.
Second issue (display)
----------------------
On the dashboard we see the total number of allocations
even if we cannot place them for allocations without an end date.
This behavior contradicts that of allocations with an end date.
Solution:
---------
Make an additional check on the start date of an allocation.
This verification is very restrictive.
It stipulates that if the end date of a leave is before
the start date of an allocation, the allocation in question
must not be taken into account in the dynamic calculation
to link the allocations to the leaves.
In addition, this verification will make sure to trigger
the hack of the commit 02695aa095428b4ef5045f9c90d1b508ec9d896c.
Therefore a Validation Error will be raised.
From a display point of view, it will be fixed
on the dashboard and in the modal window to make a leave request.
opw-3230286
closesodoo/odoo#117024
X-original-commit: 745221b478e0a587ac51fd3f0fca8e067b473b12
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
With the addition of the pos_daily_sales_reports module, the get_sale_details
function return was different which was deregulating the expectation of
the SaleDetailsReport.xml file (printing detail reports on ticket).
This is now changed thanks to an override of some part of the file
when installing the module pos_daily_sales_details.
closesodoo/odoo#117006
X-original-commit: 79d309d38bdf0ef68c1c85228b94cdea0da55ccf
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Current behaviour:
Search filter is not showing correct results for projects that are in
overtime. Some projects that are not in overtime are not shown.
Expected behaviour:
Search filter for projects that are in overtime should work correctly.
Steps to reproduce:
- Install Project, Timesheets
- In one of the projects, create a task in an "In Progress" stage
- Add an employee on it, planned hours to 1h, and log in the
timesheet 50 hours (so the task is clearly in overtime of 49h)
- In that task, add an employee, planned hours to 50h
- In the same project, create a task in a folded stage, log in the
timesheet 1h (the task is +49h remaining hours in the green)
- Fold the stage when done editing the stage.
- In the project default view, we can clearly see that the project
is in the red (-49h).
- Filter based on overtime, the project is not present in the results
Reason for the problem:
There is a divergence of behaviour between the compute and the
search method of the `is_project_overtime` on the project.
The compute takes only the overtime of the tasks that are not in a
folded stage. While the search is query all the tasks of the project,
regardless of stage and summing those to deternine if the project is
in overtime. So if you have 2 tasks, one in a folded stage and the
other not, that have `remaining_hours` that are cancelling each other,
the search result is incorrect for that project
Fix:
Update the SQL query in the search method for `is_project_overtime`,
to reflect the domain conditions from the compute about the stages.
Affected versions:
- saas-15.2
- 16.0
- saas-16.1
- master
opw-3182077
closesodoo/odoo#116992
X-original-commit: 69f1441133e30b8dc0cc331afcec933d694665e0
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Issue:
Despite the behavior which is to recalculate the hours to keep
the same number of days from the point of view of the company,
when distributing allocations for a department,
an incomprehensible calculation appears.
This behavior appears even if all the working times are the same
(both for the company and for the employees).
Cause:
When we need to calculate the number of days for an allocation given in hours,
we use the number of hours per day of the employee.
However, in the case of an allocation by department, this value is `0.0`.
Therefore, we will use the hard-coded `HOURS_PER_DAY` value which is `8.0`.
This value makes sense if the company's schedule is 40 hours per week (8 hours per day).
It is also useful in the case of an undefined company's schedule.
But if the company schedule is defined and is different from 40 hours per week,
this value no longer represents anything.
Solution:
First use the number of hours from the point of view of the company
before using the hard-coded value.
opw-3205685
closesodoo/odoo#116991
X-original-commit: 6ddf340f0f19e1abd58ce8345bdc25763cb32878
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Ivan Yelizariev