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)
Allow to configure the bank statement import mode from kanban
When doing a manual journal entry, don't show the maturity date
Removing Issued total, using credit instead (less code, more
useful to have due amounts, instead of overdue)
Creating a bank, set a name 'BofA Current' and an
account number (that way, the account.account is based
on name)
Settings Wizard & menus: better sentences
Statement CSV Import: installed by default (it
does not add any menu)
remove use_in_payment: complex field, only
used for a default value
Small code cleanup
[IMP] sale: moving order date to secondary tab (strange on a quotation)
This icon allows to control what types of notifications you want to receive.
That an icon typically used for "notifications" is better than an icon
typically used for "reminders" and "alarms". There is the risk of a wrong
expectation because reminders and alarms have a notion of time associated to
them: reminders in the future or alarms in the future at a given time. In the
case of a follow, there is no "future time" concept, whereas there is a
notification concept. It makes even more sense when we look at the placement of
this icon on the right side of the label "Following".
Closes#16170
Moving main menu item 'Planning' from mrp_workorder to mrp.
We put this main menu in the module mrp to add items in it in module
mrp_workorder and mrp_mps without adding a dependency of mrp_workorder
to mrp_mps
This commit introduces a new widget specific to employees. It is used
to display an org chart centered on the current displayed employee.
Two levels of managers as well as subordinates are displayed.
It is contained in its own module and its installation is available from
hr settings.
Thanks to Stefano Rigano <sri@odoo.com> (@stefanorigano) for design and UX
implementation.
No technical or functional change. Only reorganizing fields to better
understand the model. Future commits will change a few fields in this
model and this commit prepares it by classifying a bit them.
Currently, if you create a manufacturing order, you can select
all the product that have a BOM. But some product have BOM that
are archived or that can't be manufactured.
This commit add a constraint in the domain for product field.
The constraint ensure that BOM are not archived nor phantom BOM.
It is confusing to see an existing payment transaction on an SO next to its
total even though it doesn't necessarily mean that the SO is paid because the
transaction could have failed. Additionally, if there are several tentative
transactions for one SO, only the latest one is accessible through this m2o.
Closes#16128
When the module sale_stock is installed, the MTO route is now by default
available on sale order lines.
We also remove the ability to create routes from sale order lines, as a
salesman will never have to configure new stock routings.
If a record is tagged with no update, the translations must not be replaced,
even if the "overwrite translation" checkbox is checked.
If somebody renames a noupdate and translated record, updating the translations
must keep the new translations.
Closes#14768
When posting journal entries for an hr.expense.sheet with several expense lines
(by clicking on the button "Post journal entries"), all the account move lines
created for the same sheet must be linked to the same account move because
the model hr.expense.sheet has just a field "account_move_id" to access all the entries
(by clicking on button "Accounting Entries")
This commit reverts f97eb0ac2b
opw:715523,709930,725798,716239
The domain field needs space to be rendered. Even with its "in_dialog"
option activated, the readonly representation can take some space.
If there is not enough space, it will be a mess to read it and the
"-> x records" button can also overflow the "Add filter" button.
This commit makes the field to be rendered as a "block", which fixes
the problem in all current cases.
In the kanban view, if the default_group_by is a many2one, it's possible
to quick create a new column (which will create a new record in the
relation model).
However, the field `name` was hardcoded during the creation, which means
that a custom model with `x_name` couldn't be correctly created.
This commit allows it by using `name_create` instead.
The alert box was flickering if empty: at each click on the status
button, the box was appearing and disappearing quickly. This is probably
due to a bug in the form view that do not wait for the evaluation of the
attrs. This bug is fixed in the new views, but only if the attrs is
fixed. Indeed, as the attrs condition is
attrs="{'invisible': [('production_messages', '=', False)]}"
the field was never set to False. This is because the compute method was
doing
workorder.production_messages = "<br/>".join(messages)
So, even if `messages` was empty, production_messages will be set to ''.
In [1]: 'aaa'.join([])
Out[1]: ''
So we fix the condition to set False to the field if the string is
empty.
In [6]: 'aaa'.join([]) or False
Out[6]: False
A 50 px height was hardcoded, so if you have more than 2 or 3 messages
they were displayed outside of the messages box. We remove this
hardcoded height and it looks better.
When there is a lot of texts to display in a tooltip, it will overflow
the viewport vertically as the max-width of the tooltip is set at 200px
(bootstrap default). This commit increases the max-width to the
viewport full-width.
opw-725804
Xavier Morel