Purpose
=======
The 'service_tracking' selection field on the 'product.template' model in the 'sale_timesheet' module
had its 'task_new_project' option renamed to 'task_in_project'.
If one or more sale_order_line have a product configured with this option, a new 'project_id' field appears
on the sale_order under the 'Sales Information' section.
When a project_id is selected, the analytic account on the sale order is automatically changed
to this project's analytic account.
This allows handling more use cases on sale_order:
- If a sale_order_line has a service product with that new option and no project_id configured on the sale_order:
-> create a new project based on the configured project_template_id and then create a task in that project
(same behavior as before)
- If a sale_order_line has a service product with that new option and a project_id is configured on the sale_order:
-> directly create a task in the selected project_id
The behavior does not change for the 3 other options ('no', 'task_global_project' and 'project_only').
Specs
=======
- Add project field on sale order in "other infos" tab, shows only when a product on the SO has the option activated
- If projec is selected on SO, create task in this project, otherwise it creates a new project (as before)
- Rename 'task_new_project' into "task_in_project"
- Allow to have the new option with project template
- Selectable projects on Sales Order are `billate_type` in 'no' and 'task_rate'
- Never link SO's project to SO or AA
- Add onchange on project_id to select this project's analytic account on the SO
- Non stored computed field to check if at least one SOL has the new option
Use cases
- 2 SOL with new option (no template) will create 2 tasks in SO's project
- 2 SOL with new options (one no template, one with) + 1 SOL "create new P no T" --> create 2 tasks in SO's project and one new project
Task #1915660closesodoo/odoo#29772
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
Task #1915660
Purpose
=======
Analytic Account field of a project should not be visible for non-members
of the "analytic.group_analytic_accounting" group.
This is now consistent with the other analytic account fields of the application.
Task #1915660
Purpose
=======
If one or more sale_order_line have a product configured with this option, a new 'project_id' field appears
on the sale_order under the 'Sales Information' section.
When a project_id is selected, the analytic account on the sale order is automatically changed
to this project's analytic account.
This allows handling more use cases on sale_order:
- If a sale_order_line has a service product with that new option and no project_id configured on the sale_order:
-> create a new project based on the configured project_template_id and then create a task in that project
(same behavior as before)
- If a sale_order_line has a service product with that new option and a project_id is configured on the sale_order:
-> directly create a task in the selected project_id
The behavior does not change for the 3 other options ('no', 'task_global_project' and 'project_only').
Specs
=======
Add project field on sale order in other info tab, shows only when a product on the SO has the option activated
if projec its selected on SO, create task in this project
Tech Spec (jem)
=======
On product:
- rename 'task_new_project' into "task_in_project" (help message precise either new project (based on template) or
SO's project is prior
- allow to have the new option with project template
On sale order:
- non stored computed field to check if at least one SOL has the new option.
- if so, display project field
- selectable project are billate_type in 'no' and 'task_rate' (TBC for the 2nd)
[awa: also add 'analytic_account_id' != False in domain]
- setting project on SO should change the AA of the SO.
[awa: add onchange on project_id to select this project's analytic account on the SO]
- Never link SO's project to SO or AA
[awa: do not touch the project_id's sale_order_id and analytic_account_id fields for this use case]
- 2 SOL with new option (no template) will create 2 tasks in SO's project
- 2 SOL with new options (one no template, one with) + 1 SOL "create new P no T" --> create 2 tasks in SO's project
and one new project
Actually, when running browser_js tests, the test automatically fails
when a console error is seen.
In some cases, an exception can be thrown during a tour but without
console error. In that case, another type of devtools protocol event is
fired: Runtime.exceptionThorwn. This event is not catched by the
browser_js test.
With this commit the above mentioned event is catched and the test is
directly considered as failed.
closesodoo/odoo#31555
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
During the event tour, the save button is clicked before the drag and
drop is finished and cause an uncaught exception.
With this commit, an extra trigger is used to check the presence of the
dirty flag that is set when the page is changed and is ready to be
saved.
When a move is created in a picking through the scrap button, it must
not be visible in the picking, and should be accible through the
stat button showing the srap.
Now to hide, those moves from the picking view, we are checking that the
move has a different picking type than the one on the picking, which can
lead to invisible moves, that are not in the picking view because they
have a different picking type and not in the scrap stat button because
they don't have scrap object.
To fix this behavior, we are hiding from the picking the ones having a
scrap object linked instead of the one having a different picking type
closesodoo/odoo#31810
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
commit 4697d74480 update our bootstrap version to 4.3.1, one change of that version is that
bootstrap now escape the content of popover and title removing the table element. https://blog.getbootstrap.com/2019/02/13/bootstrap-4-3-1-and-3-4-1/
This result in the popover in the reconciliation widget being empty.
Therefore since the content of the popover was safe as it was rendered by Qweb.render, we disabled completely the sanitizer
for the popover in the reconciliation widget.
closesodoo/odoo#31797
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
After the update of jQuery, crashes were no longer displayed (in
dialogs) on browsers using the unhandled-rejection-polyfill lib
(e.g. firefox). This was due to a bad conversion from ES6 to ES5.
Issue reported on the jquery update pad.
closesodoo/odoo#31767
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Purpose
=======
The 'service_tracking' selection field on the 'product.template' model in the 'sale_timesheet' module
had its 'task_new_project' option renamed to 'task_in_project'.
This is a preliminary renaming for task #1915660.
It's better to always have a relevant name in the image URL for SEO.
Also make sure there is always an alt on the image.
closesodoo/odoo#31705
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, you can configure tracking for consumable type
product. Now, tracking and date settings are hidden when the product's
type is set on consumable.
Also, resets tracking when change type on consumable.
We chose to not enforce this constraint in the model because we consider
it a bit overkill and we did not want to block migrations.
Task #1938594closesodoo/odoo#31355
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Those tests were skipped because they were failing
non-deterministically.
This commit aims to make them deterministic by putting back some
guard promises that were lost during the jquery update adaptation.
This commit also fixes a lingering issue with one of the asserts.
We observed that sometimes, the "alt" and "title" attributes where
both present on the element but displayed in different order in
the string returned by wysiwyg.getValue(). This is because there
is no set order in the attribute returned by jQuery.html().
Because of that, I replaced the simple sring test by a thorough
manual comparison of the result that is expected to be equivalent.
closesodoo/odoo#31671
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*partner_autocomplete,test_main_flows
In jQuery 3, the active element in autocomplete dropdowns is no
longer identified with class 'ui-state-focus' on the <li/>, but
with class 'ui-state-active' is on its child <a/>. Moreover, the
background color of the active element is now set on the <a/>
instead of the <li/>.
This rev. adapts scss rules accordingly, and selectors in the
main_flow_tour.
Issue reported on the jquery update pad.
closesodoo/odoo#31693
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
When an import failed because of a specific cell, the error was
Error cell found while reading XLS/XLSX file: #N/A
Add the line and column index in the error for better debugging
Translate error message
Cherry-pick of odoo/odoo#30729 in master
Closes#30729closesodoo/odoo#31677
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
after the update of jquery, all promises are asynchronous.
In the invoices, a class was added to the section and note field before
it was rendered.
To fix this, we are now waiting for the rendering to be completed before
adding the class.
closesodoo/odoo#31666
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Following of https://github.com/odoo/odoo/pull/28457. Promises which
are rejected are acting the same way as exceptions and thus have to be
catched. The Odoo `guardedCatch` method is not stopping the exception
though. In the backend, unhandled promise rejections are catched by the
CatchManager, which then ignore them.
This commit makes the frontend act the same way regarding unhandled
promise rejections. We might want to share the crash manager behavior
someday.
Part of https://github.com/odoo/odoo/pull/31664closesodoo/odoo#31664
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Task 1943019
onchange should ensure that you don't have both a credit and a debit <>0
prefill account/partner if the user is recording several lines a row with the same account/partner
the journal should be set by default
closesodoo/odoo#31593
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
We had to manually convert the unhandled-rejection-polyfill lib,
and we forgot to replace this by self in two arrow functions.
This was causing crashes e.g. on Firefox.
We also forgot some uses of const, which is not really an issue as
const is supported on all browsers, but it is not ES5.
Issue reported on the jquery update pad.
closesodoo/odoo#31658
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
The goal of this task is to update jQuery from version 1.11 to 3.x.
Task-id : 1896658
As we are skipping 2 magor versions, there are some breaking changes in the jquery library described here: https://jquery.com/upgrade-guide/3.0/
Main changes are:
-------------------------
1. Update the libraries jQuery, jQueryUI, QUnit and select2 to their latest version.
The link to generate the build of jQueryUI with the used components: [jquery UI build](https://jqueryui.com/download/#!version=1.12.1&components=111110010101111110100010110000011010000000000000)
2. Use native promises ([a complete explanation about promises here](https://github.com/getify/You-Dont-Know-JS/blob/master/async%20%26%20performance/ch3.md)) everywhere possible:
In order to [be A+ compliant](https://promisesaplus.com/), the jq3 deferred uses `setTimeout(..., 0)`
for every then and catch, which takes between 4 and 10 ms by call.
This would be way too slow to use in Odoo.
To prevent this, we have used the native Promises everywhere possible.
Be it with jq deferred or native promises, all promises are now asynchronous,
this example will ALWAYS result in printing first "just after blabla" then "blabla"
because the `then` function will always be asynchronous (opposite to
what jquery used to do)
```
function () {
Promise.resolve("blabla").then(console.log);
console.log("just after blabla");
}
// console:
// just after blabla
// blabla
```
3. On native promises, you should see the catch like a try/catch in
javascript, meaning that it will catch all errors including coding errors:
For this we have introduced the concept of `guardedCatch`, which will be executed
on promise rejection unless the promise is rejected because there is
a code error or runtime error (calls on undefined, etc).
4. Native Promises do not have `done`, `fail` and `always` methods nor does it have the `state` method
- `fail` can be replaced with `guardedCatch`
- `return $.when(x).done(function() ...)` can be replaced with
```
var x = Promise.resolve(); // we get the x promise in a local variable, without then
x.then(function() ...); // we add a new handler to x. This operation returns a new promise we don't care about
return x; // we return the x promise that will be completed without waiting for the then
```
- `$.when().done(function ...)` without the return can be replaced by `then(function ....)`, because if it is not returned, it doesn't matter what is chained or not `$.when().always(function() ...)` can be replaced with
```
var always = function() ...
Promise.resolve().then(always).guardedCatch(always);
```
- It is not possible to inspect the state of a promise, except in debug tools of chrome and firefox. Any code that relies on `$.Deferred.state()` should be rewritten to use flags in `then` and `catch` handlers. Remember that it is not possible to execute the handlers in a synchroneous manner, so when a promise is created, its `then` will never be called on the same execution stack. At best it will be called on the next microtask tick (before the next setTimeout).
5. We have introduced the concept of guardedCatch, to copy the behavior of the old fail:
The guarded catch will only execute the handler in parameter if the rejection reason is not an `Error`
```
var failingPromise = Promise.reject({message:"I am the rejection reason"});
failingPromise.guardedCatch(function(reason) {console.log(reason);}); // is called, then returns a rejected promise
failingPromise.catch(function(reason) {console.log(reason);}); // is called
```
will write the reason "I am the rejection reason" to the console twice: once because the `guardedCatch` will execute (and return a rejected `Promise` with the same reason it was called), a second time because the `catch` will catch the rejected reason returned by the `guardedCatch`
```
var promiseWithError = Promise.resolve().then(function() {
a.b = 0; // <-- the variable a does not exist, so a.b is an error
});
promiseWithError.guardedCatch(function(reason) {console.log(reason);}); // will not be called
promiseWithError.catch(function(reason) {console.log(reason);}); // will be called
```
contrary to how deferred used to work, here the catch will be called because it behaves like a `try... catch...` and will catch the coding error like if it was a business error. The `guardedCatch` however does not call the handler if the rejection reason is an error.
In all Odoo code, we never reject a promise with an error and always use objects to defined the rejected reason, so it is a good idea to use `guardedCatch` everywhere.
6. Native Promises can have only one parameter passed to a `then` function or a `catch` function:
`xxx.then(function(param1, param2) {...}); // param2 will never have a value`
- we can replace `$.when(prom1, prom2).then(function(result1, result2) { ... });` by
```
Promise.all([prom1, prom2]).then(function(results) {
var result1 = results[1];
var result2 = results[2];
...
});
```
7. We are now using ES7 code in the unit tests (async await).
closesodoo/odoo#28457
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
Problem is that jQuery animate uses jQuery deferreds, so it may
happen in tests that we fold a thread window, and we have to wait
for 2 (?) nextTick to see that the window is actually folded.
We use a css transition instead, which produces the exact same
result.