When logging timesheet, no employee is set by
default on the UI. The employee is deduced
from the user_id in the create, but we want to
see it on the list view even if it is not saved
yet.
The website is not ready. It is still too young to understand what the
beautiful `_rpc` function can bring to its life. Someday it will, but
for now, it can at least rely on the `rpc.query` function or to the
'Ace' menu which now understands the beauty of `_rpc`.
---
-> Replace website `_rpc` calls with deprecated `rpc.query` as the
website is not structured enough yet to handle 'trigger_up' events.
-> As the `_rpc` calls cannot be replaced for the ace editor because it
is also used and tested in the backend, promote the 'Ace' menu (which
instantiate the ace editor) to be a `ServiceProvider` so that the
`_rpc` method works in this particular case.
The ModelFieldSelector keeps an internal cache for the fields_get.
This cache needs to be cleared in the tests environment because
a model with the same name may be defined several times accross the
tests modules, but they may contain different fields.
This could also be a problem with studio: when a field is created,
the ModelFieldSelector cache must be cleared as well (in addition
to the data_manager one).
We thus introduce a new 'clear_cache' event on core.bus. When
triggered, the ModelFieldSelector and the data_manager clear their
respective cache.
We use this event in the test environment to ensure that the cache
is cleared at the end of each test using a mockEnvironment. This
rev. also fixes an infinite loop in the override of destroy() in
the mockEnvironment, which occured when both session and config
were specified in the params.
When the root node of the arch has attribute 'create' set to '0',
the generated DOM element must have classname 'o_cannot_create'.
This is used to correctly display the nocontent helper (when there
is no record).
Before this rev., the helper indicated that the user can click on
'Create' to create a new record, even if the create action was
disabled. This was for example the case in Point of Sale > Orders.
The problem occurred in form views with a many2one field, when the
user reproduced the following steps:
- type some text in the many2one
- click on 'Create ...' in the many2one dropdown to quick create
(name_create RPC) the record
- before the name_create returns, click on 'Save'.
When this happened, the record was saved before the many2one was
updated with its new value. So the record was incorrectly saved,
and the view was again dirty as soon as the name_create returned,
even if it was in 'readonly'. So after saving, a 'Changes will be
discarded' dialog opened when the user tried to leave the form.
We fix this issue by making the controller wait for the name_create
to return, and for the many2one to update its value, before saving.
This issue could also occur in list views.
The autofocus worked fine when switching from 'readonly' to 'edit',
but not when clicking on 'Create' from the multi-record view. This
was because in this case, we were trying to focus the field while
the view wasn't in the DOM yet. This rev. ensures that we wait for
the view to be appended to the DOM before trying to set the focus
on the default field.
Also ensures that the first visible field is correctly focused.
Before this rev., if the first field was invisible (or simply
not focusable), no field was focused.
Credit goes to @msh-odoo for the preliminary work.
The 'Add an item' button of one2many editable lists is deactivated
once clicked (since rev. f9a1241) to prevent concurrent record
creation. It is re-activated when the record has been created.
Unfortunately, it might happen that the record is actually not
created, so in this case the button is never re-activated.
This happens for example on the customer invoice form view, if
the user tries to add a line before selecting a partner.
This function should return a deferred, as indicated in the
docstring. However, in some cases, it doesn't. It then crashed
as the FieldX2Many tries to call done() on undefined.
This happens for instance on the customer invoice form view:
create a new record, select a partner, add a line, select a
product, directly click on the invoice date field (this will
trigger an onchange which will totally override the value of the
one2many). The FielX2Many calls setRowMode to switch the edited
row back to readonly, but this row doesn't exist anymore as the
one2many value has been overriden by the onchange, so setRowMode
wrongly returns nothing, and it crashes.
Suppose that a default_get returns the value [[6, 0, [1]] for an
x2many field (i.e. put id 1 in the relation). A read is performed
to fetch record of the comodel whose id is 1. Suppose that there
is another x2many field of the comodel. This x2many has to be
fetched (if not empty), and processed by the BasicModel (i.e. a
dataPoint must be created for it) as well.
Before this rev., the second x2many wasn't fetched nor processed,
and it produced a traceback for example in Expenses app, when
clicking on 'Submit to manager' from an expense form view.
For now, these tests do not work with another CoA than the generic one.
Depending on your testing infrastructure, they may or may not pass.
We skip then invalid CoA's and plan to make them work in master.
On the 6 June, the rate from EUR to USD change
in demo data. This cause problem in test, when
comparing amount.
We choose to not used currency rate defined in
demo data and that are time-dependent.
The import_module() method does not need to be public,
so let's mark it private. It's not called by anyone
except import_zipfile().
After 76cd8d2558 it would
fail anyway because addons_path would not be prepared by
import_zipfile().
Before this fix, if the start field is readonly, the user could not create
an event. With this commit, it is also ensured that the context sends the
right default values to the view
In case of a MemoryError, there is no error message, the user gets a
"Database restore error: "
without any details.
Instead fallback to the repr.
This way, a wrong password is
"Database restore error: Access denied"
and a memoryerror
"Database restore error: MemoryError()"
Closes#17393
On a pricelist, if multiple rules were set with the same
set of rules condition, the choice of which rule/item
is used was random, according to the postgres database
state.
Adding the `id` in the order force to always use the same
rule/item (the first that was created).
opw-744865
with the new views, we removed the many2many_kanban widget on many2manys, since it is the default behaviour anyway, but we also removed it for a few one2manys. And this is a mistake, some one2manys have to behave like many2manys.
(PR #17190)
- Create an excluded tax of 20 %
- Create a customer invoice of 1000
- Create a payment of 900
- Make the matching between the invoice and the payment:
Write-off of 83.33, with the 20 % tax
Error: 'Cannot create unbalanced journal entry'
After commit 89cbef8540, the tax are by default not created
automatically anymore. We should make sure to pass the context key
`apply_taxes`.
opw-744266
When disabling the customer portal
in the general settings
(or uninstalling the `portal_sale` module directly),
the model `sale.order` no longer has a method
`get_signup_url`, and it therefore leads
to the fail of the email template rendering which is
still referencing this method.
Besides, the `access_url` is actually used only if
`is_online` is True,
(see the `% if is_online:` few lines later)
and in this case `get_signup_url`
was not used at all.
Therefore, we can assume `None` is a good alternative,
as the resul of `get_signup_url` was actually no longer
used.
opw-710481
If you have two invoices with a same product,
- one having 1 unit of a product,
- the other -1 unit of a product,
The sum of these quantities will be 0, and it will lead
to a division by zero in the former sql request.
The nullif should be applied on the sum, not on the line quantity.
opw-745073
This try except block was added in another era, where the piece of code
in the block was far less ambitious (and not for good reason since
adding a try except block because of a malformed mail template seems
overkill).
Even worse, this block actually prevented errors from bubbling, which
could have adverse effects.
Example: a long transaction confirmation (several seconds since it
implies S2S communication, invoice creating/validation, etc.) is
rollbacked because a mail message is recorded on the quote during
the processing time. The quote confirmation then crashes because of a
concurrent update error in postgres. This try except block does not
re-raise the error, which means that instead of retrying the operation
like the ORM would normally do, we have an incomplete traceback in the
system (since the error message crashes itself) and the transaction is
not validated (as far fetched as it may seem, this is in fact how this
bug was discovered).
This try-except block offers no gain in error logging (on the contrary,
since we have lost the initial error-causing statement) and prevent the
orm from correctly managing errors.
This commit removes it and let the orm handle the errors like a grown up
man; either crash for real (because it should crash to know if there's a
problem) or retry the transaction if it's a serialization issue.
opw-744629
The attribute filters based on all products matching current domain was limited
to the first page of result only.
If all the products of the current page had no variant, no filter was displayed.
Closes#17361
Previously, when an update operation was performed, the list of
ids in the x2many field was emptied beforehand.
It kinda worked in lots of cases where one would expect it to
fail because in thoses cases the widgets send link_to commands
along with the update one, thus re-adding the removed line.
Now the behavior is more consistent accross the board. We start
with the current list of ids and apply the requested changes.
When the user zooms with the browser, the bottom left pads are
misaligned for some zoom levels.
By slightly reducing the width of the action pad, this can be solved for
all acceptable zoom levels.
opw-745074
Use the field `time_cycle` for cost computation, which takes into
account the routing configuration (fixed time of computed based on
previous operations).
- Create a work center with a capacity of 1, an efficiency factor of
100% and a cost per hour of 40$
- Create a routing with two operations: one with a fixed duration of
30:00 minutes (OP1) and another with a duration computed on real time
but with a default of 30:00 minutes (OP2)
- Create a component with UOM "m" and a cost of 10$
- Create a finished product with an associated BoM
- The BoM has a first line with 0.8m of component in the OP1 and a
second line with 0.4m of component in the OP2
- Activate the Compute from BoM option on the finished product
- The proposed cost is 32$
Expected cost: 52$
(30 minutes @40$/hour + 30 minutes @40$/hour + 1,2m @10$/m)
We divide the WC cost by the number of operations, which does not make
sense.
opw-741032
An archived forum could still be posted in, something better should be
done in the next version (eg. website published present on a lot of
record type) but as of 10.0 just this improvement is done.
opw-745510
closes#17365
Jérome Maes