In anglosaxon accounting's stock valuation, the case where invoice and company currencies are different was not managed properly, because of a syntactic error in the condition checking this case.
(this has already been merged on saas-14, but the PR should have initially been made for 10.0 ... my mistake ! See https://github.com/odoo/odoo/pull/17259 )
Before this commit the key default_type in the context was messing with ir_attachment's own key of the same name
We change the key's name to avoid misreadings
OPW 757039
Closes#18515
Before this commit, the iframe tags were sanitized as the should, but never spawn back from JS.
Now, the iframe is actually created
opw 750830
Closes#18643
* [FIX] Gamification: email template
- realized that the pictures of users were not public by default,
which means src with an url won't work if not connected to the database.
This is fixed by embedding the pictures directly in the mail.
* [FIX] Gamification: challenge template
- fixed layout problems with what works in the renderer.
When a unique variant was created from a product template with function create_variant_ids,
two product price history were created:
-One was created from function create on product.product
-The other one was created from function _set_standard_price on
product.template
The first product.price.history created in this situation was all the time
set to 0 and it lead to some problems in the report inventory date.
This first product.price.history doesn't have to be created.
opw:747857
Since the switch to the new views, clicking on a 12am cell in a week
view of calendar triggers a traceback. A similar issue happens when
creating an event at 11.30pm. This is due to the fact that events
starting or ending at 12am are suspected to be incorrect and are thus
checked against the database.
This commit fixes both issues, by requiring that database checks be
carried out only if the records actually exist in the database.
- Activate multi-company
- Company B is parent of Company A
- Admin is in Company A
- Demo is in Company B
- Create a rate with Demo
The rate is recorded on Company A, not Company B as expected.
This is because we call: `self.env.user._get_company()` which would be
equivalent to `self.env.user.env.user.company_id`. Since the user is
browsed as `sudo`, it returns the company of the Admin.
opw-753139
The rev. https://github.com/odoo/odoo/commit/99ae418bf24171fbc6bb27584059c27efb857e77
introduced a trigger_up `mutexify` when quick creating a record in a many2one ;
this broke the behaviour when the many2one was standalone (because it has no
BasicController and mutexify is handled in the latter).
An attempt to fix this issue has been made in the rev. https://github.com/odoo/odoo/commit/e83c3e2678500c9bf2c17b4d23ae9a294ebafaa7
by adding an option `standalone` in the field widget options. In this case,
the action was directly executed instead of the trigger_up. While this correctly
works, this implies that the option needs to be added in every standalone
many2one (and only many2one as the others won't use the option), which is not
very convenient.
An other attempt is made in this rev. by moving the mutexify handler from the
BasicController to the FieldManagerMixin ; as a widget that instantiates a field
widget needs to extend this mixin, both cases will work and we won't need to
specify the option anymore.
This commit thus partially reverts the rev. https://github.com/odoo/odoo/commit/e83c3e2678500c9bf2c17b4d23ae9a294ebafaa7
When creating a customer invoice with description/reference with more than
64 characters, the description was cut to generate the name of the account move
lines. But it's possible to create an entry with more than 64 characters as name
by the interface. The limitation is deprecated.
opw:760316
On a list view, if we group records the arrows and changing page
feature are disabled. But if then we removed the grouping, the arrows
never reappeared.
note: not necessary as of 9.0 it was already solved in 1280bf251
opw-760956
closes#18596
the field data-max is supposed to be stored in the database.
Currently, the arg is 'stored=True' which is not recognised by the orm.
This fix ensures the field is correctly sotred and thus not computed at reading.
Add into the warning message the list of stock.move that raise the constraints
error.
When you create an 'Inventory Ajustment' of 1000 lines and see this error,
it is not easy to find which product could cause the problem.
This solution is not perfect since the name is not uniq, but it decrease
drastically the number of record to check manually.
opw-760643
UserError uses a retrocompatibility function 'except_orm' which one can take a
second parameters. The default value of this second param is None, so if we
don't force an empty string, we will see a None on each raise UserError as last line.
When returning a delivered product with a non internal location,
the delivered quantity on the SO was not updated.
Steps to return a delivered product:
- Click on button "Return" on stock.picking
- Check the refund box
- Click on return
PS: for the field return location, you can choose a child location from
WH/stock. So it can be a not internal one.
opw:749610
When "No message" is set on field purchase_line_warn/sale_line_warn,
the message doesn't have to be displayed in the respective field
purchase_line_warn_msg/sale_line_warn_msg.
opw:760801
When I did efd15852, I accidentally undid d20074c5. That commit
wanted to filter out unwanted values from the action context, but
it was too violent, as it was discarding the action context. (See
bug described in efd15852)
My original commit aimed at avoiding the filtering of the action
context by having it devoid of unwanted values altogether. The
idea was "if this is an action button, we don't want the element
context". However, the default behavior of the _getContext function
was to add the element context. There were options to force to add
the element context despite being in a case where it should not be
added, but we needed the opposite: do not add the element context.
We used "additionalContext" in this fashion, the idea was: "if I
give you specific context values, don't polute it with the element
context". This was efd15852.
However, not all actions have context defined explicitely in their
definition. In this case, since additionalContext was undefined,
the element context was added again, despite our will not to add
it for actions. We solved this by simply always giving an
additionalContext to getContext, providing an empty one if needed.
To reproduce this bug (which is the same as efd15852):
- Go to Manufacturing
- Click on menu Master Data then Products
- Open a product
- Click on the "Bills of Materials" stat button
- Click on create
- The create crashes because of the "default_type" context key
that is erroneously passed from the "Products" action to the
"Bills of Materials" stat button action.
In the dashboard, the domain wasn't passed to the view since the new views.
The action in the dashboard and the one saved were thus different (ex: when
saving 'Customer', you got all partners).
This was also causing a traceback when editing a value in the grid view.
This domain is now correctly passed.
This commit aims to reproduce saas-15 behaviour when rendering the
calendar. More explicitely, in favourable conditions, we would like the
calendar to be contained in a scroller adapted to the screen dimensions.
To do so, we require that the calendar only use the height given by its
parent container (in case of overflow, the calendar should have its own
scrollbars). We then trigger a 'resize' event to account for a bad
initial render of the calendar.
This fix reproduces a behavior implemented in saas-15.
It avoids simultaneous actions when you quickly click
on status bar buttons.
For example, in a manufacturing order, the main_flow_tour clicks
on 'check availability' and 'produce'.
Clicking on 'check availability' triggers an act_window_close
action when it has done.
Clicking on produce opens a dialog. Both action are executed simultaneously.
It may happen that the act_window_close closes the dialog opened by action
'produce', which makes the test fail.
Now the following buttons are disabled if you click on a status bar button:
- action buttons in control panel
- action buttons in status bar
- stat buttons in button box
Personal information should be protected at the model level, not only
the view. Otherwise, user can read these fields when exporting.
Courtesy of @odony
opw-752734
Fine tuning of this commit:7333f5e
When the PO lines were not ordered according to the scheduled date,
the scheduled date of the picking was wrong when delivering.
opw:752192
oco-odoo