When using command "6" (SET), the one2many field's inverse was not
assigned on the lines.
closesodoo/odoo#65675
X-original-commit: ba733a9ac73dcf978ed7eaab7681781b2d5a9bfc
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When retrieving company dependant values, the computed domain called
search_multi method of ir.property as normal user.
Since odoo/odoo@8f57863707 ir.property records are no longer
readable by a normal classical user.
To reproduce:
Add a domain using a company_dependant field
e.g. on res.partner, with purchase installed, modify the parent_id
field in form view to
<field name="parent_id" ... domain="[('property_purchase_currency_id','=',property_purchase_currency_id)]" />
When clicking on the parent_id with a low priviledge user, an
access-right error is raised, as the user doesn't have access to
ir.property records
Fixesodoo/odoo#65450closesodoo/odoo#65643
X-original-commit: 33868b4e14124800035ea99df111b35b4199ae60
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When syncing with a Google account, if user's email is different from
Google account, the server creates a new partner. Moreover, the synced
event are not linked to the current partner.
To reproduce the error:
1. Have two Google accounts GA01 and GA02
2. With GA01, add an event to Google Calendar and add GA02 to guests
3. In Odoo, sync with Google Calendar using GA02
- The partner linked to the current Odoo user must have an email
different from GA02's email
Error: The calendar is synced, but the user needs to check "Everybody's
calendars" to see the synced events. A new partner has been created
using GA02's email. The synced events are linked to this new partner
instead of current user's partner (`self.env.user.partner_id`).
Moreover, Google event's organizer is always added to attendees but, if
it this is indeed the case (so if the organizer is also an attendee),
`google_event.attendees` already contains this organizer.
OPW-2440033
closesodoo/odoo#65630
X-original-commit: 12cb76bdfe7a5affb7580485473be71cfa37658a
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Purpose
=======
Currently there's no easy way to retrieve all the contract using a given
calendar.
closesodoo/odoo#65621
Related: odoo/enterprise#16157
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit keeps the sales related fields together in a contact form view
by moving 'property_delivery_carrier_id' field at last, instead of after
'user_id' (Sales Person).
Task Id : 2445997
closesodoo/odoo#65030
Related: odoo/enterprise#15946
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
You have have a scheduled activity precisely at 8:12:34 AM (send an
email, anything). You trigger the cron using that precise moment. The
cron runs at 8:12:00 AM which is before the scheduled moment so the
activity is skipped. Imagine there is no other scheduled activity that
coudld trigger the cron, it is only run at worst 23h59 minutes later
thanks to the daily cron execution fallback.
The assumption of a29bb54 is wrong, it groups the moments the
cron should be triggered by grouping the moments on the rounded down
minute. This is not consistent with the trigger API that promises the
cron will run *as soon as possible but **not before*** the scheduled
moment.
closesodoo/odoo#65555
Task: 2452697
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
This below case is not working before this commit:
when Bill to Ship to where Delivery address partner is not registered and not have GSTIN
closesodoo/odoo#65599
X-original-commit: d9b409247303c6b165a7df381169f2480a19900f
Signed-off-by: Josse Colpaert <jco@openerp.com>
The work location of an employee was previously a fields.Char. That was
changed to a Many2one field to a the new model called work.location.
That had some consequences in other modules that had to be slightly
adjusted. The modules impacted were hr, hr_appraisal, hr_payroll.
Task id: 2335646
closesodoo/odoo#63192
Related: odoo/enterprise#15235
Related: odoo/upgrade#2020
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, the page can be set in cache with some data pre-filled.
Now we don't cache anymore the contactus page if you have GET params.
closesodoo/odoo#65608
X-original-commit: 4ce59c3ab26a441ad8b7f2fd038b690cf897231d
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Currently, the subtype checked selection is not saved when the user adds and
removes subtypes. Indeed either an addition is performed, either a removal
but having both is not correctly taken into account when updating an existing
subscription.
How to reproduce
* click on the pencil icon to edit the subscription of the follower;
* as an example default "Discussions" will be the only one selected;
* check "Notes" and save;
* -> this works;
* click again on the pencil icon and uncheck "Notes" and check "Activities"
then save;
* -> this does not work as only removal is performed (Activities is not
checked);
The problem only occurs when you unchecked subtypes and checked other ones.
This commit fixes that behavior by taking into consideration both new
subtypes and subtypes to remove.
LINKS
Task ID-2205643
Task ID-2241688
COM PR #56775
X-Original-Commit odoo/odoo@d16b036638closesodoo/odoo#65605
X-original-commit: 18cb4f6d8120a30a7f5d05eef107ac1734dd1431
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Thibault Delavallee <tde@odoo.com>
Co-authored-by: Shahista Pathan <sat@odoo.com>
Behavior before the commit
--------------------------
find_or_create define in mail module called
super if no partner is found based on the email_normalized
super call find_or_create define in base that make
a search again on the email before the creation
This cost two search every time a new partner should be created
and the search on email is less efficient than the search on
email_normalized
after the commit
----------------
Only the search on email_normalized is done before the creation
drawback: if a module that does not depends on mail module
override find_or_create the code will not be triggered anymore
the module should depends on mail module
closesodoo/odoo#65565
X-original-commit: 49d5b3813e57f2cd91d582de9b9bb534f05d2dc3
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In case of bad translation that doesn't contain the placeholder
Context:
A bad Japanese translation was inserted
#. module: mail
#: code:addons/mail/models/mail_thread.py:0
#, python-format
msgid "Create new %(document)s"
msgstr "新しい%(ドキュメント)を作成する"
The translation has been corrected but use the 14.0 syntax of _ method
to include placeholders and fallback on the English source term in
case of bad translation
cf odoo/odoo#52155closesodoo/odoo#65586
X-original-commit: 48cc6b1f2b3208e8affd5f6a261751fe973c2091
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Modify manually for the languages where the language is not on Transifex
closesodoo/odoo#65564
X-original-commit: 793dc3fc1002aca15f5e0a7c33baf36a4550d180
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
PR [1] introduced the auto save feature (changes in form and list
views are automatically saved when the view is left, e.g. with
the pager, breadcrumbs, stat buttons, menus...).
However, there was one case that had been left aside: when we close
the tab or browser. This commit ensures that we also save the
changes in this case.
The record is saved only if it is valid, otherwise the changes are
simply lost (we don't block the tab/browser from closing itself).
Moreover, the beforeunload handler must be *almost* sync (a few
ms setTimeout seems ok, but definitely not an rpc roundtrip). For
that reason, we cannot wait for onchanges to apply before saving.
part of task 2330101
[1] https://github.com/odoo/odoo/pull/60693closesodoo/odoo#65561
X-original-commit: 9949ea14e4f27ca8c0fc84d726ad0434e2e216b8
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Before this commit, it was not possible to center a button using the
editor option 'align center'.
It is because, using document.execCommand(), the Chrome browser doesnt
want apply 'text-align: center' on nodes with centered children. And
the buttons have the boostrap class '.btn' which adds text-align:
center.
So the hack here is disabling the text-align property from the '.btn'
class during the execution of document.execCommand().
task-2423935
closesodoo/odoo#65566
X-original-commit: d4f38c344360713287eed22872614f46dec7e0f6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Previously, when removing all the content of a snippet, that snippet
would get automatically deleted. This was not the case for parallax
snippets because we previously intended the user to drop the parallax
snippet, empty it, and drop other content inside of it.
Recently, we added the parallax option on all snippets, rendering the
previous workflow obsolete. There is now no longer any reason to keep
empty parallax snippets. This commit fixes that.
task-2446008
closesodoo/odoo#65551
X-original-commit: 61f410b57f1c28bd6464b86d1582c22b7fd846d5
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
I misremembered that `_` would go look for the translation stuff
through the stack, but it only goes up to the caller of `_` itself.
Since `clean_filename` has no `cr`, `cursor` or `self` that's never
going to do anything, and it's thus completely useless.
closesodoo/odoo#65534
X-original-commit: ab3122448079d998e88f77704df62d1b1871e918
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The method `_mail_tracker`` must be called after the super call on `write`
closesodoo/odoo#65505
X-original-commit: cfd98d7b0e022b876a4cc99becc2da4f972ea030
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
WHY: PEC server rejects default addresses, so you cannot test connection
---
opw-2371431
closesodoo/odoo#65516
X-original-commit: 876d3b3b8cf9f91a3609871f69b3ce1186d71ac6
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
When a new warehouse is created, the receipts of the purchase orders done in
this new warehouse have different behavior than the ones from the inital
warehouse. With the new warehouse the 'Detailed Operations' tab of the
receipt is visible but not the button next to 'Done' in the 'Operations' tab.
Since no elements are inside the 'Detailed Operations', it requires a manual
entry of all elements for every receipt with backorder.
This aligns the behavior of new warehouses with the inital one, not
showing the 'Detailed Operations' tab in the receipts but allowing to use
the button of the 'Operations' tab.
closesodoo/odoo#65501
X-original-commit: 126102b5b4cd9aa32fb3eb9a763d73e4056d3462
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: npi-odoo <npi-odoo@users.noreply.github.com>
Often the business want to trigger the cron several time at different
moments. The typical use case is the business holds a recordset and
needs to trigger the cron for every record. The current solution is to
loop on each record to call `_trigger` times.
We now allow to invoke `_trigger` with an iterable of `datetime`
objects, and isolate the implementation in method `_trigger_list`.
We also removed the `delay` argument as it was not used.
closesodoo/odoo#65459
Task: 2452697
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Steps to reproduce the bug:
- Accounting - Journal Entries - form view - Print - Invoices
Bug:
A UserError was raised 'Only invoices could be printed.' but in the attachment,
the PDF was generated.
opw:2452278
closesodoo/odoo#65508
X-original-commit: ba32244c10396ff8605e5533e08675a64fbf9d88
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce the bug:
1) Enable Paypal on the Payment Acquirers and select "BE Company CoA" on the company
2) fill the email and enable the "Add Extra Fees"
3) create an invoice on the company "BE Company CoA"
4) preview it as a public user
Bug:
An access error was raised:
Due to security restrictions, you are not allowed to access 'Companies' (res.company) records.
opw:2439896
closesodoo/odoo#65507
X-original-commit: 6b23ff3bdd1d5a3f34a431e2301db5984e0f761a
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- Go to Accounting > Configuration > Tax Report
- Create a Tax Report (with Lines having Tag Name)
- Go to Accounting > Accounting > Tax Adjustments
In wizard, no Report Line can be selected for mandatory "Report Line" field.
Report lines are filtered on "report_id" field, which is a related field to the report line field.
Therefore there is no way to select a Report Line.
opw-2449295
closesodoo/odoo#65502
X-original-commit: 0311cffd89c375a6fc1babacaa19029776bfebfb
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
When you save your custom snippet you probably won't give it a
specific name.
Before this commit several custom snippets name was specified on save
and there was no way to modify their name afterwards
After this commit custom snippets are assigned a generated name but they
can be renamed afterwards
task-2374802
closesodoo/odoo#61483
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Purpose of the task is to Improve the current pricelist line
form view for clarity.
SPECIFICATIONS:
- Move the price computation on top and apply on at bottom.
- Improve the formula view and calculate dynamic tips based
on formula value.
closesodoo/odoo#63733
Taskid: 2373068
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The 'o_text_overflow' class whlie provided on any field, is used to
have classic ellipsis (...) for very long string. However, it is
implemented the way that it occupies the available width for the field
tag it even if the the string is small.
The same class is also utilized in some field widgets like email, phone,
URL etc. But it has a small side-effect due to full width occupancy.
Because the above widgets rendered an anchor tag, the clickable area is on
the whole available width instead of simply on the content provided in anchor
tag. So even if user clicks on the empty area of that field, the click
action is performed (for example, in email field widget, default mail client
pops-up) which should not happen. It should behave like clickable m2o fields
where the action is performed only when clicking the content and not on the
empty area.
With this commit, we wrap the anchor tag, within a container div tag. Here,
the overflow class will be on the container div which will do it's job to
prevent the long strings from breaking the UI, and the anchor tag being its
child, will not be the full width, thus limiting the clickable area. This
commit also makes the related test cases more robust by checking proper
classes for particular widgets.
TaskId - 2345974
closesodoo/odoo#63735
Related: odoo/enterprise#15777
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Example to reproduce:
Drop the "Cover" snippet and try to remove the background
image. Clicking on image button has to be done 3 times to land on the
correct result:
- First click removes image, but not filter and leaves both buttons
checked
- Second click removes the filter and unchecks its button.
- Third click unchecks the image button.
It should be one click to remove image, filter and uncheck both buttons.
The goal of this commit is to prevent _applyOptions() from setting
background-image values if image is not optimizable. This filter will
solve the issues since empty values (badly parsed by getBgImageURL())
won't be added as background urls.
task-2312878
closesodoo/odoo#65438
X-original-commit: aba9056e7baa58decf147313678ad9d1f4522dee
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Purpose
======
The goal of this PR is to write some unit tests about the changes made in Task-2388500, Task-2409761 and Task-2424382 to keep the functional features.
## Determined Sales Order Items in task and timesheets
These tests check if the Sales Order Items (SOL) computed in task and timesheets are the ones expected based on the pricing type defined in the project.
- Check if the SOL in task is the same than the one in project when we create a task in project which has a pricing type to project rate or employee rate.
- When the pricing type is employee rate and we timesheet, check if the SOL on these timesheets are the one expected, that is:
- If the pricing type is employee rate and there are some mapping for employees, normally when we timesheet for an employee in the mapping, we should have the SOL defined in the mapping for this employee in the timesheet.
- If we timesheet for an employee who is not in the mapping then we should have the SOL of the current task.
- When the pricing type is task rate and we defined a customer who has some SOs with services products in project, if we create a task in this project then we should have the customer defined in the project and the one of latest SOLs if it is prepaid service and remaining_hours > 0. Otherwise, the SOL is False.
- When the pricing type is employee rate or project rate and the customer, SO, SOL is defined in the project, if we change the customer then the SO and SOL should be False if the customer in the project is different that the one in SO selected.
- If the pricing type is employee rate then when the customer changed in the project, the SOL in each mapping should also be removed.
## Remaining hours for prepaid service products
This test checks if the remaining hours is correctly computed in project.task when the Sales Order Item in this task contains a prepaid service product.
## Tour JS to check features in the UI
A tour js has been created to check the process with the UI. The steps are the following:
- Go to the Sales App,
- Create a sales order for Brandon Freeman for instance,
- In this Sales Order, we take a prepaid service product (we created this one in a unit test in python as we must not use the demo data to realize the JS tour) and the quantity ordered is 10 hours,
- Check the product_uom field is set on 'Hours',
- Confirm the Quotation to create the Sales Order,
- Go to the Project App,
- Create billable project to timesheet for Brandon Freeman,
- Create task in this project and add a timesheet into it,
- Show in this task that we can see the Sales Order Item linked to the createed timesheet, because this field is hidden by default.
- Go to the Settings menu and then Projects submenu.
- Create a project, and show the three different configurations to invoice services in a project. That is:
- Task rate
- Project rate
- Employee rate
## Miscellaneous
The `project.task.create.sale.order` model has been removed because the wizard is unused since these 3 tasks have been merged.
task-2439304
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#65146
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Generic improvements have been made to improve the Project App and its onboarding.
## Web module
- kankan examples modal: change the 'use this for my kanban' button into 'use this for my project'. To do this, a small change is made in the web module to use the options variable called `applyExamplesText` to change the label of the button in project app.
- A private method called `_getFavoriteIcon` is added in `FavoriteWidget` to easily change the icon based on the boolean value when we override this widget in another module.
## Project App
For project.task model:
- the label of the priority label has been changed from "Priority" to "Starred".
- the user_id field should not be clickable in form view.
For project.project model:
- the fa-star icon has been replaced by the fa-bookmark and fa-bookmark-o icons in the kanban view.
- When the user is the 'Project User', the 'share' button and 'project overview' stat button are hidden in the project form view.
- the 'sales order' stat button is only visible to users who have at least the `sales > all documents access right level` in project form view.
task-2440564
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#65095
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In a multicompany environment, when a expense is created from the
expense email alias, the expense account is computed with SUPERUSER
context, so depending on the SUPERUSER set company, we could get
a mismatch of expense and employee's company and the account one, wich
causes a subsequent error when trying to post the expense.
closesodoo/odoo#65413
X-original-commit: da758c44b19a9339f0c0b1b6a74c11e3e5491a64
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Co-authored-by: simongoffin <sig@odoo.com>
Followup to odoo/odoo#65314: turns out there's a bunch of other leave
requests in the file which will eventually fall on a weekend, and will
probably blow up due to the new validation in 14.0:
- hr_holidays_sl_al in March 2021 because April 17th, 2021 is a
saturday
- hr_holidays_cl_mit_2 in June 2021 because June 5th, 2021 is a
saturday
- hr_holidays_sl_vad in September 2021 because September 25th, 2021 is
a saturday
- hr_holidays_sl_kim in April 2021 because May 1st, 2021 is a saturday
- hr_holidays_sl_kim_2 in March 2021 because July 3rd, 2021 is a
saturday
Solution
========
Instead of hard-coding month-days, move to the first monday after the
original date e.g. if we were looking for the 20, now get the monday
after the 22. In relativedelta terms, `weekday=0` is "the next
monday". The date is then formatted inclusive of the month-day rather
than hard-coding one.
One nit is for the end date:"the next wednesday" may come before "the
next monday" if we're on TU or WE. So we need to first jump to the
next MO *then* to the WE after that, which makes the code a bit
longer (and more redundant). As a result the end date is now "the
wednesday after <the start date>" rather than being a literal 2 days
later or whatever.
The PR updates all the 1-day and 2-day intervals, it also updates the
3 days inclusive (those over 3 which include start and end dates
rather than without) including those updated by #65314 for clarity /
coherence of small intervals. Longer intervals are left untouched,
although we may eventually want to update them so `number_of_days`
computations are more reliable.
Redundancy issues
-----------------
There are a bunch of redundancies / verbosities which don't seem
easy or possible to remove:
* While lxml does resolve entities by default it doesn't load
DTDs (let alone validate them), aliasing various datetimes
& deltas as entities is not an option, not to mention for security
reasons we'd rather stop resolving entities entirely than allow
custom ones.
* While it's possible to define nested safe_eval'd `context` on nodes,
the evaluation context for *those* contains neither datetime nor
relativedelta, so storing a bunch of constants in the (environment's)
context and using that in the expression is not an option either.
* Leaving `date_from`/`date_to` off of some records breaks, probably
because some other field necessary to properly compute *them* is
missing.
Other changes
=============
* Removed explicit settings to `number_of_days` and explicit calls to
`_compute_number_of_days`, seems redundant and unnecessary as the
compute works fine as long as we let it.
* While at it, updated the calls to `action_approve`: moved them next
to the corresponding record (instead of being on the other side of
the file) and used direct references to the subject records rather
than complicated searches.
* Also updated two leave allocations to be created validated OOTB
instead of manually calling action_validate as that's what's being
done elsewhere in the file.
Notes
=====
* In relativedelta lingo, "the next X" is inclusive of the current
date e.g. when looking for the next WE, if the date being offset is
already WE there will be no movement, this can be unexpected.
* Normally relativedelta would be used with the MO/TU/WE/... constants
for weekdays, but we're not exposing those to `@eval` so integer
literals it is.
closesodoo/odoo#65430
X-original-commit: 7840b21483c0012174e6028a39b114ce56f06158
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When changing the bank account by the outstanding account of a payment, invoice's payment_state should be recomputed by the orm.
So, when writing 'account_id' on the liquidity line, 'is_matched' must be recomputed on payment (_compute_reconciliation_status). Then, if reconciled to some invoices, 'payment_state' must be recomputed as well (_compute_amount).
closesodoo/odoo#65427
X-original-commit: 7caf5316407ab8950216592e38551f29207076de
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The purpose of this task is to clean up and provide clear export
file names.
Currently, When exporting data:
- From a pivot view, the file name is 'table'
- From a list view, the file name is technical name of model
so in this commit, Change the export file name as below:
- For list view quick export and standard record export,
the filename will be 'model_description(model_technical_name)'
- For pivot view quick export,
the file name will be 'Pivot(string set on view)(model_technical_name)'
and if string is not set then 'PivotUntitled(model_technical_name)'
In all the cases space and forward slash will be removed.
closesodoo/odoo#64123
Taskid: 2237840
Related: odoo/enterprise#15579
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Issue
- Install "Field Service" app
- Create new task
- Try to select Planned start/end date and valid
Daterange picker is hiding when trying to scroll down to valid selection.
Cause
The daterange picker is closed when ev.target is not inside the picker,
however ev.target always return the document element.
Solution
Do not hide daterange picker on scrolling if on mobile.
Note : It will only apply if scrolling on the daterange picker and
will still hide if scrolling outside this last one.
opw-2428099
closesodoo/odoo#65435
X-original-commit: 1d9b6f56e70faee13cda0ccb9893ed49904ab319
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Filling the new column in SQL is dramatically faster than doing it via
the ORM, which iterates over all the records in the table.
The test case is creating a related field for 100+ records with distinct
values. Setting the field's value was taking more than 100 queries. It
now takes 3 queries.
task-2449313
opw-2380445
opw-2389376
https://github.com/odoo/enterprise/pull/15910closesodoo/odoo#65432
X-original-commit: d66652b4aa514546356306e3eb48eaecaba07c33
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This tour js is used to check if the process is not broken. To do this,
we create an unit test to launch this tour js.
Before launching this test we create a prepaid service product in the
unit test.
Steps of this tour js:
1) Go to the Sales app,
2) Create a Sales Order with the prepaid service product and we order 10
hours for this product.
3) Go to the Project App,
4) Create a billable project to timesheet for the customer who orders
these hours,
5) Create task in this project and add a timesheet into it,
6) Show in this task, we can see the Sales Order Item linked to the
created timesheet, because this field is hidden by default.
7) Go to the Settings > Projects,
8) Create a new project and show the three different
configurations to invoice services in a project. That is, 'task rate',
'project rate' and 'employee rate'.
task-2439304
This commit add a test for project with pricing_type in ['fixed_rate',
'employee_rate']. This test checks when the user changes the partner_id
in the project, if the SO and SOL in project and also in mapping are
removed if the customer selected isn't the one in the SO.
task-2439304
This commit removes the project.task.create.sale.order model because
this wizard is no longer used. Before we use this wizard to create a SO
from ticket and task, but in reality this feature is no used.
The test using this wizard has been changed to keep the behaviour of it.
This test checks if the invoiced timesheet does not change the project
when the linked task changes the project.
Moreover, the both projects used in this test have been switched because
when we invoice the SO the timesheet is in the template project and this
one is not billable.
Thus, we create no invoice. To create an invoice as we expect, we must
have the timesheet in the global project.
task-2439304
This test check if the compute method for the remaining_hours field in
the SOL containing a prepaid service product is correct and also the one
for the remaining_hours_so field in the task which contains a SOL with
prepaid service product.
task-2439304
Raphael Collet