When having an automated action which
triggered upon changing a field to write on another
(no python code, but operatiing with ir.server.object.lines)
Before this commit, the onchange was not performed.
This was because there was no active id
(in fact the code did not take object(<NewId>) into consideration)
After this commit, the onchange is performed.
OPW 801424
The space available for the house and room number is specified by the label size
House Number<field>Door Number<field>
takes max one column of size (about 147px) so makes the field very small for input
Rename the labels to make it smaller
Fixes#21927
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
In order to really test a production environment we have to ensure
some mail related config parameters are set. This has an impact on
some tests.
Which is strange is that it lessens query number of a test that
already uses those parameters. Maybe XMas spirit.
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
Thread mixin class adds a message_last_post field. This field may be
updated when a comment is posted, depending on a context key. Since a
while this context key is not used anymore. This means the field is never
updated. As it is used only as a filter in project we decided to remove
it.
This commit remove the field and the context key support. This kind of
specific feature can be done using customization if necessary in some
advanced use case.
* web, website, mass_mailing
Before this commit, the editor allowed defining the margin of some
elements and the height of some elements. There were three main
problems with this system:
1) When an user dragged the arrow, he often expected to change the
size of the element while he was in fact changing the margin
2) When changing the margin, you increase the space between two
elements but with a white space (while most users want a space
with the same color of the block they are resizing = padding)
3) When changing the height, the user was able to hide snippet parts
and the height was not consistent accross screen sizes
Now, the only thing you can edit is padding. There is only one arrow
for each direction, which allows increasing spacing and consistent
dimension at the same time.
The only feature that is lost with this change is the ability to
control vertical alignement of colored columns. This is not a problem
as colored columns are rare in our current snippets and there still
have the possibility to add margin classes by hand if necessary (there
are also plans to control vertical alignement another way).
Note: margin classes are kept for compatibility.
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
When reinitializing modules it is impossible to create partners if
purchase is installed because purchase_warn field has a required
column but no default value if the module does not depend from
purchase. Use case is trying to run test_mail tests with purchase
installed.
As this field is not business critical it is now not required. As there
is a default value behavior should not change for users.
See also 71181a0e39, dd47abdcc3 and 06a02ae4c2.
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
The "Customize Theme" modal was displayed under the main navbar since
the introduction of the affix feature (especially in some themes). This
is because the main navbar's z-index has been increased for animation
reasons.
In fact, the fix seems simple: the customize modal does not need any
z-index override (it should behave like any modal).
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
Christophe Simonis