Current behaviour when duplicating a record:
apply copy override in the user language (e.g. "%s (copy)")
copy the previous term in all the other languages (including)
So if product was named:
cheeses (en)
kaas (nl)
fromage (fr)
Duplicating the product, while in French, will result into:
cheeses (en)
kaas (nl)
fromage (copie) (fr)
This is a problem if there is a unicity constrain on the field, it will be
raised (there is already a product named 'cheese')
After this PR:
Duplicating the product, while in French, will result into:
fromage (copie) (en)
kaas (nl)
fromage (copie) (fr)
This applies **only** if there is an override of copy
This is detected by comparing the old and new value for the user language
Fixes#7010Closes#22052
In march 2017 saas-15 on activity message, the create_uid was displayed
with 26940f8d.
In november 2017 saas-14 an activity was always created sudo() with the
change 53ad585bf.
Thus in saas-15 we always have "planned by Administrator for {user}"
not making sense.
opw-804409
closes#22113
1. Create a new user with all the permissions as manager (or at least
Accounting) except Inventory
2. Login and then go to Invoicing --> Settings
3. Do a minor change, save
An access error occurs.
Since the settings of all modules are smartly loaded in v11, it now
implies that a user must have extra manager access rights to be allowed
to save them. We could have kept separate actions for each setting page,
but we would have missed the fun of access errors.
Anyway, security-wise this is not an issue to force the manager groups
since a user with 'Settings' access rights can change his own rights.
It's just very annoying. Or fun.
Complement of aa65a46fc5Fixes#21766
opw-801210
When you create a down payment invoice from an SO, the product that is used in the line is 'Down Payment'.
The description of this product, which is visible for the customer, was not translated to the language
of the customer in the SO and in the invoice. It was translated to the language of the user logged.
This fix is made to keep the same behavior for the description of an SO line and for the description
of the invoice line.
opw:803977
- Steps to reproduce the bug:
Go to events ->Duplicate an existing published event
Try to publish that new event
- Bug:
You get redirected to the previous event webpage, which is already published.
Unable to publish the event from that page.
The url used to access the event is computed the function _compute_website_url which
a slugify of the display_name of the event.
opw:804118
- Define a Component A tracked by lot.
- Define a Final Product B tracked by lot.
- Create a BOM, e.g. 5 units of A to produce B.
- Get some quantity of A in a sub-location, e.g. 'WH/Stock/Shelf 1'.
- Create a MO for 1 unit of B.
- When clicking on 'Produce', record 6 units consumed instead of 5.
- Post the inventory
5 units of A is removed from 'WH/Stock/Shelf 1' and 1 unit of A is
removed from 'WH/Stock'. The latter might create a negative quant if no
stock is available in 'WH/Stock'.
When the extra move line is created, it is created using the data of the
stock move (in `_generate_consumed_move_line`). When posting the
inventory, the quants selection is made strictly in the location set (in
`_update_available_quantity`), which might cause the mentioned negative
quant.
The solution is to select a sub-location where the product can be found.
This gives a higher chance to avoid negative quants afterwards. Note
that if we wanted to avoid negative quants, we could make a reservation
process on the move, and potentially create several stock move lines.
This is beyond the scope of the integration of MRP with sub-locations.
opw-803969
Code to thumbnail payment icon image had an error for python3 because
from RPC the image would be a text string instead of an expected
bytestring.
This change accepts both and made another small fix in the view since
image_medium doesn't exist (and image is already thumbnailed).
A third fix was that removing an image caused an error.
opw-803722
closes#22088
Binary fields were simply shown simply by their textual representation in list views,
e.g. the base64 string.
There was no formatter for binary fields, therefore it has been implemented so that
it displays its estimated size.
Binary fields in list views had a download link in v10.0.
We provide this feature back by means of a widget called 'download_link'.
It is also possible to define an option to set the field name having the filename as its value.
Example:
<tree>
<field name="fname"/>
<field name="datas" widget="download_link" options="{'filename': 'fname'}"/>
</tree>
with the following record: {fname: 'document.txt', datas: 'Cg=='},
we get a file named "document.txt" by clicking on the download link.
Closes#21996
Steps to reproduce the bug:
- Create a bom with lines
- Change on one product in product view form the uom with diffrent category (exemple : unit -> meter)
- Create un manufactoring order : you have an error You try to move a product using a UoM that is
not compatible with the UoM of the product moved. Please use an UoM in the same UoM category.,
the error message doesn't give with product there are an issue. (
if you have hundred of line in your Bom, it is very difficult).
This fix improves the error message.
opw:800328
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.
Christophe Simonis