If an action unlink the current records (e.g. unreconcile on account.move.reconcile), trigger history_back to avoid errors when trying to reload inexistant record (opw 607883)
This is a partial backport of saas-4 code (rev c0db6ae, 162ad1c) and should not be forward ported.
When creating an invoice from a sale order, if the user choose to invoice a fixed price (deposit), he has the possibility to choose an advance product. As described in the help message, this product should be a service product. Therefore, we add a domain so only services are displayed in the dropdown list
If we try to generate twice entries on the same fiscal year, we can get completly unrelated errors ("You can only reconcile journal items with the same partner").
With this, we make sure people will first cancel the entries before regeneraing the entries.
To search the contracts for payroll, the domain is constructed with three clauses. Each of these clauses needs to start with a '&' to make sure they are correctly combined with the OR clause'
In the backend the option 'Allow a different address for delivery and invoicing' will set the group sale.group_delivery_invoice_address to employees. However the public user is not an employee (and we don't want to change that) so does not get this group. As we don't have similar group mechanism for public user, we have no other choice than always displaying the option to have different address. opw 610118
When searching for default values, if we set a condition (e.g. 'type=out_invoice'), fetch also the default values without any condition set. Thanks to the order by clause, the one with a condition have an higher priority than the one without and will not affect existing result.
This fixes default journal/currency on an invoice where the journal is retrieved in the onchange_company_id method (domain is forced). Without this patch only ir.values with a domain set will match, opw 610645
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)
At rev 84e9a67cdf a check to avoid the creation of ir.model.relation for custom modules was added. The condition is not correct as based on the string instead of the field name. We do not have access to column name at this level but the the m2m relation table do start with x_ for custom fields (see __init__ method).
[FIX] mail: misc bug fixing
- avoid deleting the Whole Company mail group if still present, because it is required for some module installation. In 7.0 installing some modules may crash if this group is not present.
- fixed an issue when computing possible recipients in the Chatter
- small fix in html2plaintext about blank lines
orm: do not try to create ir.model.relation for custom m2m as self._module is either empty (for custom models), either the one of the last inheriting module (which is wrong). The field should be removed manually and should not be impacted by the uninstallation of modules. The removal of the relation table can be done when removing manually the custom field (see rev 6af3193).
ir.model: when removing a model, drop the table with the CASCADE instruction. This will remove left constraints from remaining m2m tables.
This means that dropping a table (either manually removing a custom model or uninstalling a module) will not drop the relation table for a custom m2m field. This is not ideal but better than the previous behaviour (which was to fail the DROP TABLE instruction and keep the table with a few columns and unconsistent data).
When droping a column, remove also the relation table in case of custom m2m field.
The relation table needs to be dropped otherwise an unremovable constraint to the targetted table is kept (and anyway is not needed anymore).
When the cron for autovacuum runs, the osv_memory objects are deleted. The portal.wizard.user object has a required field (wizard_id) linked to another osv_memory object (portal.user) which causes a traceback when the cron tries to delete portal.user object before the portal.wizard.user. opw 609918
This instance was not actually exploitable for
SQL injection as it is not callable directly
via RPC and guarded by other queries when indirectly
called. Still plain awful.
This instance was not actually exploitable for
SQL injection as it is not callable directly
via RPC and guarded by other queries when indirectly
called. Still plain awful.
The installation of a multilang localisation (e.g. Belgium) used to install as well account_accountant (and then account_voucher) for no technical reason and was considered as the full accounting package.
Martin Trigaux