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
Description of the issue/feature this PR addresses:
Creation of backorders only when needed
Current behavior before PR:
- When the option "No Backorder" was selected, a backorder was created then cancelled.
Desired behavior after PR is merged:
- When the option "No Backorder" was selected, no backorders are created.
( Task ID : 46981 )
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#27624
- The docstring for the method `create_backorder(self)` was updated to a more convenient one.
- The kwargs `backorder_moves` was remove since it was useless.
Before this commit, when the user chose to not make a backorder, a backorder was created then immediatly canceled.
This behaviour is now changed as in such a case the backorder is simply not created anymore
- The docstring for the method `create_backorder(self)` was updated to a more convenient one.
- The kwargs `backorder_moves` was remove since it was useless.
Before this commit, if a JS module caused an error while being
evaluated, the error was silently swallowed (and only logged in debug
mode, in the extra information about the state of all modules).
With this commit, we always log the error in the console. Note that
this only applies to JS execution errors. If a file has invalid
javascript structure, then a parsing error will happen, even before the
module system has the possibility to do anythin.
closesodoo/odoo#27836
Before this commit, it was not possible to map one tax to multiple taxes
in the point of sale, just as it is in the account module.
This commit implements fiscal positions that can map to various taxes
on POS.
Furthermore, id adds test to secure that somewhat implicit feature on which
several localisations seem to depend upon.
A typical use case if one tax is not replaced but complemented by another.
**Description of the issue/feature this PR addresses:**
- Taxes can only be replaced in POS.
- Not complemented by a peer tax.
- Behavior not aligned with backend fp mapping.
**Current behavior before PR:**
- Tax cannot be mapped to several taxes (aka: complemented: "to itself and other") on POS
**Desired behavior after PR is merged:**
- Tax can be mapped (aka: complemented) to various taxes on POS
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
@xoe-labs
closesodoo/odoo#26415
The file stock_config_settings_views.xml is not mentioned in the manifest, and
it is wrong as the model `stock.config.settings` which does not exist anymore
closesodoo/odoo#27540
Linked to task 1887993, related to the de-magic-ification of the "admin"
user: currently data files are "executed" as the root user, re-linking
relevant records to the admin user is a PITA (e.g.
97b82ff7c1).
Just executing all demo files as the admin is not feasible (some things
a regular user literally can't do), but the ability to execute entire
data files as a specified user or with specific context keys set, and
furthermore override that at the function/record level, is useful.
This:
* refactors some of convert_xml to prep for the rest
* cleans up and fixes the handling of uid/context to use them in record
and function tags and properly inherit them from data parents
* cleans up some of the rng & conversion code (unused features, dead
code, broken features, …)
closesodoo/odoo#27383
* ir_set and url were accepted by the RNG despite ir_set having been
removed back in 2015 or so and <url> having possibly never existed in
the first place (could not find any reference to an <url> element
outside of sitemap qweb templates)
* <assert> was essentially deprecated/removed in 2015 with the v9
accounting having stopped running account_assert_test.xml, which was
the last file using the tag so far as I can tell. The file itself
remained as dead code until 2018
Use the same pattern as for the envs: a stack of noupdate values pushed
and popped around data nodes.
Avoids re-parsing the same noupdate attribute on every node execution,
and completely removes the need to pass the nearest data node to every
_tag_ function.
* add tests for uid/context on record & function & root nodes (odoo,
data, openerp) "inherited" by record & function
* add rng validation to the test cases to ensure technical
capabilities are matched by validation capabilities (which was not
the case as we could validate nonsense and import stuff which didn't
pass validation or something)
* extact uid/context into its own rng pattern
- add uid support to record validation
- add uid support to root nodes validation
- fix uid support on function validation: was typoed to @id, which
is not used anywhere in function tags loading & makes no sense
as far as I can tell
* replace get_uid/get_context by get_env & reimplement the whole mess:
build a stack of environments from the root nodes (each root node =
one env in the stack, though the exact same env can be present
multiple times if none of the root nodes has a @uid or @context) and
leaves can build upon this "ready made" environment for their own
uses or use it as-is.
As a result, all uid/context should now properly transfer from the
root nodes to the leaves needing them
* fix support for context on functions: was not actually implemented
as the context was not propagated into the old-style API call
* add uid support to record & context is now inherited from env
* add _tag_ methods for root nodes (remove some of the parse special
casing)
* remove unnecessary/useless returns
* remove cr & uid (there's an env)
* remove mode argument from callbacks (redundant and confused with
self.mode)
* try to cleanup menuitem callback a bit
* make second callback param not optional (because it's not)
Purpose: improve understanding of project model as well as their
daily use. This is done by improving tooltips of some fields
according to business logic.
This commit is related to task ID 1885507 and closes PR #27019.
Purpose
=======
display_name is equal to doing name_get()[0][1]
Replacing name_get()[0][1] by display_name could be good for 2 things:
- Uniformization of the code
- Probable optimization if name_get is used inside a for loop on a recordset (as the values will be prefetched and put in the cache).
TaskID: 1849250
closesodoo/odoo#26341
The `account.financial.report` model has been removed, so these reports
are now deprecated. They will be added back in Enterprise.
opw-1891341
closesodoo/odoo#27559
The method button_start begins by an ensure_one() but loop on self too.
This commit removes to loop for cleaner code.
Task : 1850640
closesodoo/odoo#27532
Usecase to reproduce (chrome):
- Create a BoM with float quantity in component
- Print the BoM cost and structure report
When using a type="number" on firefox it is not possible to use a
decimal. However on chrome there is no restriction and a decimal
could be use. It makes senses to be able to work with decimal
(e.g. the UoM is in kg)
It also exists an explicit cast to integer since data are received as
string from the javascript. However since quantity displayed could be
decimal, the cast should be adapted to float.
Closes#27464Fixes#27437closesodoo/odoo#27522
Using `request.env` should be reserved for code that lies outside of
model methods (typically: controllers). Model methods have to use the
appropriate `self.env`.
This particular case caused frequent Python-PostgreSQL undetected
deadlocks during installations of website-related modules in 12.0.
One way to reproduce it was to trigger the installation of both
`website` and `website_form` in a single transaction, with neither
pre-installed.
Installing Apps that depend on both would do the job, such as
`website_sale`, provided that GEOIP is available on the system.
In details:
During installation of `website`, new attachments creation would call
get_current_website (see 602807acdf and
4f6ec1cd2a), using the wrong database
cursor: the one from the request instead of the one for the
installation, as provided by `ir.module.module._button_immediate_function`.
This would acquire database locks on `res.country` and `ir.model` in
the wrong transaction, later blocking alterations to `ir.model` in
the installation transaction, e.g. for website_form's
'website_form_access' column.
This combination of events was possible before 12.0, but more difficult
to reproduce as module installations used to happen with a super-user
account, ignoring ACL checks and therefore not locking `ir.model`.
When creating a warehouse with purchase app installed, it will
traceback since the route_warehouse0_buy is referenced in a wrong
module.
closesodoo/odoo#27523
Fix to commit: a1d6064dcc
Which erroneously put a mass_mailing method in mail,
as mail.mail.statistics is defined in mass_mailing.
Since it does not depend on the records, it been extracted from the
loop.
opw 1890461
closesodoo/odoo#27431
When auth_password_policy is installed, and a field with
`password="True"` is in a res.config.settings (eg. google calendar is
installed) we could have an error caused by deferred not expected in the
res.config.settings _render.
Since the RPC is only needed when the password_policy has been been
defined, this commit do this removing the error that currently happened.
A customization of res.config.settings adding password_meter would still
break settings (but it is currently not done) and will be solved in a
future fix.
closes#27426
Robot Odoo