On UNIX, the timezone modules conversions can be reset by using
`time.tzset()`. On windows this is not available and the timezone (TZ)
environment variable must be set before the first import of time module.
If not, all datetime gotten in python without specifying UTC (such as
datetime.datetime.now) could be wrong.
This was fixed with 4a77c6a0 in 2013, but has come back since 389c2ba97b
imported pkg_resources (which do a `time` module import) before that.
closes#14926
opw-693764
- Create a SO for a customer (without VAT), validate the invoice
- Connected as the customer, go to 'my/account', and change any
information (e.g. phone number).
You receive the error 'Changing VAT number is not allowed...'.
This is because `data.get('vat', partner.vat)` is `u''`, while
`partner.vat` is `False`.
opw-696962
Previous commit was cleaning the orphan and fuzzy translations of all main translations.
This commit does the same for all regional languages (that are not on Transifex).
To keep these files small, keep only the translated strings.
Fixes#14937
Was removed at 467ba386 but need it in blackbox for many terms
The alternative is to add all the fields in export_for_printing but this patch,
even if less modular, is way smaller and safer.
When a search is performed and the completion feature is used (search on
a many2one field), clicking on a '(no result)' item causes a crash.
opw-703557
Some languages were published on Transifex in v9 but no longer in v10.
These languages were still using the outdated .po files
In some of these po, there were some fuzzy translations that were incorrect
(e.g. 'POS Order %s' - 'Kassa ostud', missing '%s')
These were not erased as still using the old translations.
Regenerate a correct .po file based on the new .pot and remove fuzzy
translations.
Fixes similar issue than raised at #14937
The onchange code calls the variable 'partner' before assignement,
this error comes from the migration in rev: https://github.com/odoo/odoo/commit/d45996c9
We fix it by calling the right 'self.partner_id' variable
These `end` migration script will be executed when all modules have
been updated and models setup.
Also accelerate the search of migration scripts, speeding up registry
loading.
To reproduce:
- Configure an external payment provider (e.g. Ingenico) with "Authorize
& capture the amount, confirm the SO and auto-validate the invoice on
acquirer confirmation"
- Create a quotation with a product linked to a subscription
- Send the link to the customer
- Click on "Accept & Pay", use the configured provider
The SO is confirmed, but the invoice is not generated.
By calling `action_confirm` in the callback of the transaction, we
validate the SO before `form_feedback` is called. Therefore, the method
`_confirm_so` will do nothing since the SO is not in state 'draft' or
'sent' anymore.
The solution is to manually call `_confirm_so`instead of
`action_confirm`. This is necessary to do it at this moment since we
might not go through `form_feedback` (e.g. if we pay thanks to wire
transfer).
opw-694273
To reproduce:
- Create 2 products with 'Track Service' set as 'Create a task and track
hours'.
- On a SO, add these 2 products and confirm (2 tasks will be created)
- Go to Timesheet > Activities, and create a line for Task 1. The
delivered quantity of Product 1 in the SO should be modified
accordingly.
- Change the activity line by setting 'Task 2' instead of 'Task 1'.
The delivered quantity of Product 2 is updated accordingly, but the
delivered quantity of Product 1 is unchanged.
This is a complement of commit 4e60d28d00.
opw-693520
opw-695087
When adding a partner "filter" to the calendar view, it only works if we
select directly the partner and not when we choose him via "search more"
or create him on the fly.
This commit uses the partner id directly which is available in the field
value in those three possible instances.
opw-702491
Use the same logic to display taxes as in the default report:
use the tax description and fallback on the name
Already done in report_invoice_document and report_saleorder_document
Closes#14906
It forced to select a coutnry before the state which is not very userfriendly.
Cf comments at #13657
Instead restrict only if the country if a country is selected.
Courtesy of Pedro M. Baeza, Tecnativa
For v10 this is a minimum change and a larger refactoring can be done in master.
This replaces and closes#14896
By not marking invalid custom views as a failure, this allow database
migrations to not be considered failed for simple errors that can be
solved after migration.
normal mode: Importing only regular/basic fields from source file
advanced mode: Importing any related fields from source file(i.e. if detected pattern in header like '<relational_fieldname>/<fname>')
- Rename following checkbox "Show all fields for completion (advanced)" in "Show fields of relation fields (advanced)"
- If the import file contains a column with a field of a relation field, show the column label in the preview, even if "Show fields of relation fields (advanced)" is not checked > to make it less confusing when importing advanced files (e.g. products with attributes)
This is a backport of 1ba4fbe640, which was performed due to several
tickets mentioning confusion with the new import system.
Some more recent versions of etherpad can have newlines in the pad
content. Allowing newlines should not break anything that worked
before and allow more etherpad versions to be used.
closes#14877
opw-703173
The css clear was using jquery ui class for enterprise which now may
not be available on the given part. This commit replace it with class
defined in account_reconciliation.
With this the style could have issues such as not displaying the
congratulation message after reconciliation.
fixes#14743
Each qty of a line in the BOM Structure report must be computed in
the uom of its BOM line.
Example:
With 2 products: A, B
BOM A: 100 kg of A is produced by 5t of B
So 1kg of A needs how many t of B ?:
In the code:
qty_per_bom = 100 kg expressed in the uom of B => qty_per_bom = 0.1t
qty = 1 kg expressed in the uom of B => qty = 0.001t
l.product_qty = 5t
qty of B = (l.product_qty *qty)/ qty_per_bom = 0.05t
opw:697502
Due to an error introduced when migrating the module at new API
at commit a4e57ea16c limited attendances
having date_from and / or date_to were not correctly taken into
account.
Tests have been added to avoid regression.
Commit d861cdc1c4 introduced the tax group feature. The tax line
details were removed from the printed invoice in favor of the tax group.
However, it requires that all tax groups are correctly defined in the
localization, otherwise the printed invoice doesn't show the required
tax details.
The correct fix, which is the complete definition of the tax groups,
will be done for the upcoming v11 version. In the meantime, this simply
introduces back the tax details table.
Nicolas Martinelli