Here is what could happen before this commit: open a record (let's say
project.task) in form view. Then, on the sidebar (actions), choose
Merge Selected Tasks), choose a task, and click on Merge. What happens
next is a traceback.
Here is a more precise description of what happened:
- the formview dialog for the merge action closes, which triggers a
reload for the main formview
- the merge action returned an action description for an act_window
- the action manager instantiated a new viewmanager and prepare the form
view, which is an async operation (need to load some data to display
the form)
- the previous view manager (initial one) completes its reload, which
makes it rerender the view, which triggers a DOM_updated event
- the new view manager see this event, and tries to call getScrollTop on
the current view controller, but there are no controller yet, it is
not ready.
We could argue that some of these events should not happen (for example,
if we will open a new view manager action, why do we reload the current
view manager?). But solving these issues is a more deep architectural
problem (we probably will rewrite the actionmanager/view manager layer
at some point).
It could also be argued that in any case, the method getScrollTop should
not crash (same for setScrollTop). Sadly, these methods are fragile,
because some changes in the loading behaviour of a view may break them.
So, in any case, protecting them against unexpected traceback is a
worthwile investment.
With this commit, we just slightly improve list benchmarks, to make them
go through a wider variery of code.
Since we aim to use these benchmarks to track changes in performance
through various versions, it is useful to have a good version in
saas-16.
When we are on a partner form view, we get the total invoiced containing
the child contact of the current partner. But when clicking the button
we only see the invoices of exactly the current partner.
In most locations of the code this has changed (since 347c784da) and
this part should also contain the descendants contacts.
opw-744929
closes#17188
In the case of a chatter on a calendar virtual event, there was a number
of issue because the record ID was of the type "[REAL ID]-[VIRTUAL ID]".
This caused issue when fetching and posting message with the composer.
opw-744405
closes#17179
-> Move Subtasks mechanism from hr_timesheet to project.
-> Various functional improvements:
- Add new 'Sub-tasks' setting and 'Sub-task Project' field based on
this setting.
- Relabel 'Team Collaboration' section to 'Task Management'.
- Remove 'Customer Satisfaction' section and move setting
'Rating on Tasks' into 'Task Management' section.
- Add customer name on the project's kanban view.
- Set default value of 'Sub-task Project' field is the same project.
- Add 'Parent Task' stat button on task form view.
- Make 'Sub-Tasks' stat button visible when no parent task
Before doing an onchange in a x2many, the basic model tries to evaluate
if the line is valid or not. In that computation, we used the
field.required property instead of using the required modifier. This
commit had to move the modifier handling from the BasicRenderer to the
BasicModel, in order to use it in the _isX2ManyValid method.
Revert "[FIX] account: reset the move reference on bank statement"
This reverts commit 6de2990f8d.
The previous patch was removing the reference of the move.
However, the reference is useful to reuse the name if the line is reconciled
again.
Instead, remove the constrain. To delete the move, account_cancel is already
needed. It is useful to allow removing statement lines to match the statements
form the bank and the one on Odoo.
In the future, allowing to set the amounts to zero should be added as a way to
correct the lines.
opw-741205
In the extended template `HiddenInputFile` there are actually two inputs
(one for image only and another one).
This widget needs to replace both of them otherwise the file selector will
be opened twice.
This rev. fixes the next three bugs:
- the dataPoints representing each group didn't have the parentID
attribute set
- when quick creating a record, the res_ids and count attributes
of the group, and of the parent weren't correctly updated
- when quick creating a record, the environment (view_manager)
wasn't correctly updated
The combination of thoses bugs produced the following crash. Open
a grouped kanban view (e.g. project.task), quick create a record,
open that record in form view (note that the pager was wrong, it
indicated 0/x, where x number of records), delete the record ->
the form is supposed to load the next record, but it
crashed because it couldn't get its id (trying to read id null).
Before this rev., the dashboard wasn't rendered correctly when
the same action (same action id) was several times in the
dashboard.
For instance, if the dashboard contained the list and kanban view
of an action, both views were rendered in the same block, leaving
the other one empty. Moreover, (un)foldeing one automatically
(un)folded the other one.
This was because the action id was used to identify each view, but
this id is not unique in the dashboard. We now use a generated id
instead, which is unique.
Before this commit, it was not possible to set the 'html' widget
for a field in Studio.
Even if this is the default widget for the form view, it not the
case for the kanban view. You need to precise each widget you
want to use (for performance reasons).
opw-744254
- Set-up multi-currency with the following rates:
MXN: 1.0
USD (2017-04-10): 0.052632
USD (2017-04-27): 0.051680
- Create an invoice of 1779.55 USD on 2017-04-10
- Register a payment of 1779.48 USD on 2017-04-27
- Set the invoice as fully paid
It is impossible to validate the payment because of the following error:
"The amount expressed in the secondary currency must be positive when
account is debited and negative when account is credited."
We make sure to align the writeoff amount sign with the writeoff amount
sign in the company currency.
opw-741520
The snippet options are attached to `closest`, `all` and `is` functions
to be able to find/check DOM they are associated to. Their behavior
depend on the snippet option type: the search in the DOM is either done
in the body, the editable parts, the editable children only, ....
The problem is that when searching from a given DOM element, jQuery
won't match the elements whose selector contains this given DOM element.
Or in code terms, jQuery find function behavior is:
`$('A').find('A B')` <=> `$('A A B')` (not `$('A B')`)
This was indeed a problem on the job position apply form pages where the
main editable element is the <form/> element itself. Indeed, the snippet
options' selectors which began by 'form' were not able to match. Worse,
the selector is used for a jQuery search for drag & drop and saving but
not for initialization (where it is used as a `is` check on clicked
elements). So, some DOM were able to be modified by options but not
properly (re)configured before saving.
opw-705902
opw-741305
The structure of the product.{product,template} form is the following:
product.product_template_form_view* (both)
|-- product.product_template_only_form_view* (template)
| \-- stock.product_template_form_view_procurement_button
|
|-- product.product_normal_form_view* (product)
| \-- stock.product_form_view_procurement_button
|
\-- stock.view_template_property_form (both)
Previous view was adding weight, volume fields on both view with a attrs that
applies only to the product.template (display only if no template).
This means that the weight was not displayed on product.product form if opened
from a Many2one (using the default product.product view) while the attrs should
not hide it.
Closes#16541Fixes#16428
In a scenario with the following views:
Mod A, view 1*
|-- Mod B, view 2
\-- Mod B, view 3*
view 3 can not rely on the elements added by view 2 in xpath
If view 3 is a primary view, view 1 must be fully resolved first (apply view 2)
before resolving view 3.
Next commit describes a real use-case with product.
Linked to #16541 and #16428
Previously, it used to reload its data when the user clicked
multiple times on save, even though there were only changed
fields during the first initial save, all the other queued
ones have no changes at all and, as such, should not trigger
additional reloads.
Previously, it was possible to click multiple times on stat
buttons while still waiting for the result of a previous button
click. This could end up with the web client in strange states
or, worse, lead to tracebacks. Because of this, we decided to
disable the buttons once one of them is clicked and restore
them afterwards.
By doing this, we encovered a place in the code where a failed
deferred would not be properly forwarded back to the caller,
which meant, in our case, that the buttons would not be
enabled back in case the action failed. This is now fixed.
Initial methods to fix this issue used to break the test below.
Because the label of the assertion this used to break was
contradictory with the value it was actually expecting, we
decided to fix it as well.
Previously, the buttons were not updated properly after discarding
from an editable list view. The user was stuck with "Discard" even
though there was nothing to discard anymore, and he could not create
a new record either since the "Create" button was invisible.
This was fixed by 3aad756. I originally did a different fix which
has since been rendered useless, but the tests I wrote are still
meaningful since they are testing a different case than the commit
which fixed the issue.
When a membership is created, a redirection is done to the tree view of
the vendor bills. It should be the tree view of the customer invoices.
opw-743241
Languages like Arabic (ar_SY), Hindi(hi_IN) do not use english digits to describe dates, and moment.js format function will keep these characters. So, the server will get date strings, and will be unable to use them.
To see the problem, just type moment().locale('ar_SY').format('YYYY-MM-DD') into a browser console.
In this commit, we simply force the locale to 'en' before sending data to the server.
PR #17156
- Rename "Validate" button to "Test Import"
- unmatched columns are marked in red
- better column matching (show suggestions of the char field even if the imported values are of int type)
PR #16881, close task 32894
Introduced at 4e715dae94. Instead of
doing hacky things like self.pos.gui.screen_instances... in the
cashier widget to force the numpad UI to rerender itself it's better
to use Backbone.js because:
1. we're already using it everywhere else to handle UI updates
2. easier to extend for eg. adding more cashier related access rights
To do so cashier is turned into a Backbone attribute on PosModel. All
references to the cashier property are replaced with get_cashier to
ensure the Backbone attribute is used.
Note that this is not necessary for the user property on
PosModel. This contains the actual user logged into Odoo and thus
never changes.
This also removes the check in set_unit_price because:
1. it was wrong to begin with (no price change when
restrict_price_control is enabled or you're a manager?)
2. even if fixed it would break the following for non-managers:
1. tipping
2. fix_tax_included_price
Purpose
=======
The menu "Sales -> Invoicing -> Orders to invoice , shows the orders which are confirmed and where the invoice needs to be created for those.
User should not be able to create SO from this menu.
===========
Specification
===========
Remove create Button in (Order to invoice and Order to upsell) menu and in website -> order to invoice
Before this commit, it was only possible to click on input to
change the value of the many2many_checkboxes widget.
For better consistency, we must allow to click on labels.
The motivation for this commit was to fix a wrong evaluation context for
x2m fields: it was using a list of res_id, which may contain virtual
ids.
For example, it could be seen in the form view for journal entries:
adding the first line (field line_ids) was fine, but clicking on 'Add an
item' a second time caused a crash. The reason was that the line_ids
was explicitely added to the context in the view, and the second time we
add a line, the web client sent a list looking like this [35,
'virtual_43'] to the server, in the nameget context.
The proper behaviour is to send a list of commands for those fields.
This means that we had to do some non trivial changes in the
getEvalContext method: we stop using the get method with raw: true. It
was nice to use the same method, but the eval context is actually
different that the values returned by the get method. That was the
motivation to introduce the 'noUnsetNumeric' flag, but now, we simply
create another method and let each method do its own work.
TLDR: eval contexts are hard...
Purpose
=======
As you can easily edit your stages via your kanban view, this menu item is not necessary
Specification
=============
Following configuration/stages menu Move to debug mode
List of menu:
Quality/Configuration/Quality Alert Stages
PLM/Configuration/ECO Stages
Events/Configuration/Track Stages
Project/Configuration/Stages
Maintenance/Configuration/Maintenance Stages
Recruitment/Configuration/Stages
Email Marketing/Configuration/Campaign Stages
The inner ’.s_parallax_bg’ element has a negative z-index value to be
rendered behind any other inner content.
This may cause the element disappear, because z-index is evaluated on
the entire page.
This commit will restrict the ’s_parallax_bg’ behaviour at snippet
level, assigning a z-order to the container too.
``import odoo.addons.foo as bar`` doesn't seem to properly trigger the
import hook in Python 3 (it blows up on decimal_precision and
base). Thus convert *all* examples of that pattern to the more
sensible ``from odoo.addons import foo as bar``.
sum1201