When an addon has an invalid version but is not installable,
there is no need to error out. This situation typically happens
when unmigrated modules are present in the addons path.
closesodoo/odoo#157657
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
This allows launching Odoo with "python -m odoo".
This manner of launching python applications is now widespread.
In particular it makes it easier to configure an IDE debugger to run with the correct python version.
closesodoo/odoo#81864
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
By searching on account.move.line parent_state instead
of move_id.state, we avoid a join in many circumstances
and allow the database to benefit on an index on
company_id+parent_state to optimize several
queries, such as the default filter on the Journal Items
menu which shows posted items.
closesodoo/odoo#82504
X-original-commit: ef61db1cf8ebf1ab11e5dfdd439256d0607edba8
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Florian Gilbert <flg@odoo.com>
account.move.line has a journal_id field that is related on move_id.journal_id.
By searching on journal_id we avoid a useless join,
offering more room for database query optimizations.
closesodoo/odoo#81856
X-original-commit: 2741f245f8a47e971309e97128662f1863329e45
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Florian Gilbert <flg@odoo.com>
By searching on account.move.line parent_state instead
of move_id.state, we avoid a join in many circumstances
and allow the database to benefit on an index on
company_id+parent_state to optimize several
queries, such as the default filter on the Journal Items
menu which shows posted items.
closesodoo/odoo#80815
X-original-commit: c2a72c268e6a28d7448b6dbf96fed4e36d24b3fe
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
When a custom module is in 'to upgrade' state,
and the code has a dependency that is not yet
installed, Odoo refuses to upgrade it, and
says the new dependency is unmet.
This commit fixes this by also calling button_upgrade() in this situation,
and not only for modules in 'installed' state.
This situation arises in a version migration scenario. Custom modules are
in 'to upgrade' state after migration.
If one of these custom modules has a new dependency
after migration, it refuses to upgrade.
closesodoo/odoo#72942
X-original-commit: d5ffe0159ada953985a23c29e36763599bd10ed9
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
When an installed module is not installable, we don't want
to check its dependencies because they may not be available.
Erroring out on such dependencies is not needed because
the module will not be loaded anyway. On the contrary, such
errors prevent starting a database which would otherwise
function normally.
Such errors occur when doing incremental migrations where
it happen that addons are installed (from the previous version)
but not migrated yet and therefore not installable.
When we migrate lower level dependencies Odoo marks
higher level addons as "to upgrade" even if they are not installable.
That is usually harmless, except when such addons have
dependencies that are themselve not available.
This PR fixes that.
closesodoo/odoo#73206
X-original-commit: a11e8a32883b0d0deaeb2497daa585eb3d3c686e
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Before 1721ec1363 and fdc4ef97c9, Odoo did work fine when the
user had another default schema than 'public'.
This commit restores this behaviour by searching
for existing objects in the user's current schema,
which is the first in the schema search path and
the one used when no schema is specified when
creating objects.
closesodoo/odoo#68144
X-original-commit: 223781b34afacd1c0c5674d395cece6d472b048c
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Since there are message_post overrides using the form `def message_post(self,
**kwargs)` in some modules, this method is intended to be invoked with keyword
arguments only.
This commit enforces this behavior. Calls such as `message_post("body")` will
fail regardless of which addon is installed, forcing users to use
`message_post(body="body")`.
It also fixes a message_post override in hr, and applies the same
mechanism to message_notify, and _message_log.
closesodoo/odoo#33306
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Use pkg_resources.get_distribution() to check if python external
dependencies are installed, instead of trying an import.
The import test is preserved as a backwards compatibility measure.
This better expresses which python distribution needs to be installed
from PyPI and allows declaring a minimum supported version using PEP 440
version specifiers.
Closes#25541closesodoo/odoo#25549
Signed-off-by: Christophe Simonis <chs@odoo.com>
Payment journals have an option to keep moves unposted until bank statement
reconciliation.
When cancelling such payments, it is not necessary to attempt canceling the move
if it is unposted.
This patch allows cancelling such payments without needing to configure the
journal as cancellable while the move is still draft.
To reproduce:
1. check "Post at bank reconciliation" on a bank journal
2. do "Register payment" with that journal on a invoice
3. open the generated payment
4. click cancel => error "You cannot modify a posted entry of this journal..."
closesodoo/odoo#33312
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The visibility condition of the Matching group on account move line
was not compatible with the visibility condition of the
"View partially reconciled" button. So the group being hidden was
hiding the button that should overwise have been visible.
closes#32043closes#32216
opw:1961210
closesodoo/odoo#32371
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Purpose
=======
Unbreak consistency check:
- on creation (check not done)
- when applied to a record set of several sheets belonging to different employees (reporting spurious errors)
Specification
=============
- self.something() in a api.model method does not make sense, so I replaced it with a call on the newly created sheet.
- Iterate on sheets instead of mapping all the lines
Purpose
=======
Employee must match on sheet and lines
Since the employee_id field of hr.expense.sheet is modifiable in submit state, there is a possibility to modify a sheet in such a way that the employee does not match on the expense sheet and expense lines. This commit fixes this.
Closes#17274
Without this, the Configuration > Accounting > Journals shows
the Bank Journals view. And the type column is missing.
This align with what is done for the form view.
by auto-extending addons path with odoo.addons.__path__.
This patch also introduce
* an explicit declaration of odoo.addons as a namespace package
This is necessary because the standard way of declaring namespace
packages in setup.py does not work as long as odoo/__init__.py
contains code.
* a more reliable way to find odoo root path.
Properties depends on with which companies the records
are browsed.
When retrieving the fiscal position as sudo,
the company must therefore be enforced within the context,
to make sure to get the properties from the right
company.
This method can totally be accessed as sudo,
within the crons for instance.
Before this revision, the recurring invoices cron
could retrieve properties from the wrong company,
and therefore retrieve the fiscal position of another
company.
Closes#11039
The domain for the analytic account in the `reconcile with writeoff` wizard
should be based on the `type` field, which must be `view`,
not on the `parent_id` field, as it's done everywhere else
(e.g. in the supplier invoice form).
`[('parent_id', '!=', False)]`
and
`[('type', '!=', 'view')]`
is almost the same, but the second domain is more appropriate.
Closes#4562
In account_budget module,
when creating a budget position,
the user can select view accounts and also accounts with consolidation children,
in addition to normal accounts.
However, when viewing budgets with positions containing only view accounts,
the "practical amount" field was always zero.
Since these type of accounts are accepted as budget positions,
the system should take into account children and consolidation children
when computing the practical amount.
Fixes#372Closes#1247
- remove 2011 tax data
- remove unneeded tax account for 0% taxes
- TVA en amont moved under 421611 instead of 422611
- Fix issues with IB-PA, AP-PA, IP-PA and all taxes with children
- improve structure for tax codes
- fix account type (other -> view)
- add fiscal position mappings
- credit part of IC/EC taxes goes into account 461 instead of 421
- add missing template account for TVA en amont extracommunautaire
- fix a long standing issue with the reconcile flag on accounts
- use TRUE/FALSE instead of t/f in the csv
- added source XLS file with conversion script
Closes#5870
The tax_amount on account.move.line generated from the validation of an invoice
did not include the taxes with 'include in base amount' enabled.
Instead of using the line total, use the price_unit of the tax which is
correctly computed through compute_all method.
Fixes#5939
The key 'novalidate' is added in the context when an operation not impacting
the validation of a move is made. The validation recreates analytic lines
which decrease the performances.
In case of registrating a payment, the skipped validation are the one from
the reconcile method (reconciliation does not change the validity)
Fixes#3787, opw 618529
Since bank statement do not use vouchers anymore in 8.0,
it's not necessary to create the voucher anymore.
Additionally, I add an extension point to let modules adapt
the statement line.
[FIX] account: Preserve analytic account on tax lines which are on same general account as invoice line
After careful analysis, I'm now convinced it is a good thing to preserve
the analytic account on taxes line which have the same general account
as the invoice line.
This is the best default case and will save time for users,
while leaving the flexibility to adapt the analytic account on
taxes manually.
[FIX] account: Error when manually adding analytic account in the generated tax lines on an invoice
fixes#374
fixes https://bugs.launchpad.net/ocb-addons/+bug/1084822
The fix considers invoice tax lines with different analytic account
are equivalent for the purpose of checking if the list of tax line
is complete.
Caveat, this changes the structure of keys in the dictionary
returned by account.invoice.tax's compute method, I suppose this
is ok for the master branch.
After closing a POS session, the pos order lines are grouped by product.
Instead, distinguish products with a different discount notice to have different lines for such products in the generated account.move for better traceability.
Looking for accounts with reconcile=True is enough.
Restricting on payable/receivable account types narrows the search
to much and makes it difficult to implement transfer account holding
the payment while they are in transit at the bank.
Relying on the ordering by tax code is not sufficient,
as some tax declarations such as the Luxemburg one,
show tax case codes not ordered numerically
Original fix courtesy of Stefan Rijnhart (Therp)
Fixes: lp:1168948
Rebase of: PR #759
After careful analysis, I'm now convinced it is a good thing to preserve
the analytic account on taxes line which have the same general account
as the invoice line.
This is the best default case and will save time for users,
while leaving the flexibility to adapt the analytic account on
taxes manually.
fixes#374
fixes https://bugs.launchpad.net/ocb-addons/+bug/1084822
The fix considers invoice tax lines with different analytic account
are equivalent for the purpose of checking if the list of tax line
is complete.
Caveat, this changes the structure of keys in the dictionary
returned by account.invoice.tax's compute method, I suppose this
is ok for the master branch.
The accounts "TVA en amont" were not used by the l10n_lu chart of accounts.
Instead the accounts "TVA en aval" were used for all taxes both sale and purchase taxes.
(Manual rebase of PR #735)
Stéphane Bidoul