Commit Graph
9 Commits
Author SHA1 Message Date
Xavier Morel bdc9d9d369 [FIX] core; base: lots of docstrings
* add configuration for `flake8[flake8-rst-docstring]`
* enable docstring-related checks
* fix invalid docstrings in odoo's core & `base`
* fix a few more bits (mostly missing or incorrect `:param:` info
  fields) are out of scope for the lint but my editor catches

closes odoo/odoo#74604

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
2021-12-09 14:36:58 +00:00
Xavier Morel 1ecb0641ef [FIX] core: calling read_group / name_search over xmlrpc
Also non-browser jsonrpc (as it goes through a similar process): for
internal performance reasons, name_search and read_group have been
converted to a *lazy* name_get, so the "display name" is not
unnecessarily computed.

However this is an issue for the RPC endpoints (/xmlrpc and /jsonrpc)
as they have no support for `lazy` and thus tend to blow up and / or
do the wrong thing when trying to output a lazy:

* xmlrpc has no way to handle lazy at all and straight blows up
* jsonrpc falls back to `json_default` so they try to stringify the
  lazy, which might have worked except

*Problematically* both endpoints delegate the actual work to
`dispatch_rpc` which handles dispatching between various services and
ultimately creates a *new* cursor before calling model
methods (`object` service and `execute`/`execute_kw`).

This means by the time the result is serialized to be output, the
lazy's cursor has long been closed, and thus any access to an
unevaluated `lazy` errors out when trying to fetch the underlying
item.

This also means we can't just add a hook to serialize the lazy
in the xmlrpc marshaller, though we do have to do that. We *also* (for
both xmlrpc and jsonrpc) have to force evluation of lazy values before
our cursor is closed, meaning it has to be done right after the method
is invoked, iterating the entire response.

Related to task 2170343

closes odoo/odoo#49286

X-original-commit: e2b5a359c1d5eccbe725c1c3169b4130d7bca49b
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
2020-04-09 09:06:34 +00:00
mreficent 355a5dfc36 [IMP] *: fix typos in comments
closes odoo/odoo#35404

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
2019-08-07 10:28:33 +00:00
jem-odoo 86f5b6a926 [IMP] tools: get_timedelta helper
This commit introduces a small helper to return
a timedelta given a quantity and a time unit (day, hour,
month, ...)

Task-2024216

closes odoo/odoo#34576

Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
2019-07-04 08:19:08 +00:00
Nicolas Martinelli 1e558bc79a [FIX] tools: February 28th
- Set your fiscal year end date to 28th February
- Run the P&L a year before a leap year, e.g. anytime between March 1st
  and December 31st 2019.
- Select 'Last Financial Year'

The dates are set from 2019-03-01 to 2019-02-28.

There are actually 2 bugs. The one solved here is the following
inconsistency:

```
current_date = type(date)(2019, 4, 3)
date_utils.get_fiscal_year(current_date, day=28, month=2)
'date_from': datetime.date(2019, 3, 1), 'date_to': datetime.date(2020, 2, 28)

current_date = type(date)(2020, 2, 28)
date_utils.get_fiscal_year(current_date, day=28, month=2)
{'date_from': datetime.date(2019, 3, 1), 'date_to': datetime.date(2020, 2, 29)}
```

Both should return `'date_to': datetime.date(2020, 2, 29)`. This implies
that the period is recognized as `custom`, which is affected by the bug
solved in PR https://github.com/odoo/enterprise/pull/4006

opw-1949628

closes odoo/odoo#32366

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
2019-04-03 09:29:57 +00:00
Laurent Smet 67d3d30cf2 [FIX] tools/date_utils: Fix get_fiscal_year with leap years
Suppose calling get_fiscal_year(date, day=29, month=2) with date(year=2017, month=2, day=28)

The computation steps are:
date_from = date(year=2017, month=2, day=28) - 1 year = date(year=2016, month=2, day=28)
date_from = date_from + 1 day = date(year=2016, month=2, day=29)

It's incorrect because the value of date_from must be date(year=2016, month=3, day=1)

closes odoo/odoo#29416
2019-01-03 08:30:31 +00:00
Francois Volral 4a40db2097 [IMP] orm: add support to fill temporal holes (read_group)
This commit add an extra parameter 'fill_temporal' to read_group which allows
the orm to add missing groups for date intervals. This is useful for charts.

Suppose that we are in a use case where data are grouped by a date fields
(typically months but it could be another interval) and displayed in a Bar Chart
or a Line Char.
Let's says a request has to group records by month for August, September
and ...December.  If we don't changed anything, we would get a Bar Chart
looking like this :
                                        ___
                              ___      |   |
                             |   |     |   |
                             |   | ___ |   |
                             |   ||   ||   |
                             |___||___||___|
                              Aug  Sep  D
December follows directly after September, it can be unintuitive for the
user, so we change that. We add some fake records for each missing months
between the earliest and the lastest date of the result
                                             ___
                         ___                |   |
                        |   |               |   |
                        |   | ___           |   |
                        |   ||   |          |   |
                        |___||___| ___  ___ |___|
                         Aug  Sep  Oct  Nov  Dec

This commit is part of task #1835644
2018-08-10 17:21:17 +02:00
Raphael Collet 960360afe4 [REF] *: use native date/datetime for Date/Datetime fields
From this commit onwards, Date fields will return datetime.date objects and Datetime fields will return datetime.datetime objects, this implies a number of things that are clearly explained both in the ORM API for master.

This commit also introduces a number of helper functions for dates and datetimes that are exposed in tools.date_utils and fields.Date[time], explained in the documentation as well.

Task-ID: 47189
2018-08-06 14:37:19 +02:00
Laurent Smet dfde326e75 [IMP] account: add account.fiscalyear model
In order to improve the fiscal year management, we allow the user to define custom fiscal years
    using the account.fiscalyear model.

Was task: https://www.odoo.com/web#id=39878&view_type=form&model=project.task&menu_id=
Was PR #20936
2018-05-30 18:28:13 +02:00