For actions executed in dialogs (target='new'), a DebugManager
is instantiated and appended to the dialog's header (div with
classname 'modal-header').
However, in the full composer dialog (in a chatter, click on
'Send message', and then click on the expand icon), there are
more than one element matching the selector '.modal-header',
because it also occurs in the html generated by summernote.
In this case, the widget's $el is cloned and appended to each
element of the JQuery nodeset matching the given selector, but
widget.$el only refers to one of those. So when it isn't the one
appended in the real dialog's header, the debug manager remains
empty as the widget isn't able to populate it correctly.
This bug appeared with rev. 5f1ef09, as before it, the debug
manager was appended to the dialog before its content.
When a picking contain a few thousands move line, reading it was slow
because of the computation of "entire_package_ids" and
"entire_package_detail_ids". The compute method for this field calls
"_check_move_lines_map_quant_package" that check that, for a picking,
all the move lines having "package_id" and "result_package_id" as the
same package (ie moving an entire pack) match exactly the content of the
package (ie the quants).
The issue was that the method was called for every move line without
packaging because of a wrongly written condition. We now only call the
method one time for each package, whatever the number of move line.
opw-803887
Issue: create 60 lines in ordered x2many with the same value (0) for the order
field and make a change ; the displayed records will be switched.
The problem appears because the sorting function is not stable and the
records with the same values can change place (hence change page), which is
quite disturbing for the user.
Two attempts of dealing with sorting (and resequencing) in tabbed (multi-pages)
x2many editable lists (see odoo/odoo@c2563db and odoo/odoo@983c7ae) have been
previously done, using a static attribute (`keepChangesUnsorted`) on the
datapoint.
This solution sadly only covers both cases separately, not if they are combined.
Morever, onchanges were not correctly managed in neither of these two cases.
A new approach is used here, by "freezing" and "unfreezing" the datapoint when
needed, which is more flexible.
Some modifications have been introduced:
- when ordering a x2many, all records are now considered (and not only the
records on the current page) ; an additional read is thus done on the sorted
field for all records in the x2many relation
- `setSort` is now asynchronous as a `read` might be needed
This was broken in 11.0 if the media dialog was the first dialog to be
opened when using the editor. This happened for two reasons:
- Never use a widget (dialog)'s `$el` before it is started (opened).
This was the case here. The bug is even worse in saas-11.1 as we do
not allow to do that from there so it results in a JS crash.
- It worked in <= saas-16 because dialogs were started at once as they
did not need to load anything. In >= 11.0, the first dialog which is
opened in the page needs to request the main dialog template and this
takes some time.
So, this fix makes sense in >= 9.0 but I chose to merge it in 11.0 as it
only induces a real bug from there.
Before this commit, the user had the ability to scroll horizontally
on some form views containing chatter.
This horizontal scroll only appeared in mobile (Android and iOS) but
it wasn't useful.
In many cases, we allow class and style attributes in the arch of a
view. However, it did not work in a list view, and there is not really
a good reason for that (only cost is a few runtime checks).
So, with this commit, we allow those attributes in list views (and
x2manys obviously).
However, note that there is a subtle (maybe slightly confusing)
behavior: when a list renderer is in 'readonly' mode, it does not
actually instantiate any field widgets. In that case, it optimizes the
rendering by putting only the formatted value inside a cell:
<td>some value</td>
So, in that case, the only valid target for the attributes is the td:
<td class="hello">some value</td>
But when we are in edit mode, we actually have a field widget inside a
td:
<td><input>some value</input></td>
And in that case, the natural home for the attributes is the field
widget. This is quite important, because this is the way attributes are
done in the form view, and we do not want different behaviour.
<td><input class="hello">some value</input></td>
Before this rev., the default filters were ignored in Discuss. The
SearchView was instantiated and correctly retrieved the default
filters. However, a first manual 'do_search' needs to be done by
the client action for the search view to provide the domain, and
for Discuss to correctly filter the messages.
Steps to reproduce the issue:
- In Discuss (e.g. in Inbox), add to Favorites a given search,
and tick 'Use by default'
- Leave Discuss, and then go back: the default filter correctly
appears in the search view, but the messages aren't filtered.
When creating an SO for a service that create a new Task in a Project, the customer
email field is left empty.
With this commit, the email field is filled with the SO customer's
email.
opw-803566
install delivery
Create a SO with a shipper
Validate it
validate the delivery
Before this commit it was:
- impossible to do the setup for the delivery cost on the SO to get updated with the delivery validation
- the delivery cost on the SO did not update
This was because the stock API changed a bit a some functions were not here anymore
OPW 786500
Before this commit, the special mrp validate_move method did a call to
quants_move with an incomplete signature. IN the use case, that we want
to make "own" produced quantities by a third party (maquila), we can do so in
downstream modules by restrict the partner on the move so that any moved (or
created) quants will belong to this partner (owner). This is certainly
important for the case where finished products are not your own
property. Courtesy of blaggacao.
Closes#21072
Before this commit, the triangular case was not handled:
A transaction in dropshipping which happens outside our country
(provider and customer both outside our country)
was counted in the intrastat XML when it shouldn't
After this commit, those transaction are not accounted for in the XML
opw-800342
Adapt commit b92aaf1 for framework changes in saas-16.
That commit made Many2ManyTagsEmail widget display name_get gotten
dynamically. This allow to have 'show_email' context key working and
having the email displayed.
This commit use the new views (as of saas-16) to do the same change.
opw-801558
fixes#21812fixes#21523closes#21969
- Install a new db with demo data and sale_stock module
- Set rounding for product unit of measure from 3 to 5.
- Run sale_stock tests (from command line with --test-enable)
Current behavior:
> FAIL: test_02_sale_stock_return (odoo.addons.sale_stock.tests.test_sale_stock.TestSaleStock)
>
> AssertionError: 3.0000000000000004 != 3.0 : Sale Stock: delivered quantity should be 3.0 instead of "3.0000000000000004" after picking return
>
Fixes#21246
opw-803837
This corresponds to:
Réduction pour personnes physique à bas revenu dans le secteur public
Réduction du précompte professionnel de 5,83 € (après application des réductions précédentes)
pour les rémunérations imposables comprises entre 565,02 € et 2 027,86 € maximum aux personnes
à bas revenus qui sont occupées comme statutaires, stagiaires ou temporaires au service
4 Net = brut − ONSS − 20 %
précompte professionnel 2017 • 7
de l’Etat, des Communautés, des Régions, provinces, établissements subordonnés aux provinces,
communes et établissements subordonnés aux communes, qui ne sont pas engagées en vertu
d’un contrat de travail.
Purpose
=======
Le bénéficiaire des revenus est un veuf (une veuve) non remarié(e) ou un
père (une mère) célibataire, avec un ou plusieurs enfants à charge
35 -> 36 euros
Steps to reproduce the bug:
- Create a new RFQ
- When it's in draft state, log an internal note using the 'mail.compose.message' dialog.
Bug:
- RFQ is now in 'sent' state.
The fix allows to inherit from mail_purchase_order_on_send method to change the base behavior.
opw:801549
To keep the same behavior as in 11.0, you can only add a purchase order to a vendor
bill when the vendor bill is in draft. Afterwards it is not longer possible.
opw:803068
Add the inventory value in the pivot view. Indeed, the Unit Cost
displayed is the cost of the quant, which is not what is expected in
case of standard costing method.
opw-785872
to reproduce:
- have 4 units of product 1 in stock
- create a move for a dozen, reserve it
- try to scrap a single unit
- an exception "cannot reserve more than available" is raised
To reflect the change of reservation after scrapping the quantity, we
have to update the reserved quantity on the move line.
When updating the quantity on the move line, "quantity_split" is in the
quant uom, so it should be converted to the uom of the move line.
- Set a decimal precision for 'Product Price' = 6
- Set a currency precision = 2
- In the product for view, set a 'Sales Price' = 0.123456
The price is rounded to 0.12, while one would expect it to be 0.123456.
We use the decimal precision of the field rather than the default
currency precision.
Fixes#21686
opw-800279
In v10, a `Float` field with `widget="monetary"` option uses the decimal
precision of the field. In v11, however, it uses the decimal precision
of the currency. However, in many cases `widget="monetary"` is used in
the sole purpose of displaying the currency symbol. The precision of the
field sould be kept.
This commit introduces the support of the decimal precision of the field
for this specific use case thanks to the `field_digits` option:
```
<field name="pouet" widget="monetary" options="{'field_digits': True}" />
```
If such an option is used, the field precision will prevail over the
currency precision.
Related to #21686
opw-800279
Before this commit, all tooltip users was showing website and parent_name from
the Main company and not the current focsed partner.
This commits closes#18430
@kangol: fwd-port company_name
If you set 200 kamra to allow to flag a post and 300 to edit all post, you was
not able to flag the post before this commit.
This commit closes#21274
@kangol: warning, fwd port need to add tag_ids into trusted_keys
The report 'Leaves by Department' only counts full days-off, instead of
taking into account the actual number of days.
This commit fixes the total number of days per employee. However, there
is still a limitation on the display: a day is either fully colored or
not at all.
opw-801061
Previous to this commit, we try to load as many fields as possible
during module installation, however sometimes some fields are not ready
to be loaded, which is the case for custom monetary fields, thus when
trying to find the current model's currency_id field it would not find
it at all, generating an assertion error.
This commit changes this by completely skipping monetary fields if they
are not ready to be loaded.
OPW 787223
In the module website, the relational field website_id is defined twice,
once for ir_ui_view and a second time for res_config_settings, for the
former we perform an ondelete='cascade', which means that when the
website model is unlinked, the field is unlinked as well.
This is not done for the website_id field in res_config_settings, which
instead defaults to setting the field to NULL, which violates a not-null
constraint and therefore causes issues when trying to modify/save
settings.
To solve this, a hard delete of the ir_model_field website_id is
performed during the uninstall process of the website module.
Fixes#21905
OPW 803018
Before this commit, in the event that the admin user has set the language
to english, but the COA's target company had a different language,
the admin user's language had been taken instead of the copany's one
for the translation of journals and other coa intialization stuff.
This is wrong as the CoA is more connected to the company, than to the
user, which could be a functional support user that just happens to prefer
the english version over the local one.
Now, we ensure in two neuralgic places, that the company's language is passed
to the context and therefore picked up by the translation's GetTextAlias.
Signed-off-by: David Arnold <dar@xoe.solutions>
Purpose
=======
Currently, only single people are considered as isolated people.
Specification
=============
Widows and divorced people should also be considered as isolated people.
Aaron Bohy