The code which removed the background image of a snippet when choosing a
background color worked kinda by chance. Indeed, on the final click on
the color option, the snippet background-image was reset... to the
current background-image, which is none thanks to the color preview.
Unfortunately, in some themes, the gradient color option interferes:
the current background-image at a color choice is equal to the current
gradient, and thus, that gradient is being moved as an inline style.
The bug was introduced with https://github.com/odoo/odoo/commit/285d95e946e5a15139c961e30dbe3598e0d99f6a
(as, before, the background reset was done by simulating a click on the
'background: none' option item, which was removed).
Closes https://github.com/odoo/odoo/pull/27808
Before this commit, when accessing journals through the menu item
Bank Account, one was able to enter an partner.bank account number
But, in case the partner.bank already exsited, there was no way to select it
and a cryptic unicity constraint was raised
After this commit, one can select an account already existing
OPW 1884515
closesodoo/odoo#27840
When creating a "purchase.requisition" record, the default Operation Type was
always the one defined in the company 1 even if the user was not in the company 1.
opw:1890190
closesodoo/odoo#27830
Steps to reproduce the bug:
- In CRM, create an new Sales Channel
- Go to Reporting/Sales Channels
- Click in the new channel on "Click to define a target"
Bug:
Two input fields called "Set an invoicing target" appeared in the new channel
opw:1889406
closesodoo/odoo#27781
forward port of 62cbc5f
Have a user in English, put a sale report as "favorite" (pinned to dashboard app)
Change the user's language
Before this commit, the pinned view was in English (because it was recorded that way)
After this commit, the pinned view is in the user's language.
OPW 1890664
closes#27799
Producing a manufacturing order on components with more than one unit
could leads to multiple move line reserved on this component. Marking the
workorder as done, in that case, will trigger an error saying "Cannot set
the done quantity from this stock move, work directly with the move
lines". Instead of setting the quantity done directly, this commit
uses the magical function _set_quantity_done() that manage the case
of more than one move lines.
OPW-1888780
closesodoo/odoo#27773
Swiping a credit card through pos_mercury no longer worked on the
payment screen.
3a74afd21e introduced some special code
in BarcodeEvents for mobile Chrome. This code relies on an invisible
input being filled in by barcode device. On the payment screen the POS
uses a keypress event handler on body to manage input. This handler
preventsDefault which stops the input from being filled in.
It's worth noting that this new approach in
3a74afd21e is not fully equivalent to
the original barcode events handler. Events are not redispatched, so
this effectively disables keyboard input on the payment screen (or
anywhere where it is used).
opw-1888466
closesodoo/odoo#27820
Producing a manufacturing order on components with more than one unit
could leads to multiple move line reserved on this component. Marking the
workorder as done, in that case, will trigger an error saying "Cannot set
the done quantity from this stock move, work directly with the move
lines". Instead of setting the quantity done directly, this commit
uses the magical function _set_quantity_done() that manage the case
of more than one move lines.
OPW-1888780
closesodoo/odoo#27773
Usecase to reproduce:
- Create a BoM for a product with route Manufacture
- Use replenish wizard in order to fill your stock
It traceback due to an infinite loop.
It happens because when the production order creates the raw
moves, it does not set a product template. However a default_product
template is in the context and is used as default value. So it creates
a raw move with the component as product.product and the production product
as template. Since they are related it will modify the product_tmpl_id
of the product.product. It result by having a component with the
finished product as template and it will use the same stock rules and
bom again and again.
This commit clean the context before running procurement rules.
opw-1890661
The option `showSearchInput` has been added on the ModelFieldSelector to allow
the user to easily filter the displayed fields. An input is displayed in the
popover title.
The search method is fuzzy for optimal results.
closesodoo/odoo#27788
This commit will avoid having the company_id and/or website_id field(s) alone
on the top right of the 'extra' tab if the `picking_type_code` is in `incoming`
task-1894793
closesodoo/odoo#28016
(mainly views and ActionManager)
- add missing docstrings
- fix typos
- correctly order functions and imports
- put functions in correct sections
- stop using 'event' as argument of handlers
- don't call handlers directly
- remove trailing spaces/tabs
- move module created in stable version to its own file
- follow js guidelines in general
closesodoo/odoo#28024
Before this commit, our asset bundles had a special behaviour for
bundles of type css: because of an old limitation in IE9, css files had
to be split to make sure they had less than 4095 rules per stylesheets.
Since we no longer support IE9, this code can be removed, which should
slightly simplify the bundle code, and should slightly reduce the number
of requests required to properly load odoo.
closesodoo/odoo#27933
The library es5 shim was usefull for older browsers that do not implement
completely the es5 specifications, like IE9.
As we do not support browsers older than IE11, that fully supports all
the features of es5, the library has become useless.
Removing this library will remove a little bit of noise in the callstack
when debugging.
closesodoo/odoo#27877
The last time when a user connected to Odoo is a different concept than the last time when a user authenticated to Odoo. I can authenticate once and connect many times afterwards (cookie/session).
closesodoo/odoo#27963
Purpose of this commit is to rename type column to something matching the
the real business use of the field. That way it is easier to find and grep
in the code. It also lessens potential conflicts with type build-in python
function. It also lessens conflicts when using the field in JS as type
is a build-in attribute.
Renaming type column is a long-living issue. We choose to do it at the
beginning of the v13 development to catch errors as soon as possible.
This commit is linked to task ID 1896245. It is also a subpart of community
PR #27599.
closesodoo/odoo#27722
1 Display department on manager list views
==========================================
On the manager list views (Leaves/Allocations to approve), the department
is not displayed. Display it on these list views, but keep it hidden for the
employee views.
2 Allow to search employees on allocations
==========================================
3 Search on department and on children departments
==================================================
Currently when searching on a department (on the employee view for example)
we only retrieve employees from the specific department. It should return
all the employees from the department and also from its children
departments, like for partners or companies.
Adapt all the search view where a department field is used by
specifying a 'child_of' operator.
TaskID: 1892639
closesodoo/odoo#27902
Purpose of this commit is to rename type column to something matching the
the real business use of the field. That way it is easier to find and grep
in the code. It also lessens potential conflicts with type build-in python
function. It also lessens conflicts when using the field in JS as type
is a build-in attribute.
Renaming type column is a long-living issue. We choose to do it at the
beginning of the v13 development to catch errors as soon as possible.
This commit is linked to task ID 1896245. It is also a subpart of community
PR #27599.
Purpose of this commit is to rename type column to something matching the
the real business use of the field. That way it is easier to find and grep
in the code. It also lessens potential conflicts with type build-in python
function. It also lessens conflicts when using the field in JS as type
is a build-in attribute.
Renaming type column is a long-living issue. We choose to do it at the
beginning of the v13 development to catch errors as soon as possible.
This commit is linked to task ID 1896245. It is also a subpart of community
PR #27599.
Purpose of this commit is to rename type column to something matching the
the real business use of the field. That way it is easier to find and grep
in the code. It also lessens potential conflicts with type build-in python
function. It also lessens conflicts when using the field in JS as type
is a build-in attribute.
Renaming type column is a long-living issue. We choose to do it at the
beginning of the v13 development to catch errors as soon as possible.
This commit is linked to task ID 1896245. It is also a subpart of community
PR #27599.
Purpose of this commit is to rename type column to something matching the
the real business use of the field. That way it is easier to find and grep
in the code. It also lessens potential conflicts with type build-in python
function. It also lessens conflicts when using the field in JS as type
is a build-in attribute.
Renaming type column is a long-living issue. We choose to do it at the
beginning of the v13 development to catch errors as soon as possible.
This commit is linked to task ID 1896245. It is also a subpart of community
PR #27599.
Purpose of this commit is to rename type column to something matching the
the real business use of the field. That way it is easier to find and grep
in the code. It also lessens potential conflicts with type build-in python
function. It also lessens conflicts when using the field in JS as type
is a build-in attribute.
Renaming type column is a long-living issue. We choose to do it at the
beginning of the v13 development to catch errors as soon as possible.
This commit is linked to task ID 1896245. It is also a subpart of community
PR #27599.
Purpose of this commit is to rename type column to something matching the
the real business use of the field. That way it is easier to find and grep
in the code. It also lessens potential conflicts with type build-in python
function. It also lessens conflicts when using the field in JS as type
is a build-in attribute.
Renaming type column is a long-living issue. We choose to do it at the
beginning of the v13 development to catch errors as soon as possible.
This commit is linked to task ID 1896245. It is also a subpart of community
PR #27599.
Purpose of this commit is to rename type column to something matching the
the real business use of the field. That way it is easier to find and grep
in the code. It also lessens potential conflicts with type build-in python
function. It also lessens conflicts when using the field in JS as type
is a build-in attribute.
Renaming type column is a long-living issue. We choose to do it at the
beginning of the v13 development to catch errors as soon as possible.
This commit is linked to task ID 1896245. It is also a subpart of community
PR #27599.
On the manager list views (Leaves/Allocations to approve), the department
is not displayed. Display it on these list views, but keep it hidden for the
employee views.
Purpose
=======
Currently when searching on a department (on the employee view for example)
we only retrieve employees from the specific department. It should return
all the employees from the department and also from its children
departments, like for partners or companies.
Specification
=============
Adapt all the search view where a department field is used by
specifying a 'child_of' operator.
Purpose
=======
Currently if a department is modified on an employee, the department is
modified accordingly on the leave request if it still in 'draft' or
'to submit' states.
This should also be the case for confirmed leaves, if it is still planned
in the future.
Note: A test has been added for this specific use case.
TaskID: 1882544
closesodoo/odoo#27661
Purpose
=======
- A manager could want to follow only home working of its own department
- A HR officer could want to follow only sick leaves of all dpts.
We have to improve what people follow and how they follow it in the leaves module
Specifications
==============
Subtype on department
---------------------
In department form view, right now, people can follow approvals
Instead we should have some generic and specific subtypes depending on the leave type
For instance, a HR Officer wants to follow only sick leaves and a manager only home working
Following mechanism
-------------------
Remove first / second approval subtype differences
if a leave type is not linked to a specific subtype, consider only classic
people follow it (employee and assigned HR people / manager)
Link leave type to subtypes, with some by default (i.e. home working, ...), not mandatory
When creating a leave type, link it to the department to be able to
activate the subtype for only one department.
closesodoo/odoo#27620
Purpose
=======
- A manager could want to follow only home working of its own department
- A HR officer could want to follow only sick leaves of all dpts.
We have to improve what people follow and how they follow it in the leaves module
Specifications
==============
Subtype on department
---------------------
In department form view, right now, people can follow approvals
Instead we should have some generic and specific subtypes depending on the leave type
For instance, a HR Officer wants to follow only sick leaves and a manager only home working
Following mechanism
-------------------
Remove first / second approval subtype differences
if a leave type is not linked to a specific subtype, consider only classic
people follow it (employee and assigned HR people / manager)
Link leave type to subtypes, with some by default (i.e. home working, ...), not mandatory
When creating a leave type, link it to the department to be able to
activate the subtype for only one department.
According to the setting set on the pricelist
More the discount_policy field from sale to product to be usable in point of
sale, even without sale installed
Task id: 1853454
closesodoo/odoo#27310
Christophe Simonis