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
We do not want to allow the change of a related config via a pos.order
and in case the pos.order is done or invoiced we should not be able to
change the user_id anymore and the fiscal position should never ever be
changed after the order is not in draft anymore.
User editable introduced at dca370d7.
Closes#16372
Steps to reproduce:
-Create a product P with a standard price = 0 and its internal category
is in perpetual valuation
-Create a SO with an analytic account and a line with one product P
-Confirm the SO
-Create and validate the invoice
Bug: The delivered qty on the SO was equal to 2 instead of 1 because two
analytic lines are created by function create_analytic_lines with amount=0.
So in function _compute_analytic, the domain was [('so_line', 'in', self.ids), ('amount', '<=', 0.0)]
and it summed the two analytic lines for these two lines. Now analytic lines with amount=0 and linked
to a move line are summed if the they are linked to entries for an account of type "Expenses"(user_type_id).
opw:727302
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
Step to reproduce the bug:
1.Create a product with a customer tax(15%) for a price=100
2.Create a customer invoice with this product
3.Change the amount of the tax to 10(instead of 15)
4.Validate the invoice
5.Click on "Refund invoice"
6.Select the refund method "Modify: create refund, reconcile
and create a new draft invoice"
Bug the new draft invoice has 15 as amount of tax
Now all the taxes from the invoice when preparing the refund in function
_prepare_refund, in this it keeps all the modified taxes.
opw:726491
Before the migration, send_mail() used to be called with an untainted
context but after the API migration it inherited the altered context
with active_test=False which caused subsequent calls to
ir.mail_server#connect() to fetch inactive records.
- Set a google analytic key with the admin user (in the settings for
module website admin)
- Give the right to demo user for website as 'Editor and designer'
- Give the right to demo user for administration as 'settings'
- Login as demo user
- Modify the google analytic key in the settings.
Security restrictions error on (Document type: ir.values, Operation: unlink)
This is a complement of commit 6c89b2bdd2
opw-727807
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
Before the migration, send_mail() used to be called with an untainted
context but after the API migration it inherited the altered context
with active_test=False which caused subsequent calls to
ir.mail_server#connect() to fetch inactive records.
When no email is defiend on the partner, a traceback is raised when
paying with Authorize.net.
The `text` attribute requires a string, not a boolean (`False` in this
case).
opw-728301
When a user belongs to multiple groups, and an ir.rule is applicable for some of
them, the rule is added multiple times in the domain. Just do it once. This
makes the query shorter and easier to debug.
- Create a new account of type "Expenses". Allow the reconciliation and
assign this account on the internal category of a product on both
"Expense account", "Stock Input" and "Stock Output".
- Create a fiscal position to get the following tax behavior: apply two
taxes of the same amount but with opposite sign (+ 21% on the one
side; - 21% on the other side). Activate the tax cash basis feature on
these taxes. It should give, on the same FP:
Tax 21% -> Tax 21%
Tax 21% -> Tax -21%
- Create a journal for the tax cash basis, set it in the company
settings.
- Create a PO (with the previously created FP) for several products
belonging to the same internal category and receive the products. Each
line generates an entry recorded in the stock journal. The expense
account is used in those entries.
- Create the supplier invoice for the PO and validate which also
generates a journal entry with as many line on the expense account as
there are some products on the invoice.
- In the journal items, reconcile the expenses accounts entries
generated by the stock input and the supplier invoice.
It triggers a lot of lines on this expense account for 0 each.
opw-726120
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)
When we set a period for preventive maintenance on an equipment which
has no maintenance team set, the cron cannot create the maintenance
requests.
To fix this issue, the maintenance team is now required when a period is
set on an equipment.
When a PO is created through the resolution of a procurement, the first
supplier of the list is automatically chosen. This is hardcoded and
cannot be extended.
We add a hook so it's possible to customize the selection of the
supplier, for example by selecting the one who offers the best price.
opw-726309
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)
There was a bug with the icon edition when following these steps:
- Open the Media dialog to edit an existing icon
- Hit the "save" button in the dialog without choosing the icon
- The edited icon disappears
This happenned for icons whose original values were aliases of the
related icon. Indeed, following these steps to edit an "fa-facebook-f"
was leaving the icon unchanged as expected but doing it for a
"fa-facebook" icon made the icon disappeared. This is because the
last one is an alias of the first one and that the media dialog was
ignoring aliasies when saving the original value.
opw-725813
When we validate a SO with an MTO product, then an RFQ and a delivery
picking are created. The status of the delivery picking is in state
'confirmed', but should be 'waiting' as the delivery waits for a
specific delivery input.
The problem is caused by the unreserve method, which is called in the
'procurement_jit' module. This method only checks that a move has
ancestors to determine if the move should be in waiting or in confirmed,
which is not the case for our delivery move because the RFQ has not been
validated yet so there is not ancestors yet.
To fix this issue, we check the 'procure_method' of the move, and if it
is in 'make_to_order' we put it in 'waiting' instead of 'confirmed'.
We also fixed the function recalculate_move_state that could cause the
same problem.
To deduct the fiscal position, we should use the shipping partner.
The field `partner_shipping_id` is defined in the sale module.
Thus, we should choose this partner if the module sale is installed and if this field is set, or fallback to the original partner instead
Aaron Bohy