- Some fields were simply missing on templates, making impossible to give them a value on chart template installation.
- Added a real link between account.reconcile.model.template and its chart template instead of using account_id.chart_template_id
- Added tests for checking the consistency of those objects in the future.
The account payment widget did not work at all, since we pushed the new
views. With this commit, we adapt the code to the new views (note: the
file account_payment_widget was renamed in account_payment_field).
Currently the link is always the website link once website_portal is
installed. However it is better to use the generic /mail/view controller
that chooses the right redirection depending on the user trying to access
the document.
get_formview_action is now called as sudo to avoid access rights issues
when browsing it and trying to determine the ID of the form view to
display.
However in some cases it can be interesting to know the real user trying
to access the form view. The original uid is therefore added as parameter
of the method to have the best of two worlds.
In 9.0 the argument pay_journal in function pay_and_reconcile must be an id
but in 10.0, pay_journal must be a recordset with one element. So it was
not possible to call this method by rpc in 10.0
opw:725737
Before this commit, in the reconciliation widget, the reconciliation alert (exclamation mark) was displayed, even for amounts less than the total. It does not make sense, so we just hide it in that case.
When a partner has a lot of contacts, the computation of the issue total
takes a lot of time. Indeed, it performs the computation for the
partner, but also for all the children, despite the fact that the amount
is not displayed.
opw-726355
Currently the amounts of all invoices (linked to sale or purchase
journals) is summed regardless of these invoices being bills or
refunds, this means e.g. if you create an invoice for 1000 then a
refund for 500 on this invoice, the dashboard will display an
"awaiting payment" total of 1500 which while technically correct is
not really logical or helpful from a user's POV.
Fix summation to take in account the invoice type (invoice or refund)
and remove refund amount from the total amount.
Intent validated by @lap-odoo, also not ignoring or removing refunds
from count to avoid situations like "0 Awaiting Payments [for] $-1200"
which would be really strange.
OPW-728860
In Python 3, `raise` can take:
* nothing (reraises)
* an exception *instance*
* an exception instance `from` a traceback
The Python 2 forms `raise type, instance` and
`raise type, instance, traceback` are deprecated and should be replaced.
Fixers:
libfuturize.fixes.fix_raise
#8530
Currently applying a color to a kanban item applies it to the whole
card. This creates usability issues as the content is not dynamically
updated to match the chosen color.
This commit proposes to apply the color only to the header and let the
card content standard. It helps designing cards that are always usable
and readable.
SQL that retrieves data for the "Due Payments" report doesn't include
any filter for excluding AR/AP move lines already reconciled, which
shouldn't be presented in this report.
Courtesy of Pedro Baeza. Was PR #16440
Different method use self._context.get('lang', 'en_US') to get the lang
value but, the lang in the context can be set to None (eg: copy method).
When the context is used with a lang=None, the method can have a
unexpected behavior or crashed (eg: if you try to format a datetime with a
locale=None)lang can be None
Different method use self._context.get('lang', 'en_US') to get the lang
value but, the lang in the context can be set to None (eg: copy method).
When the context is used with a lang=None, the method can have a
unexpected behavior or crashed (eg: if you try to format a datetime with a
locale=None)
When reconciliating manually, it may be possible to filter between
`All`, `Customers`, `Suppliers`, `Others`.
When changing this mode, we could end up in a situation such as:
1)
- reconciliation widget X is available
- reconciliation widget line XB is being loaded
- mode is changed -> reconciliation widget X is removed
- reconciliation widget line XB loading finishes
-> error because the parent reconciliation widget exists no more.
2)
having no (or less than the expected) or too few results because
removing reconciliation items (when for example we switch from supplier
to customer mode) can be done asynchronically. But the code expected it
to be done synchronically. Also all elements displayed were removed
instead of only the ones of other types.
thus instead of displaying the expected number of reconciliation items:
MIN({num of record to display}, 10)
the records displayed were:
MIN({num of record to display}, 10 - {num records displayed before})
which could amount to 0 event if there was thousands available ones.
This commit solves these two issues:
1) by not adding line to a reconciliation item without error,
2) by counting and removing displayed items correctly
opw-725796
opw-728309
* account, mail, sale
Since the views refactoring, modifiers were not properly handled
anymore (readonly/required not recomputed, use of readonly/required
of "python field" instead of "view field", ...). This commit tries to
implement a system which allows to handle the modifiers (re)computation
the same way for all the basic views.
For this to work, many specialized renderers behaviors have been moved
to the basic renderer so that more mechanisms are shared (especially by
the form renderer and the list editable renderer). The list editable
renderer is hugely impacted by this commit.
Here is a list of key changes:
- The basic renderer now has a `_renderFieldWidget` function which is
used without modification by the form and the list renderers.
- Modifiers have to be registered thanks to the basic renderer
`_registerModifiersData` function (this is done automatically for
fields by the `_renderFieldWidget` function for example).
- All instantiated widgets are accessible, organized by record, and
ordered in a special basic renderer variable.
- The code which resets the widgets of the form view and the code
which updates the row of a list editable view is now shared in the
basic renderer and now also automatically updates the DOM according
to the reevaluated modifiers.
- The last point has an huge impact on list editable renderer: all the
widgets have to be instantiated when editing a row (even readonly and
invisible ones) as they can be switched to editable/visible during
edition (after a modifiers update).
- `replace_element` and `readonly` options of `AbstractField` are
useless: widgets are now always replacing the list editable cells
in edition and the `readonly` widget mechanism is replaced by the
notion of 'focusable' widgets.
(see `AbstractField.getFocusableElement`)
- The 'tab' navigation mechanism is impacted by the previous point,
some code sharing have been done in basic renderer for this too.
- `AbstractField` does not care anymore of the 'required' status, this
is the view responsability to check that a required field has a set
value on save.
- Some list editable bug fixing (e.g. it was possible to edit multiple
rows at the same time, it was not possible to navigate towards the
previous field, crash on o2m add an item click, ...)
- The mockserver now properly simulates server modifiers computation.
- ...
Note: list editable style may be worse than before this commit but a
CSS update is coming in a few days.
The client must receive the tzOffset to apply this on all hours.
To use the date picker we must change the date to apply the change
in the user's tzOffset, without this change the result is wrong.
For datetime widget we must change like it to avoid max stack error.
The server send the tzOffset, if it's undefined, by default the client
use the browser time offset.
Every test are change to use tzOffset.
A test is added in calendar to use the click by position for the
fullcalendar lib. This test create and drag and drop an event to check
timezone error and error when we use default value in the context.
Use formating date like 2026-04-04T08:00:00Z instead of 2026-04-04 08:00:00
is important for phantomjs, because it's crash without information if the
formating is not the standard format.
For the parsing, when the client receive a server date the date is utc
formating but when it's parsed from the client is in the user's timezone
button will only be visible if the move_line are not reconciled yet
This button will allow user to register a payment and then reconcile it with multiple invoices in the payment matching view.
Was PR #15157
Demoted to library in Python 3, see if uses can be replaced by more
specific construct, just import functools.reduce otherwise.
Futurize fixers:
* lib2to3.fixes.fix_reduce
`makeRecord` is now asynchronous as it will load data
for relational fields (X2manys and many2ones if `display_name`
is not fetched).
This change has implied a refactoring in all `makeRecord`
occurences to adapt with the returned deferred.
qdp-odoo