Wednesday, May 24, 2023
7 changes · master
Enhancements to existing features
Payment notifications from Adyen and Stripe now return clearer success or error responses. This helps payment providers detect failed notifications correctly instead of treating every response as successful, improving reliability for payment processing.
Original PR description
to return the response with correct status code as json-rpc returned status code 200 even if there was an error task-2835711
The replenishment wizard now gives users clearer planning information, including forecasted quantities by warehouse and easier route selection. It also improves the form layout, scheduled date display, vendor visibility, and prevents inappropriate dropship route choices, making replenishment decisions faster and less error-prone.
Original PR description
With this commit: ======================== - Added a new field `forecasted_qty` in replenishment to display the forecasted qty based on a selected warehouse in the wizard - Changed the `route_ids`(m2m) field to `route_id`(m2o) so that we can apply a specific route for the replenishment instead of the product's default routes - Reduced the width of all the fields - Remove the seconds from the `scheduled date` and make the `unit` field not editable. - Can see vendor information with info icon field when buy is selected - Hide the Dropship route from the Route TaskId: 2579425
Helpdesk ticket screens are easier to navigate, with less clutter and clearer links to related invoices and tickets. Email alias handling for helpdesk teams is also improved so teams keep or regain a usable alias instead of showing an inactive one.
Original PR description
- Impacted modules: - helpdesk - helpdesk_sale_timesheet - helpdesk_stock - helpdesk_timesheet - Detailed changes: - helpdesk.ticket form view: - tickets stat button: The helpdesk tickets stat button…
- Impacted modules:
- helpdesk
- helpdesk_sale_timesheet
- helpdesk_stock
- helpdesk_timesheet
- Detailed changes:
- helpdesk.ticket form view:
- tickets stat button: The helpdesk tickets stat button doesn't
take into account anymore tickets from customers that share
the same email domain address as the customer set on the
current ticket.
- invoices stat button: add an 'invoices' stat button
representing the invoices linked to the SO of the SOL set on
the ticket.
- notebook: move the fields company_id, product_id, lot_id and
analytic_account_id in a new notebook page "Extra info", only
visible if at least one of those fields is visible.
- helpdesk.team configuration view:
- helpdesk.team > email alias: if the user leaves the alias
field empty, set the existing alias of the team back or
generate a new alias for the team on save instead of
displaying 'inactive alias' (and instead of disable the option
use_alias, hence reverting part of https://github.com/odoo/enterprise/pull/37526 ).
task-3101459Resolved issues and error corrections
This fix prevents an error during installation or upgrade of manufacturing subcontracting when the standard Buy route has been deleted. Businesses can continue configuring inventory and subcontracting workflows without being blocked by a system traceback.
Original PR description
when the user deletes the route of the `stock` module that is present in the data file of `Purchase Stock`. while installing or upgrading the `MRP Subcontracting` module the user gets an error as the…
when the user deletes the route of the `stock` module that is present in the data file of `Purchase Stock`. while installing or upgrading the `MRP Subcontracting` module the user gets an error as the stock route referenced from the `Purchase Stock` module has been deleted.
Steps to reproduce :
1. Install the Inventory module.
2. Install the purchase and MRP module.
3. Open the Inventory app.
4. Go to configuration > settings.
5. Enable Multi-steps routes and save them.
6. Open configuration > Routes.
7. Delete the `Buy` route.
8. Install the `MRP Subcontracting` module.
9. Traceback generated.
Traceback in sentry :
```
UserError: Can't find any generic route Buy.
File "odoo/tools/convert.py", line 550, in _tag_root
f(rec)
File "odoo/tools/convert.py", line 279, in _tag_function
_eval_xml(self, rec, env)
File "odoo/tools/convert.py", line 204, in _eval_xml
return odoo.api.call_kw(model, method_name, args, kwargs)
File "odoo/api.py", line 461, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 448, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "addons/mrp_subcontracting/models/stock_warehouse.py", line 37, in write
res = super().write(vals)
File "addons/mrp/models/stock_warehouse.py", line 282, in write
return super(StockWarehouse, self).write(vals)
File "addons/stock/models/stock_warehouse.py", line 197, in write
warehouse.write(picking_type_vals)
File "addons/mrp_subcontracting/models/stock_warehouse.py", line 37, in write
res = super().write(vals)
File "addons/mrp/models/stock_warehouse.py", line 282, in write
return super(StockWarehouse, self).write(vals)
File "addons/stock/models/stock_warehouse.py", line 206, in write
global_rules = warehouse._get_global_route_rules_values()
File "addons/mrp_subcontracting/models/stock_warehouse.py", line 90, in _get_global_route_rules_values
rules = super(StockWarehouse, self)._get_global_route_rules_values()
File "addons/purchase_stock/models/stock.py", line 35, in _get_global_route_rules_values
'route_id': self._find_global_route('purchase_stock.route_warehouse0_buy', _('Buy')).id,
File "addons/stock/models/stock_warehouse.py", line 379, in _find_global_route
raise UserError(_('Can\'t find any generic route %s.') % (route_name))
ParseError: while parsing /home/odoo/src/odoo/saas-16.2/addons/mrp_subcontracting/data/mrp_subcontracting_data.xml:10, somewhere inside
<function model="stock.warehouse" name="write">
<value model="stock.warehouse" eval="obj().env['stock.warehouse'].search([]).ids"/>
<value eval="{'subcontracting_to_resupply': True}"/>
</function>
File "odoo/http.py", line 2115, in __call__
response = request._serve_db()
File "odoo/http.py", line 1698, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1725, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1922, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 154, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 715, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 32, in call_button
action = self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 24, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 461, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 448, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "odoo/addons/base/models/res_config.py", line 614, in execute
installation_status = self._install_modules(to_install)
File "odoo/addons/base/models/res_config.py", line 32, in _install_modules
result = to_install_modules.button_immediate_install()
File "home/odoo/src/custom/trial/saas_trial/models/module.py", line 80, in button_immediate_install
return super(IrModuleModule, self).button_immediate_install()
File "<decorator-gen-73>", line 2, in button_immediate_install
File "odoo/addons/base/models/ir_module.py", line 76, in check_and_log
return method(self, *args, **kwargs)
File "odoo/addons/base/models/ir_module.py", line 472, in button_immediate_install
return self._button_immediate_function(type(self).button_install)
File "home/odoo/src/custom/trial/saas_trial/models/module.py", line 52, in _button_immediate_function
res = super(IrModuleModule, self)._button_immediate_function(function)
File "odoo/addons/base/models/ir_module.py", line 596, in _button_immediate_function
registry = modules.registry.Registry.new(self._cr.dbname, update_module=True)
File "<decorator-gen-14>", line 2, in new
File "odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "odoo/modules/registry.py", line 90, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "odoo/modules/loading.py", line 481, in load_modules
processed_modules += load_marked_modules(env, graph,
File "odoo/modules/loading.py", line 365, in load_marked_modules
loaded, processed = load_module_graph(
File "odoo/modules/loading.py", line 226, in load_module_graph
load_data(env, idref, mode, kind='data', package=package)
File "odoo/modules/loading.py", line 71, in load_data
tools.convert_file(env, package.name, filename, idref, mode, noupdate, kind)
File "odoo/tools/convert.py", line 613, in convert_file
convert_xml_import(env, module, fp, idref, mode, noupdate)
File "odoo/tools/convert.py", line 679, in convert_xml_import
obj.parse(doc.getroot())
File "odoo/tools/convert.py", line 599, in parse
self._tag_root(de)
File "odoo/tools/convert.py", line 550, in _tag_root
f(rec)
File "odoo/tools/convert.py", line 563, in _tag_root
raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
```
Applying these changes will resolve this issue.
sentry - 4128085959Invoice uploads that include VAT details no longer fail because a required VAT validation component is missing. This helps businesses import supplier invoices more reliably and avoids blocked processing caused by a hidden setup dependency.
Original PR description
AttributeError: "res.partner" object has no attribute '_run_vat_test' log error is generated, and nothing is imported when users upload invoice file that have a VAT field. This is because the…
AttributeError: "res.partner" object has no attribute '_run_vat_test' log error
is generated, and nothing is imported when users upload invoice file that have a
VAT field. This is because the "_run_vat_test" attribute is defined in the
"base_vat" module and is not installed due to countries not having VAT.
Traceback on sentry:
```
AttributeError: 'res.partner' object has no attribute '_run_vat_test'
File "addons/account/models/account_move.py", line 2898, in _extend_with_attachments
success = decoder(invoice, file_data, new)
File "addons/account_edi_ubl_cii/models/account_edi_common.py", line 294, in _import_invoice_ubl_cii
logs = self._import_fill_invoice_form(invoice, tree, qty_factor)
File "addons/account_edi_ubl_cii/models/account_edi_xml_cii_facturx.py", line 228, in _import_fill_invoice_form
self._import_retrieve_and_fill_partner(invoice, name=name, phone=phone, mail=mail, vat=vat)
File "addons/account_edi_ubl_cii/models/account_edi_common.py", line 352, in _import_retrieve_and_fill_partner
if vat and self.env['res.partner']._run_vat_test(vat, country_code, invoice.partner_id.is_company):
```
This commit add the 'base_vat' in depends to prevent above error.
sentry-4074943505Manufacturing backorders no longer create hidden quality checks for work orders that were already completed and cancelled. This prevents users from being blocked by incorrect quality-check warnings when finishing valid backorders.
Original PR description
To reproduce the bug this commit fixes do the following: 1) Create a bom with 2 operations. 2) Create a quality point for each operation. 3) Create an MO based on the bom with quantity to produce 2.…
To reproduce the bug this commit fixes do the following: 1) Create a bom with 2 operations. 2) Create a quality point for each operation. 3) Create an MO based on the bom with quantity to produce 2. 4) For the first workorder, set quantity producing to 2 and pass the check, mark done. 5) For the second workorder, set the quantity producing to 1 and pass the check, mark done. 6) Go back to the MO, quantity to produce should be 1 / 2, click produce. 7) A backorder pop up appears, create backorder. 8) The fully finished workorder should appear cancelled in the backorder. 9) Process the second workorder and pass the check. 10) Go back to backorder and click produce, a UserError shows up asking to process all checks Expected: Should be able to produce the backorder since the workorder was already processed and marked as cancelled Explanation: The bug was that there were hidden quality checks created for the cancelled workorder when the backorder workorders were confirmed.
The appraisal publish action now consistently warns any user who is allowed to publish an employee appraisal, including additional managers assigned on the appraisal. This helps prevent accidental publication and makes appraisal access behavior more consistent across related appraisal screens.
Original PR description
An employee in the manager_ids fields was not considered a manager by the computation and was not getting the warning when toggling on publication for the employee appraisal. This is now corrected and the computation has been refactored to correctly compute the status like it was written in previous commit message. task 3217812