Before this commit, conversion between worked hours and days in
resource_calendar_attendance was calculated but in reality there is no
unambigous way to do this. Eg in Belgium the morning working period is
4 hours, the one in the afternoon is 3 hours 36 minutes, while both of
them are still counted as half days.
To mediate this, the duration in days is explicitely added to
resource.calendar.attendance, with sensible default being provided
(half a day for morning and afternoon periods, 0 for lunch).
task-3131517
Part-of: odoo/odoo#133145
Fixes a large number of cases where strings are translated then
formatted, instead of letting `_()` do the formatting internally,
which allows it to recover from incorrect translations (missing,
broken, or extra placeholders).
Also
- removes translation markers entirely when there's nothing to
translate e.g. `_("%s - %s")` is not useful
- fixes a few messes which lead to only partial translatability
(DRY is generally a bad idea when translations are involved, even
more so when you don't make the variable part translatable)
- fixes a few nearby issues noticed at the same time
- replaces a few `"%s"` by `%r`, which should automatically quote
strings relatively appropriately
- fixes translated strings which use `\` to escape a newline (in order
to fill-paragraph): `\` escapes only the newline, if the
continuation string is indented this results in a bunch of spaces
ending in the string to translate, which is pretty garbage for the
translator, using implicit concatenation works much better
Note: some of the updates revert f-string parameters to %, because
babel (2.9) apparently has trouble with f-strings and blows up trying
to extract them.
Not in scope:
Helping translators fix translatable strings e.g. any translation
string with more than one placeholder probably should use keyword
placeholders
- Provides more context / data to the translator to make sense of the
sentence.
- Allows reordering the translated terms, which can be necessary
depending on the sentence and language.
closesodoo/odoo#139314
Related: odoo/enterprise#49311
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
*:
- hr_holidays
- resource
- website_slides
Before this commit, the populate files for the listed modules
were calling the random python library.
As we don't want non-deterministic populate, this import has
been changed to use the odoo Random tool which allows deterministic
randomization through seeds.
This commit also changes the way populate works for leaves in hr_holidays
so that they fit the current way of defining leaves.
closesodoo/odoo#139150
Related: odoo/enterprise#49162
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Before this commit, owl was in the linter's accepted global variables.
This allowed direct access to owl global object.
For instance, to use xml from owl, you could do :
`const { xml } = owl;`
or you could use it directly:
`owl.xml`
Now, owl is not accepted on linter's global variables anymore, so to
import xml, now you need to use a proper import:
`import { xml } from "@odoo/owl";`
task-id 3498859
closesodoo/odoo#137517
Related: odoo/enterprise#48364
Related: odoo/design-themes#709
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
The idea of current date_{from,to} computations is as follows:
The user selects the request_date_{from,end} (and optionally
request_hour_{from,to} and these inputs are then processed into a
date_{to,from}, taking into account the type of leave, the work schedule
(resource_calendar) and time zone (since date_{to,from} are saved in UTC
while the request_dates are stored in the user's timezone.
However, in practice this computation is very messy, resulting in
date_{to,from} needing to be specified in all demo data and test cases,
even though it should be derived from the request dates. Various
superfluous or poorly named methods also exist in this flow
(eg _get_start_or_end_from_attendance which really performs a timezone
conversion, the logic of which resource calendar to use is scattered
across the whole model etc).
date_{to,from} are used many times as inputs throughout the code, with
code being present te inverse compute request_date_{from,to} from these
values. However in reality this is not possible to do consistently.
Therefore with this commit, we restore request_date_{from,to} as the
sole possible inputs, with date_{from,to} being derived from them. In
addition, the timezone and resource calendar are consolidated into their
own fields, with a single computation method computing them.
task-3081565
Part-of: odoo/odoo#119317
Before this commit, the group by in the gantt view of project didn't
allow the user to find records for which there were not scheduled tasks.
For example, if a Sale Order didn't have a scheduled task, when grouping
by Sale Order, the latter was not displayed. And searching for its name
was not displaying it either.
After this commit, when a user is searching for a sale order, even if
the latter does not have any scheduled task, it is displayed in order to
facilitate the scheduling of new tasks.
In order to do so, a group expand on sale_order_id for the project.task
model have been introduced.
closesodoo/odoo#121819
Taskid: 3251630
Related: odoo/enterprise#41257
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce:
-------------------
- Go to Working Time and modify a calendar using "Switch to 2 weeks calendar"
(not the default company calendar);
- In the Employees App settings, change the "Company Working Hours"
to the edited calendar;
- Create a new company.
Issue:
------
We have the error: "Attendances can't overlap.".
Cause:
------
When we create a company, we will use the `_default_get` method
to get the default values for the `attendance_ids`.
So we will copy the attendances from the current company,
but we won't copy the `week_type` value.
In addition, the `two_weeks_calendar` value will be `False`.
As a result, overlaps will be checked as for a one-week calendar.
This will trigger the error.
Solution:
---------
If you want to get the current company's attendances by default,
make sure it uses a one-week calendar.
If this is not the case, we take the default (hardcoded) attendances.
Note:
-----
Since the commit 292508e8a749bf32e40995454da6122cd3c1df77,
it was no longer possible to modify a company's default calendar.
It is reverted.
With this FIX, this is now possible.
opw-3446789
closesodoo/odoo#131872
X-original-commit: 22c12db1f009686fa4c3861c398ba178b2785ead
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
As all the templates are now imported in the owl app, there is not need
anymore to specify the owl="1" attribute in the templates.
Part of task~3443861
Part-of: odoo/odoo#130467
-Display the state of a time off that you open from the dashboard
-Rename Stress Days into "Mandatory Days"
-My Allocations
Remove "Employee" from the Group By
Replace filter `Current Year` with `Currently Valid`.
-My Time Off
-Remove Employees from list view and kanban view
-Create an allocation / allocation request form
- Create an allocation ux : employee side- compute the name of the allocation.
- Make field `allocation_type` invisible if there is no active accrual plan in the database.
-Accruals
-Add an "archive" in the action menu of the accrual plan.
-Show Employee button in the form view of the Accrual Plan.
-Renamed stress day into the mandatory days.
-Renamed string of the menu Approval into the Management.
-Remove two legends in the time-off Dashboard
- Public Holiday
- Mandatory Day
task-3084232
closesodoo/odoo#116472
Related: odoo/enterprise#40576
Related: odoo/upgrade#4472
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
In some methods, like group expand methods, it is not uncommon to
transform a domain designed for model A to search records from another
model B. In general this transformation requires two operations:
- Rename some fields in the domain
- Remove leaves from the domain that relate to fields not existing in
model B
The current function filter_domain_leaf allows to realize this second
operation. It currently relies on a recursive implementation with a
complexity of order O(n²).
This commit introduces a re-writing of the function filter_domain_leaf
that:
1. Changes the recursion based implementation to an explicit stack
implementation
2. Introduces a field mapping dictionary as argument
The explicit stack implementation allows to avoid stack overflow when
working with long domains. The complexity order is also improved to O(n)
instead of O(n²) which leads to performance gain. For a domain length of
~100 elements, the gain (timewise) is reaching 50%. It is >95% for
domain length over 10 000 elements.
The field mapping dictionary allows to avoid pre-filtering of domains
when using filter_domain_leaf. In cases where it is used, the domain
then just has to be browsed once in the filter_domain_leaf function.
task-3299357
closesodoo/odoo#120834
Related: odoo/enterprise#40847
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
PURPOSE
=======
When you start a new trial of an app without demo data, you
want to have everything perfect and ready for your own configuration
closesodoo/odoo#122308
Taskid: 3328654
Related: odoo/enterprise#41423
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This issue only occurs on Firefox because ´has´ is not supported
and the following rule is not applied:
https://github.com/odoo/odoo/commit/2cd0106e63785dd34553c2b4747d72b93b9a7afd
Anyway, there is an existing css rule that is applied if the field
class is correclty added.
Steps to reproduce:
- Open Sale
- Add some content in the sale order line
opw-3201461
opw-3285854
opw-3266130
opw-3244581
closesodoo/odoo#121979
X-original-commit: add1df806157c074fd1a3224d1d8bdf1922481fb
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
If applied, this commit will solve the external id issue of the base admin user.
Before this commit:
==========================
When we delete the admin user (base.admin_user) and try to login with a new user
or try to write in a new user, this error will come.
After this commit:
===========================
The issue will be resolved after this commit and authorize new users without
any errors.
sentry - 3973828005
see - https://tinyurl.com/2jm772jmclosesodoo/odoo#118681
X-original-commit: 567027b4d4e3efdbbabab3a7a3c5e090df51dbf8
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
To avoid any misconfiguration, only the current companies' calendars are
shown and not all the resource.calendar.
task-3254874
closesodoo/odoo#117663
Related: odoo/enterprise#39311
Signed-off-by: Kevin Baptiste <kba@odoo.com>
date_to is set to date_from 23:59:59 when date_from is set, because 99% of the time a public holiday
is for one day. date_to can be adjusted if necessary.
task 3162355
closesodoo/odoo#115688
Signed-off-by: Kevin Baptiste <kba@odoo.com>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
In Working Times, click on "SWITCH TO 2 WEEKS CALENDAR"
for the default calendar used by the company.
Issue:
A ValidationError appears: 'Attendances can't overlap.'
Cause:
To create a two-week schedule, by default,
we will use attendances provided for the company's default schedule.
When we want to switch from a one-week schedule to a two-week schedule,
we first delete the attendances from the schedule to be modified.
However, if this schedule is the company's default schedule,
it will no longer have the default attendances
that we must use to build the two-week schedule.
So we end up with the two "fictitious" attendances
that are used to delimit the two weeks.
With only these two attendances, the constraint of not having
two overlapping attendances is not respected
(because the two attendances created will be modified
to belong to the same week).
Solution:
Check that the calendar to be modified
is not the default calendar used by the company.
opw-3127337
closesodoo/odoo#112912
X-original-commit: 2f56ffbc2f1d3a2afbf51a859a5a5730af06fd6f
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit, the field's description was stored on the
component and this component was then registered.
Now, an object describing the field is used on registration the same way
as it is done for views since https://github.com/odoo/odoo/commit/b828cfc72c587d0b73fcc5459695705640437671.
This split the component's description (props, template, ...) of
the field's description (displayName, supportedTypes, ...) and makes
it clearer.
closesodoo/odoo#112498
Task: 3171520
Related: odoo/enterprise#37105
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Some changes were made to the default/demo/test data to be more
consistent:
- Duplicates of "Paid Time Off" time off types are consolidated into
one type (inluding year specific versions, ig "Paid Time Off 2019"
- Annual Time Off is renamed back to Paid Time Off (both for the
work entry type as the time off type) to be consistent everywhere.
- All mentions of years in work entry types and time off types have
been removed, as this is no longer relevant with the new allocation
rules.
- Time off types in the default data have been explicitely made
company agnostic, in order for them to be available to all companies
and not just the one company that was select when installing
hr_holidays. This was already the case for the be_payroll data, but
not for the standard hr_holidays ones.
- Various small cosmetic / functional fixes and simplifications
(eg deduplication of data)
- expense_other_input has been made country agnostic, in order for it
to be available in all countries.
task-2978513
closesodoo/odoo#112208
X-original-commit: dcc8bbf
Related: odoo/enterprise#36819
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit removes the legacy implementation of the form, kanban
and list views. It also removes the legacy view widget registry,
and all legacy widgets it contained. The legacy field registry
couldn't be removed yet as some fields are still used (e.g. in
client actions: FieldMany2One, FieldMany2ManyTags...), and
sometimes accessed from that registry (e.g. uom service). More
clean up will come later. Note that all tests using legacy views
have thus been removed, even though the tested feature might still
remain (e.g. FieldMany2One tests have been removed, but that field
is still there). However, those features are deprecated and
unlikely to evolve. They should be removed in the next saas, or the
one after.
Finally, this commit also removes the legacy view dialogs.
Task 3168640
Part-of: odoo/odoo#111809
Purpose
=======
Add a new type on the working schedule, adding "Lunch" to Morning and Afternoon. It's mandatory,
because, if you don't do that, you can't assume the difference between a time that should be
recorded as extra hours and a time that should not be counted because it's lunch time.
A company is not another, so to be clear, they will define what are the imposed lunch time
where the employee is not paid during the week.
Specification
=============
Lunch between Morning and Afternoon
When a time period is under Lunch :
- There is no working entry generated for that period of time.
- If you work before the lunch time and after it, it's not considered as extra time.
- The employee is not paid for the Lunch time.
TaskID: 3102363
- Automatically compute the average number of hours per day on
resource.calendar;
- Don't allow to change the working hours of an employee when they have
a current running contract;
- Seperate smart buttons on resources to distinguish Material / Human.
task-3102517
closesodoo/odoo#109768
Related: odoo/enterprise#35718
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Since the conversion of the list view to owl, the relative field size
has not been reimplemented. We have decided not to support it anymore.
So we will remove all its uses.
The relative width consists in adding a width attribute with a
value. This value corresponds to the weight of the field, the higher
it is, the more space the field will take. This size is only used when
the list is empty.
Example of this:
<tree>
<field ... width="2">
<field ... width="1">
</tree>
The first field will take 2x more space than the first one when the list
is empty.
closesodoo/odoo#110382
Related: odoo/documentation#3375
Related: odoo/enterprise#36020
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The function remove_domain_leaf is currently used for project burdown
chart. Due to an increasing need of such a function in multiple modules
for various functional cases, it has been decided to:
- Move this function in 'resource' that is imported in all the modules
where this function is needed.
- Implement extensive unit test to ensure that it address corner cases.
- Refactor the function to address the corner cases it was not
addressing until now.
The refactored function 'filter_domain_leaf' is used to transform a
given domain to a new domain using only the leaves that verify a given
check (more precisely, the leaves whose first element verify this check). To perform this transformation, the leaves that do not verify
this check are considered as undetermined. All the logical operators
dealing with undetermined leaves are ignored, which means:
- AND(leaf, ?) = leaf
- OR(leaf, ?) = leaf
- AND(? , ?) = ?
- OR(?, ?) = ?
- NOT(?) = ?
If the result of the operation is undetermined, it is returned as an
empty domain ([]).
closesodoo/odoo#105470
Related: odoo/enterprise#33657
Related: odoo/upgrade#4221
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Stepts to reproduce:
Go to Time-off app > configuration > Public Holidays.
Try to create a new holiday and select working hours.
Issue:
It will show up all the working hours available for all companies even
if we are not in that company at the moment.
Solution:
We need to take into account the company for this field in order to only
show the working hours available for this specific company. I've added
to the field the `domain="[('company_id', 'in', [company_id, False])]"`
in order to follow the same behavior as next versions.
This issue affects 15.0 and saas-15.2
opw-3068827
closesodoo/odoo#106981
X-original-commit: 65f2861bf2728a7f9f991c47edc77fc557dfde14
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, when the user is just a planning user without any
access to the Employees and Contracts apps. A traceback is occurred
saying the user cannot access to the `hr.contract` model.
This commit adds a `sudo` in `_get_valid_work_interval` method to get
the resource calendar of resources within a interval (the one of the
gantt view). This sudo does not give any recordset in sudo since the
`_get_calendars_validity_within_period` method return a dict with
resource_id as keys and the intervals valid according the resource
calendar for the interval.
closesodoo/odoo#106138
X-original-commit: 0bf271eb41cd1622d8ba4c1882a8ea94f1bdb463
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Purpose
=======
Onchange methods are executed in "edit-mode", so you need to save to get the definitive
values saved on the DB, but if you do a write on it, that changes are immediately saved
to the DB, so if you discard the changes on UI, you will have inconsistent data. That's
why you have to do update instead, that only modifies the temporary dataset.
Courtesy of https://github.com/OCA/pylint-odoo/issues/356closesodoo/odoo#104539
Taskid: 3046426
X-original-commit: 5f18f068e62ba6cf6296c5f818b2cdfabed1fdfb
Related: odoo/enterprise#33409
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The "Switch to 1 or 2 weeks calendar" are breaking the layout by
being placed just before attendances_ids on the Working Hours sheet.
With this commit, the buttons are moved in the header of the form.
task-2996235
closesodoo/odoo#102711
X-original-commit: e81e03e6511c4d975bd7da4748f11747faf38251
Related: odoo/enterprise#32539
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: phwa-odoo <phwa@odoo.com>
`activeActions` is a set of boolean values determining what actions
(i.e. 'create', 'delete', etc.) can be performed on the current view or
subview (x2many).
Before this commit, the x2many fields used a different naming convention
than the one set on the views (e.g. 'canCreate' instead of 'create').
This caused mismatches when subviews would try to rely on the parent
view `activeActions` to define their own. This also introduced a bad
design where the "type" of `activeActions` would be determined by that
same mismatch.
Another issue was that the list renderer did not always check for the
existence of activeFields in its props, despite defining them as
optional.
This commit unifies the names of the active actions accross views and
x2many fields, while adding a "type" property to it s.t. its owner
can determine what context it finds itself in.
closesodoo/odoo#102115
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
The goal of this task is to review the copywriting of the tooltips
because some of them are not correct in English and others are not
valid anymore. This is also a good opportunity to make an inventory
of the tooltips we have and to add some that could be missing.
task-2860991
closesodoo/odoo#102179
X-original-commit: 5e4cf8f9f6a4372f45aa04a5965f8073bb4ea68a
Related: odoo/enterprise#32298
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Co-authored-by: Mahendra Barad <mba@odoo.com>, Prakash Prajapati <ppr@odoo.com>
Louis (wil)