Add support for value 'save' to attribute 'special' for buttons in
form view. This is useful for form views in dialogs. When clicked,
it saves the form view and closes the dialog (the default 'Save'
button doesn't close the dialog). Without this, the only way to
achieve that was to define a dummy python method and call it with
<button type="object" name="dummy_method"/>.
Authorship should go to https://github.com/joray . However as he did
not sign the CLA and does not seem very active the patch is applied
to benefit from the improvement.
Closes#16294 .
Description of the issue/feature this PR addresses:
The Tax ID field is validating NOxxxxxxxxx as format, but the format is actually NOxxxxxxxxxMVA if you are in the VAT registrty.
Current behavior before PR:
Valid tax numbers for Norway are rejected.
Desired behavior after PR is merged:
The format NOxxxxxxxxxMVA is accepted, along with the old behaviour of NOxxxxxxxxx.
Description of the issue/feature this PR addresses:
The production routing is ignored when creating previous movements
Current behavior before PR:
When you create a production that does not have a routing established in the BOM, and you set a route manually, it is ignored when creating the previous movements
A purchase order is not the best way to create new taxes on the fly. We
therefore add the no_create option on taxes to avoid quick creating
them on a purchase order like what is already done with invoices.
Closes#15639
A sale order is not the best way to create new taxes on the fly. We
therefore add the no_create option on taxes to avoid quick creating
them on a sale order like what is already done with invoices.
Closes#15640
In view dialogs (e.g. click on the external button of a many2one
in edit mode), the attribute $buttons of the form controller is
undefined (the buttons are rendered by the dialog directly). The
code that (de)activate the buttons to prevent concurrent clicks
made the assumption that $buttons exist, so it crashed when it
doesn't.
Closes#16366
Steps to reproduce the problem:
- create 2 company
- create 2 different sequences 'payment line', one for company
- create a payment order for company A and insert a line
- create a payment order for company B and insert a line
Get SQL error saying The payment line name must be unique
Closes#17274
Without this, the Configuration > Accounting > Journals shows
the Bank Journals view. And the type column is missing.
This align with what is done for the form view.
When duplicating a quotation with a template, the order date is set
to today's date. But the validity date was duplicated which was wrong.
Now the validity date is computed according to the template and not duplicated.
opw:744671
For example: open a draft quotation, click on 'Confirm sale',
before this rev., the record was reloaded twice (each RPC done to
load the data was duplicated). This was actually tested, but the
tests didn't mock well the behavior of the ViewManager, so they
couldn't detect that those RPCs were done twice.
For historical reasons, when the pivot view was rewritten, we lost the ability to understand the measure and col_group_by keys from the context.
It was actually a deliberate decision, because we decided that it was not possible to properly handle the colgroupbys in the search views, so we replaced that mechanism with pivot_col_group_by and pivot_measures keys exported by the view, when necessary.
Sadly, we did not properly remove the outdated keys from the xml files. So, with this commit, we reintroduce those special keys, because 10.0 is a stable version. Note that this will be removed in master.
(PR 17119)
Suppose that there is a many2many list (non editable) in a form
view. When one of the many2many subrecords is edited (from the
form view in a dialog), it is saved directly when the user clicks
on 'Save' in the dialog.
Before this rev., if the user clicked on 'Save' in the main form
view after editing a m2m subrecord, a 'write' RPC was done, whereas
there were nothing left to save (as the subrecord had already been
saved).
Suppose that we have a form view with a one2many list (non
editable) containing a record. In edit mode, the user clicks on
that record to edit it in a form view (in a dialog). In this form
view, there is an x2many field that isn't in the list. Before this
rev., it crashed when the user clicked on 'Save' in the dialog
after editing the value of the x2many.
This was because the basic model didn't use the correct fieldsInfo
in that case (it use the fieldsInfo of the list view instead of the
one of the form view, and the x2many field isn't in the list).
Also ensures that the record is correctly saved even if editing the
x2many is the only change done, as this wasn't the case before.
Before this commit _lead_create_contact actually constructed values AND
created the partner in one single step, making it difficult to override
in localizations that affect the partner model.
As containing method already existed, the partner creation was moved up
to this method, and the method was renamed to match with the file's
conventions. Now this method cleanly constructs the values.
Closes#16493 .
Closes#16576
Description of the issue/feature this PR addresses:
According to HTML good practices, when an element is used but there's no text displayed on the screen, the attribute aria-label should be used to label that element.
This is the case in the buttons to change view types (List, Kanban, etc) since there's no text displayed, but an icon instead.
This HTML attribute is specially useful for screen readers, which usually are not able to figure out a button's functionality when that button is not properly labeled.
Current behavior before PR:
Buttons are not properly labeled
Desired behavior after PR is merged:
Appearance should be the same, but the produced HTML should be of better quality, because it would fit more HTML good conventions and it whould be more accessible
Related issue:
I had already reported this issue on the branch 10.0 at PR #16030. However, I decided to report it on this branch, because I believe this branch is the right place to be reported.
Closes#16801
When a warning is set on partner profile, _onchange_partner_id method in
the invoice returned the message before assigning account_id,
payment_term_id, fiscal_position_id. hence, those fields come with empty
value.
Board module allows to add favorites to my dashboard. This is an option
added by the board module under Favorites menu item of search view.
However its margin is incorrect and displays badly compared to other
options in search view.
When opening a modal on top of another, we expect the associated
modal-backdrop to be over this another modal (so that it is grayed).
This was not the case as bootstrap forces the modal-backdrop z-index
to a lower value than the modal's one (see fix comments in the changes
below).
Closes 16971
If the record with id `res_id` on the model `res_model` doesn't exists anymore, do not call name_get method on it in the method `_compute_res_name`. That could lead to tracebacks or inconsistencies.
In the list controller, some code to determine the active domain to
export was causing a crash. It was easy to see: just select all records
in a list view, then click on 'Export' in the sidebar.
Note that the data_export code is still quite old, and did evolve
organically. It does not conform to our new design principles, in
particular, the way component should communicate. But this is a task for
another day.
Due to a bad refactoring of this method during the remove of the
'report' module, a traceback occurs when resetting an invoice to draft.
This is due to the retrieve_attachment method that is used as an api.model
instead of api.multi.
Let's consider the product category PC in valuation = 'periodic' and the product P
with the category PC.
When creating a vendor bill with P, the account on line doesn't have to be
the stock input account but the expense account.
opw:744409
Currently the variants are ordered by the attribute value in the name_get. That way, all the attributes aren't displayed in the same order.
Ordering by the variant attribute name will solve this issue.
Closes https://github.com/odoo/odoo/pull/17034
In v9 the right filter to use is based upon the message_needaction
field coming from mail.thread . Indeed this gives records containing
messages demanding an action which is the right way to use the
needaction mechanism in 9, like done in all other addons inheriting
from mail.thread.
Closes#16769 .
Olivier Dony