The forward-port of the above revision missed
the conversion to the new api and that
`context` had to be replaced by `self.env.context`
Fixes#14922Closes#14923
In the Lead Automation module, the module is working as expected when
the activity type is 'Email'. In other cases, the corresponding methods
are not implemented and raise an error.
opw-697829
According to the routes set on the products of the raw materials, a
procurement may have to be created for the consumed lines of the MO.
A route may also be set on a product category. Before this patch, we
only look for procurement rules for the routes defined on the products
and on its category, ignoring the inherited route of the parent category.
Fortunetaly, we have a computed field on the product model returning
all the routes from the current category, so we use this one in the
search for procurement rules.
A test has been added to show the failure.
Before, when the routing of a production order was empty (no operations),
it got into an inconsistent state (you click on "plan" and nothing happens).
Empty routings were used before to do subcontracting or 2-steps inventeory
(we did not set any operations on the routing but we set a location).
Here, we change the related routing field on the production order into a
calculated field which becomes empty when the routing has no operations.
This way, the "produce" button is displayed (as for production orders
without routing) and working/
This is a temporary patch to workaround the issuein a stable release.
In master, we might remove the location on routing and place it on the
workcenters and put a constraint that does not allow an empty routing.
Revision 20935462a0
introduces the below regression:
When registering a payment on a customer invoice refund
or a vendor bill, with a payment difference
e.g. payment of 101 for an invoice of 100
and marking the invoice as fully paid,
the counter part in the payment account move
were wrongly computed:
In those cases,
its the payment total minus the invoice residual total
that must be performed, and not the other way around.
This revision solves this, inspired on how
the payment difference is computed for display
in the wizard on how it was before the above revision,
in the method `_compute_payment_difference`
Fixes#15000
Before this patch, the inventory was automatically posted when you click
on "done" on the last planned work order. This behavior was preventing
the user from correcting, for example, the consumed quantity on the raw
materials move on the manufacturing order if it was different from the
theoretical quantity. Note that finishing anyone but the last work order
still let you edit the consumed quantity. Same with changing the lot.
Now you have to click on "mark as done" on the manufacturing order to
post the inventory. Note that this is the same behavior when working
without work order (produce > mark as done will post).
We adapt the tests to reflect this change.
In some case (for example the one solved with b51d21c5) we can have
write done on a field text in read only mode.
With 98ed53ce if :
- such a case happened (in b51d21c5 the fix only worked after the given
field was written one time) or a similar instance,
- and the user was in debug mode,
- and the widget used was TextFieldHtmlSimple
this could lead to an issue with the code trying to toggle the code view
mode whilst the editor is closed.
When doing pivot table data visualization, the Unit Cost of several
lines are summed up but there has more meaning if they were averaged.
This will probably still not be perfect (such as averaging two line
with different quantities the quantities would not be taken into
accounts) but it is already slightly better.
opw-694068
Suppose the following usecase: you scan the first product of the
picking. A server onchange is then triggered. You scan the same product
a second time, before the first onchange has returned. You expect that
the first onchange is completely executed before running the second one.
This was not the case. Moreover, some onchanges were not be able to
work with the invalid state of the formview at some times, and crashed.
The previous implementation was wrong because id didn't run the main
barcode processing mechanism inside a Mutex. It was also wrong because
it didn't correctly wait for the onchange to execute (a previous barcode
onchanges or some classic ones) before setting the barcode field.
With 98ed53ce when a form view is saved when a html field is in code
view mode, the change is not lost.
This new backend tour check that when saving in or not in code view, the
content is saved effectively.
The test not in code view would ensure issues like #14381#14351#14394
are detected on runbot.
closes#14475
opw-693052
note: the old test system is used so this test is only for up to saas-11
The intended scenario when using the code view is the following:
1) click on code view button to use code view
2) make changes
3) click on code view button to get back to wysiwyg view
4) save from the wysiwyg view
If the 3rd step was not done:
- for the inline editor, we lose the changes that have been done in
code view,
- for the iframe editor, we lose the entirety of the content.
At one time the user was forced to go back to wysiwyg before being able
to save, but this have been removed hence the present usability issue.
With this fix, when the editor content is saved, if the user is in code
view he is automatically set back to wysiwyg view.
fixes#14648closes#14475
opw-678677
opw-693052
In e0c4ec54ca a change was done to improve the behavior in some
editable list instances, but this introduced a small issue for
list with line creation disabled.
With this change, doing tab or enter at last line should keep the
previous behavior of wrapping around and not creating a new line.
opw-703748
When the 'Invoicing' or 'Accounting' module is installed without the
module 'Sales', only the admin user can create products in the database.
The expected behavior is that any 'Accounting Adviser' should be able to
manage some products in Odoo.
To allow 'Accounting Advisers' to manage products, we add them the CRUD
rights on 'product.product', 'product.template' and
'product.price.history'
opw-703610
When a quality.alert was added from the kanban view, a traceback was raised
due to a coding error. In the fail function, the event is the second parameter.
opw:703281
Split method generate_account() in chart template generation to allow an easier overwritting of the vals in case a localization added some custom fields on account.account object. Courtesy of David Arnold(dar@devco.co)
Since new-api migration of `ir.ui.view`, the method that check views
raises exceptions instead of returning a boolean. Show them as warning.
Related to #14521
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
The number of records selected by a FieldCharDomain was only computed
with the base language.
But when selecting the domain with a modal window, or when sending a
mass mailing restricted to a domain, the current user language is used.
With this commit, the number of records is computed with the current
user language.
opw-693836
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
This reverts commit 804ef6f.
1. Generating the vendor bill by adding the related Purchase Order:
in that case, it works well since the system has a first on-change on the product when selecting the asset type;
it sets the asset account in the expense account of the product which in turn is used as the vendor bill account.
2. Creating the vendor by adding manually the product which is an asset:
in that case it takes the wrong account since it used the depreciation account instead of the asset one.
But the labels cannot be changed because the case 1 works.
opw:702265
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
Denis Ledoux