In the normal course of saving-action, readonly fields are stripped
out when sending data to the server. The SSF would reuse the same code
when "saving" O2M lines to the parent record however that is not
correct and would lead to misbehaving views as readonly (non-stored)
fields used as "transients" (storing data within the extent of a
record's edition session) would not behave properly.
Fix by overriding the O2M Form's save so that readonly fields are
kept and stored in the parent record.
Closes#23620
This rev. extracts two rendering parameters for the groups
corresponding to the default col value to apply (for inner and for
outer groups). This allows to easily override those default values
in extentions of the FormRenderer (for instance, in the renderer
of the new Dashboard view).
This rev. refactors the way the view's arch is parsed in BasicView,
so that it can be extended specifications of the BasicView to
handle other tagnames that 'field' (which is basically the only
one handled in BasicView).
This rev. extracts the part of the rendering that renders outer
groups (i.e. groups that contain groups) in its own function. This
allows extentions of the FormRenderer to use it (for instance, the
renderer of the new Dashboard view).
This rev. introduces an option to doAction (keepSearchView). If set
to true, the searchView of the current action will be kept and used
by the new action (this only works if there is already an action
with a searchView, and if the new action is stacked over that one).
This is necessary for the new dashboard view.
A better solution would have been to export the state of the
existing searchView, and import it to the new one, but the current
implementation of the searchView doesn't allow to do that easily.
This will be done as soon as the searchView will be rewrote.
This rev. allows to add or remove filters to the SearchView from
the outside, and to make it display this new domain. This can be
used by views that trigger domain changes (e.g. this is the case
of the new DashboardView).
The graph view uses the nv(d3) lib to render the graph. This lib
requires that the rendering is done directly into the DOM (so that
it can correctly compute positions). However, the views are always
rendered in fragments, and appended to the DOM once ready (to
prevent them from flickering).
Before this rev., the graph view circumvented this by performing
the rendering in a setTimeout(0), letting the framework append the
widget to the DOM first.
This rev. removes this hack and uses the on_attach_callback hook
instead, which is called when the widget is attached to the DOM.
This ensures that the rendering is always done in the DOM, and we
keep the rendering part synchronous.
Correct account invoice line form view so studio doesn't fail on
something that doesn't seem really correct (and somehow worked thanks
to pyeval implementation or the override from another view type).
opw-1826254
opw-1830171
closes#23997
On 'My attendance', do some check-in/out operations
while on the server side, everything was ok, the display had some issues:
On Chrome, that worked well whereas in Safari, it did not
since the Date() implementation only accepts ISO date strings
We take the opportunity of this fix to handle dates with moment.js, which accepts non-ISO formats
OPW 1831555
closes#23962
When creating sales/purchase receipt for a journal having a secondary currency, an error was raised as the amount_currency had the wrong sign (compared to the debit/credit).
Was Issue #1819396. Was PR #23768
Steps to reproduce the issue in 11.0 Enterprise:
- Go to the language English
- Remove from the time format the seconds
- Refresh the page
- Go to sales
- Create a sales order;
Bug:
- You get the warning message
closes#23596closes#22027
opw:1829577
When creating a timesheet, several fields need to be recomputed:
- `currency_id`
- `group_id`
- `department_id`
- `is_timesheet`
- `validated`
When `validated` is computed before the other fields, the recomputation
will lead to an `AccessError` because of the rule
`hr_timesheet.timesheet_line_rule_user`.
Since the test `test_timesheet_validation_user` expects an
`AccessError`, the test succeeds. However, from time to time,
`validated` is computed last => the `AccessError` is not raised.
Actually, a `ValidationError` should be raised in this case (from the
`create` override in `timesheet_grid`).
Before this commit:
Clicking on 'unstar all' button removes all messages from starred channel
but it only decreases the counter as many as there are displayed messages
on screen.
For example, if there are 40 messages starred, only 30 messages
are on screen (default limit) but unstar all will decrease counter
only for those messages instead of 40.
After this commit:
clicking on 'unstar all' button will correctly take in account all
fetched messages and not only displayed messages.
So now, after clicking on 'unstar all' button will update the starred
counter to 0.
task-ID: 33958
Previously, the ISR reference was computed from the iban number but it seems some banks (for example UBS) use arbitrary ISR references that needs to be manually set.
Was task: 40975
Was PR #22931
After this rev., in Discuss, messages are automatically loaded when
the user scrolls to the top of the channel.
Task 33958
Co-authored-by: Aaron Bohy <aab@odoo.com>
The code in res config that enabled or disabled internal operation type
did not take into account that active_test is set to False inside this
type of code since c2e259d8.
Thus a picking type of an archived warehouse would possibly unexpectedly
be enabled after saving the settings.
opw-1826196
closes#23956
The state of the JS documentation was quite sad, not updated in a long
time. With this commit, we rework a lot of the JS doc. Most notably,
we add a section 'Javascript Cheatsheet' (help on some common
customization tasks) and rewrite the 'Javascript Reference' totally.
Note that the JS reference page also contains a reference on all field
widgets.
This work is just the beginning, it is probably not complete, but at
least we will have a foundation.
The caller of `read_group` can now provide the aggregating function to use for
a given field:
# set aggregating operator for fields 'foo' and 'bar'
model.read_group(domain, ['foo:sum', 'bar:avg'], ...)
One can also aggregate the same field several times, by giving a specific
output name for each:
# aggregate 'foo' with both 'min' and 'max'
model.read_group(domain, ['foomin:min(foo)', 'foomax:max(foo)'], ...)
With project_issue installed, and when deleting an analytic account, a search
is done to check if there is linked issues. When the current user has no access on
the project.issue model, an error is raised. This check should be done as an admin.
Before this commit, when accessing the payment page with arbitrary amount
(/website_payment/pay?reference=Testinvoice&amount=150.0¤cy_id=6&country_id=)
A traceback was thrown because the keys concerning the partner were not present in the dictionary
that prepares the values for the form that we send to Stripe
Considering that those info are not mandatory for stripe (although not very good practice -- the more info the better to verify an identity)
we ignore them if not present
After this commit, the public route works fine
OPW 1832164
closes#23948
Before this commit, the smart button on the SO was computed
with only the SO's name field
In a multicompany setting, it could give up invoices from other companies
After this commit, only the invoices of the same company as the order are accounted for
OPW 1831551
closes#23925
To be able to retrieve the base amount of cash basis taxes lines, additional journal items are created for the base as well in the journal entry generated by the payment.
However, these additional journal items debitting and creditting the same account are considered as pollution in reports.
This module and hook allow to move these additional lines to an another account, if needed.
-task: https://www.odoo.com/web#id=35605&view_type=form&model=project.task&action=333&active_id=967&menu_id=4720
Was PR #23349
Steps to reproduce the bug:
-Create a tax of 21% tax included but don't select the "affect base" checkbox.
-Create another tax of 5.2% (no tax include)
-Create a sale order with a line that has a unit price of 121 and both taxes.
Notice that the total amount is: 126.2 (100 base amount + 21 from 21% tax + 5.2 from 5.2 tax)
-Click on "Print the proforma invoice"
Bug:
The total amount was still 126.2 and base=100, however taxes were wrong, there were 21 for the 21% tax
and 6.29 instead of 5.2 for the 5.2 tax.
Back-port of this commit: f50a08bc3d
Forward up to saas-15
opw:1819882
- Set the number of digits of 'Product Unit of Measure' to 1
- Create a stockable product:
UOM: Dozens
Purchase UOM: Units
- Buy 17 Units, validate the picking
- Create a landed cost:
Amount: 100
Split Method: By Quantity
- Compute
The Valuation Adjustment line contains contains a line with a quantity
equal to 1.4, leading to a line of 98.60. It is impossible to validate
the landed cost because of the inconsistency.
The method `get_valuation_lines` retrieves the data from the
`stock.move` and copies the following values to the
`stock.valuation.adjustment.lines`:
- `product_qty` > `quantity`
- `weight` > `weight`
- `volume` > `volume`
Therefore, we must make sure that these fields are using the same digits
precision. We adapt the precisions accordingly.
opw-1817783
When you have a receipt in multiple steps and cancel the generated RFQ
the following internal move stay in waiting another operation.
We recompute its state and pass it in waiting.
OPW-1832176
Before this commit:
1. With a coupon set on 'specific_product', the discount amount was multiplied
by the product quantity twice.
(Introduced by a42c27f which apply discount on the full price by using
price_total (already multiplied by quantity) over price_unit.
2. With a coupon set on 'cheapest_product', the discount was not discounting taxes.
3. With a coupon set on 'cheapest_product' and `sale_coupon_delivery` installed, it
would simply crashes and throws an error since `sale.order.line` has no
`program_id` attribute.
Now:
1. We no longer multiply by the quantity twice;
2. We apply discount on the full price (with taxes);
3. We use correct attribute to avoid crash.
opw-1830986
Before this commit:
1. With a coupon set on 'specific_product', the discount amount was multiplied
by the product quantity twice.
(Introduced by a42c27f which apply discount on the full price by using
price_total (already multiplied by quantity) over price_unit.
2. With a coupon set on 'cheapest_product', the discount was not discounting taxes.
3. With a coupon set on 'cheapest_product' and `sale_coupon_delivery` installed, it
would simply crashes and throws an error since `sale.order.line` has no
`program_id` attribute.
Now:
1. We no longer multiply by the quantity twice;
2. We apply discount on the full price (with taxes);
3. We use correct attribute to avoid crash.
opw-1830986
Laurent Smet