Hopefully, this commit makes it consistent. There were two problems
with the previous implementation:
- Contexts from field attr (if asked thanks to the options.field
parameter) were not evaluated with the right evaluation ctx
- "raw" contexts (from parent) had to be evaluated with another
evaluation context
Also rename the options.field parameter to options.fieldName.
FieldMany2One was declared as an extension of AbstractRelationalField
AND mixins.ServicesMixin... which was wrong since the mixin is already
added to the Widget class. This caused the extension of the mixin
methods to be lost.
We replace a bunch of formatting and parsing functions by an object
(parse or format) which can be used to dispatch on the correct type. It
allows us to remove the format_field and parse_field functions.
Also, we camelcase our new code and add some comments.
The field_utils date method have been modified recently, and the idea
behind those changes is that the BasicModel keeps at all time a moment
instance as its internal representation of a date or datetime.
But the parse and format methods did not properly support unset dates,
so we have to slighlty change them to support the case where their values is
not set.
Before this commit, the BasicModel didn't parse the dates when loading
data for a list. But the rest of the web client assumes that data is
properly parsed into their correct types, so a moment instance for date
and datetime.
Also, uppercase field_utils and properly reorder imports
Until now, those tests failed if the window did not have the focus. We
solve the issue with 2 different fixes:
* instead of checking that the focus property is set, we can check the
activeElement instead, it seems to work.
* instead of calling the focus method, in some tests, we can trigger a
* 'focusin' event. I don't know why this works, but it does.
Note that this might make the tests work in phantomjs
Before this commit, the odoo web client used strings to represent dates.
Now, the date is parsed into a moment object when the value is read from the
server side. The widget formats the object to display the value. When the
widget value changes, the value is parsed to a moment object. The value is
automatically formatted to server value in ajax calls (toJSON method).
Commit cef659783514f8935cc46a496f71063d022e8dac changed the way domains
are computed but forgot to change the values representation used by the
Kanban view. This commit fixes that and adds tests to make sure it does
not happen again.
Before this commit, modifiers were partially processed by the mock
server. Now, it should be a better approximation of what the server
does:
- Take the invisible/readonly/required from "attrs"
- Merge invisible with the "states" ([["state", "not in", states]])
- Override if invisible/readonly/required attribute is present
+ Adapt some tests
With our new views, we broke almost all JS code, including the
reconciliation widget, which was (and still is) dependant on the field
widget. With this commit, we rewrite and simplify the reconciliation
code. We also add some tests, to help with the maintenance.
Work done by CHM
This commit introduce a full redesign of all JS views. We started
basically from scratch. The goal was to unify all the various views
under a common framework, to make them testable, to make then usable in
different conditions (in studio, or in the frontend), and to make our
lives easier.
Some important points are:
- we introduced new coding guidelines (camelCase, 80 chars width, ...)
- we have a brand new testing framework (still QUnit based)
- kanban view moved to the web addon
- calendar view (formerly web_calender) moved to web as well
- the tree view was removed
- all new code should be documented
We hope that this code is the start of a new era for the Odoo web
client, we want to have a high quality codebase, well documented, well
tested, well designed.
Work done by the framework team: mostly aab, ged, chm, dmo, qsm
For readability and coherence, in Python 3 the prefix for octal
literal becomes ``0o`` (rather than just ``0``). This new version was
also added to Python 2 as of 2.6.
Convert all octal literals in file-manipulation code (POSIX ACL), and
fix a few integers which were unwittingly octal.
(lib2to3.fixes.fix_numliterals)
While sometimes convenient, the ability to unpack tuple parameters (to
lambdas and functions) was removed from Python 3. Either use the tuple
directly or unpack it in the function body.
(lib2to3.fixes.fix_tuple_params)
Redundant with `in` and removed from Python 3.
Removed odd, old and long-unused UpdatableDict (which defines and uses
has_key) and UpdatableStr (which was nearby and caught in the blast),
validated with al.
(lib2to3.fixes.fix_has_key)
* `<>` was removed and should be replaced by
`!=` (lib2to3.fixes.fix_ne)
* `\`` was removed and should be replaced by either `repr()` or the
`%r` format string modifier (lib2to3.fixes.fix_repr followed by
hand-rolled edition to replace concatenation)
For example, we had in the past fields added on account.account but not on account.account.template. The purpose of the new test is to detect such oversight (force developpers to explicitly name exceptions in the test).
Was PR #16012
task ID: 31488
Previously availability of meta-information (failing constraint,
impacted table and column, …) in pg errors (e.g. constraint check
failure) was limited and only available through formatted error
messages, which could be localised (by PG itself) so not did getting
that information require string extraction it was brittle in the face of
localised instances.
Postgres 9.3 adds this meta-information to error diagnostic data
(`PQresultErrorField`), allowing easy programmatic access to it.
Psycopg2 [added a Diagnostic
object](http://initd.org/psycopg/docs/extensions.html#psycopg2.extensions.Diagnostics)
around the time pg9.3 was itself released.
Assuming Odoo now requires pg >= 9.3 we can remove the old string
munging extraction for diagnostic.
* funny story, the handling of 23505 didn't actually work because
"duplicate key value violates unique constraint" is a literal part
of the error message, I'd misunderstood "value" as a field name
because my test model's field was called "value". Makes sense too
since you can set UNIQUE constraints on multiple fields (and UNIQUE
indices on expressions)
* for both errors, it should be possible to use the table_name or
constraint metadata to provide messages about sub-model issues (a
constraint on an m2o), but that's not currently handled
Fixes#15323
Aged receivable/payable was using create_date of account_partial_reconcile to decide if a partner needs to be shown at a given date or not.
While it was not wrong, our decision to use the create_date was based on the fact that we wanted to be able to render the exact same report we had at a past date, so a the date of the reconciliation would be important... but since the unreconciliation was not forbidden it wasn't really the case.
Moreover, in some case where reconciliation is not at the same time the payment is recorded, this choice
- was confusing people about results given by the aged receivable/payable report.
- was confusing people about the 'Paid on...' line in the payment widget on the invoice, as they would see there a date unused by the system (although they would have liked too)
This was discussed in opw 31844. Was PR #16016
Since we only uses date fields in accounting, it does not have any sense to have a datetime for currency rate:
- it is error prone for the users as the timezone they're in will affect the rate (and possibly take yesterday's rate).
- it involved the possibility to create several rates per day, which was not fully supported and might give undeterministic results (so we also add a constraint in order to only have one rate per day)
qsm-odoo