Before this rev., when the user opened a form view
containing a pad widget, with a pad url already configured,
a dialog directly popped asking "The record has been
modified, your changes will be discarded. Are you sure you
want to ?".
This is because of an unconventional behavior of this
widget: the field actually encodes an url, the one of the pad
to display. When the user saves, a write is forced so that
the server can retrieve the pad's content and store it in DB.
To force the write, the widget always notifies a fake change
on the url. However, we don't want this change to trigger
the confirm dialog. With this rev., this fake change doesn't
make the record 'dirty'.
*account_asset
When a button of type 'action' is clicked (execute a given action),
special keys must be set in the context (active_id, active_ids and
active_model). They must be computed regarding the record containing
the clicked button, i.e. if we are in a modal, it must be the id
and model of the record displayed in the modal.
Before this rev., we always sent the id and model of the record
displayed in the background (i.e. the id and model of the url).
This caused a bug in MRP that could be reproduced as follows:
- open a manufacturing order in form view
- click on edit
- click on one of the line of the one2many, and click on the green
icon to edit a product
- click on the update product quantity button on top of it
- the product field must be correctly filled, which was not the
case before this rev.
Date fields have magic grouping methods to specify how to group on
them like date:month, date:weeks, date:days for example. It needs
to be handled properly since date:month is not a valid field name
but date is.
Steps to reproduce the issue:
- Go to Sales/Dashboard
- Click on My Pipeline
- Group by "Creation Month"
Basically, this can be triggred from any view which has a search
view which defines a group using the magic date grouping methods.
Rev. c5bd509274 attempted to improve the
pad sync mechanism when merging records (tasks), but failed to consider
the case where the pad_url field is not set yet.
This happens at create(), due to the chicken-and-egg problem with the
pad URL depending on the record ID, and therefore set *after* creation.
Ignoring the sync when the URL is not yet set should be enough, as the
URL generation method also takes care of that first sync.
In the main_flow_tour, we edit a related record of a many2one in a
one2many. A modal is displayed and we make some changes. We
then click on 'Save' in the dialog. The next step is to add a new record
in the one2many, so we click on 'Add an item'. However, we didn't
wait for the modal to be closed before clicking, which is actually not
possible in practice (because of the modal backdrop).
This made the tour fail when run from the browser, since commit
c300e5e, which produces a redraw of the line containing the
many2one that has been edited.
This rev. ensures that we wait for the modal to be closed before
adding a second record.
When a replying to an email, the matching alias should first verify access
via the parent record if exists (i.e. check on the project instead of
on the issue itself).
The new "My Activites" filter introduced by rev. 87e457158e
should not be in the same group of the search view as other activity
filters (Overdue/Today/Upcoming), otherwise they are combined with OR
instead of AND.
This is particularly misleading when coming from the Sales dashboard, as
the "Overdue" button of "My Pipeline" will lead to a list of
opportunities with "My Activities OR Overdue Activities", showing *all*
opps with overdue activities, not just yours.
Such buttons are not going to work on records that actually do not
exist yet. The behavior is now the same as in saas-15.
Steps to reproduce the bug:
Steps to reproduce the bug:
- Enable lots in Iventory
- Choose a product which is a component of another (through mrp bom)
- Set this product as tracked by lot
- Set this product inventory quantity to 0
- Create a new manufacturing order for the product for which it is a
component
- Click on "Check Availability"
- Click on Produce
- Click on the little square with a + in the m2m list view, the
server will crash in the ensure_one of the function called by
the button since there is no record to run it on.
Previously, we did not handle the case where the result of the m2m
default get was a new record. In this case, we can't just send a
replace all command giving the ids since the new record has no id.
We decided to keep the replace all command even when it is empty
to stay consistent with the o2m implementation, even though saas-15
did not behave like that.
Steps to reproduce the bug:
- Enable lots in Iventory
- Choose a product which is a component of another (through mrp bom)
- Set this product as tracked by lot
- Set this product inventory quantity to 0
- Create a new manufacturing order for the product for which it is a
component
- Click on "Check Availability"
- Click on Produce
- You'll get an error as the id given to the onchange is a virtual one,
rather than a create which would not include an id.
Previously, it used to create a virtual datapoint even though there was
no change on this field. If the field was a many2one, this datapoint
triggered a name_get call afterwards, but giving the virtual id of
the datapoint since there is no real record. The solution is to avoid
creating a virtual datapoint when it is not needed at all, thus fixing
the wrong name_get call.
Steps to reproduce the bug:
- Enable lots in Iventory
- Choose a product which is a component of another (through mrp bom)
- Set this product as tracked by lot
- Set this product inventory quantity to 0
- Create a new manufacturing order for the product for which it is a
component
- Click on "Check Availability"
- Click on Produce
- You'll get an error as the web client tries to fetch the name_get of
this datapoint even though the record does not exist.
Unfortunately, ed60339 is incompatible with ebd1721 since
we once again do not send the values of readonly fields.
This is a partial revert of commit ed60339.
Onchange RPCs return an object that may contain a 'domain' key.
When it does, its value is an object whose keys are field names and
values are the new domain for the corresponding field.
Commit 8473bde8 added the support of the 'domain' key, but stored
it directly in the fieldsInfo (an object gathering information of
the fields in the view, and which is shared between all records).
This was wrong as the domain isn't necessarily the same for all
records. To reproduce, with the UOMs activated, go to Sales >
Quotation, in the form view, add an order line, set a product
(e.g. Graphic Card), the onchange sets the domain for the uom
field (matching uoms like 'unit', 'dozens'). Add a second line
with a service product, the onchange returns another domain for
the uom field (matching uoms like 'hours', days'). Click again on
the uom field of the first line, the domain is the one of the
second record, which is wrong.
This rev. directly stores the domains returned by the onchange on
the object representing the record, so that this information isn't
shared between records anymore.
Before this commit, it was impossible to load the x2many fields subviews when
they were not defined inline.
Now it is possible to call the method "_loadSubviews" to do so.
Used mainly in studio, to be able to display the x2many fields without inline
views.
Before this revision, editing a many2one inside an x2many field did not
cause an update of the x2many field upon saving. This is due to the fact
that a field on a screen was deemed affected by a record change only if
its value or a directly related record has been updated.
This present revision looks for changes recursively, thereby including
the case where an x2many field contains a many2one.
The bug appeared for example in Manufacturing, when editing the product
name of a BOM line.
* [FIX] Gamification: email template
- realized that the pictures of users were not public by default,
which means src with an url won't work if not connected to the database.
This is fixed by embedding the pictures directly in the mail.
* [FIX] Gamification: challenge template
- fixed layout problems with what works in the renderer.
Since the switch to the new views, clicking on a 12am cell in a week
view of calendar triggers a traceback. A similar issue happens when
creating an event at 11.30pm. This is due to the fact that events
starting or ending at 12am are suspected to be incorrect and are thus
checked against the database.
This commit fixes both issues, by requiring that database checks be
carried out only if the records actually exist in the database.
The rev. https://github.com/odoo/odoo/commit/99ae418bf24171fbc6bb27584059c27efb857e77
introduced a trigger_up `mutexify` when quick creating a record in a many2one ;
this broke the behaviour when the many2one was standalone (because it has no
BasicController and mutexify is handled in the latter).
An attempt to fix this issue has been made in the rev. https://github.com/odoo/odoo/commit/e83c3e2678500c9bf2c17b4d23ae9a294ebafaa7
by adding an option `standalone` in the field widget options. In this case,
the action was directly executed instead of the trigger_up. While this correctly
works, this implies that the option needs to be added in every standalone
many2one (and only many2one as the others won't use the option), which is not
very convenient.
An other attempt is made in this rev. by moving the mutexify handler from the
BasicController to the FieldManagerMixin ; as a widget that instantiates a field
widget needs to extend this mixin, both cases will work and we won't need to
specify the option anymore.
This commit thus partially reverts the rev. https://github.com/odoo/odoo/commit/e83c3e2678500c9bf2c17b4d23ae9a294ebafaa7
When creating a customer invoice with description/reference with more than
64 characters, the description was cut to generate the name of the account move
lines. But it's possible to create an entry with more than 64 characters as name
by the interface. The limitation is deprecated.
opw:760316
On a list view, if we group records the arrows and changing page
feature are disabled. But if then we removed the grouping, the arrows
never reappeared.
note: not necessary as of 9.0 it was already solved in 1280bf251
opw-760956
closes#18596
the field data-max is supposed to be stored in the database.
Currently, the arg is 'stored=True' which is not recognised by the orm.
This fix ensures the field is correctly sotred and thus not computed at reading.
Add into the warning message the list of stock.move that raise the constraints
error.
When you create an 'Inventory Ajustment' of 1000 lines and see this error,
it is not easy to find which product could cause the problem.
This solution is not perfect since the name is not uniq, but it decrease
drastically the number of record to check manually.
opw-760643
UserError uses a retrocompatibility function 'except_orm' which one can take a
second parameters. The default value of this second param is None, so if we
don't force an empty string, we will see a None on each raise UserError as last line.
When returning a delivered product with a non internal location,
the delivered quantity on the SO was not updated.
Steps to return a delivered product:
- Click on button "Return" on stock.picking
- Check the refund box
- Click on return
PS: for the field return location, you can choose a child location from
WH/stock. So it can be a not internal one.
opw:749610
When "No message" is set on field purchase_line_warn/sale_line_warn,
the message doesn't have to be displayed in the respective field
purchase_line_warn_msg/sale_line_warn_msg.
opw:760801
When I did efd15852, I accidentally undid d20074c5. That commit
wanted to filter out unwanted values from the action context, but
it was too violent, as it was discarding the action context. (See
bug described in efd15852)
My original commit aimed at avoiding the filtering of the action
context by having it devoid of unwanted values altogether. The
idea was "if this is an action button, we don't want the element
context". However, the default behavior of the _getContext function
was to add the element context. There were options to force to add
the element context despite being in a case where it should not be
added, but we needed the opposite: do not add the element context.
We used "additionalContext" in this fashion, the idea was: "if I
give you specific context values, don't polute it with the element
context". This was efd15852.
However, not all actions have context defined explicitely in their
definition. In this case, since additionalContext was undefined,
the element context was added again, despite our will not to add
it for actions. We solved this by simply always giving an
additionalContext to getContext, providing an empty one if needed.
To reproduce this bug (which is the same as efd15852):
- Go to Manufacturing
- Click on menu Master Data then Products
- Open a product
- Click on the "Bills of Materials" stat button
- Click on create
- The create crashes because of the "default_type" context key
that is erroneously passed from the "Products" action to the
"Bills of Materials" stat button action.
Jérome Maes