*: hr_gamification, point_of_sale, web
Before this commit, no content helper in some form view fields were broken,
due to the style of the classname `.o_view_nocontent` that uses an absolute
position.
This is due to some templates that wrongly use this style for displaying a
help message, although this is only valid for views with no record.
This commit solves the issue by using another classname for those fields
with the nocontent helper, namely `.o_field_nocontent`.
Have an event starting *now* with a reminder, let's say 15 minutes
After saving the event, the notification pops up.
Click "OK"
Before this commit no call to the server was done, implying that the notification
will keep on popping up untimely
This was because, the widget was destroyed, hence its parents got removed
before the triggering up of rpc call
After this commit, we make sure we destroy the widget *after* the rpc
OPW 1860169
closes#25399
Let's assume a one2many list with two fields A and B, and an
onchange on A that sets B. Before this rev., on new records, the
onchange was only triggered if the one2many list was defined
inline.
Rev. 13c885195 was an attempt to fix the onchange issue in x2manys
with non inline views, but it only worked on existing records. This
rev. fixes the problem for both cases (existing and new records),
and thus reverts the fix of 13c885195.
The idea of this fix is to make both cases behave similarly, w.r.t.
fields and viewFields stuff in the fieldsView. In the inline case
(like in the main view case), fields and viewFields are the same.
In the non inline case, viewFields contained more information than
fields. As fields is used everywhere in BasicModel (and viewFields
is basically ignored), the fix is to set fields to viewFields.
This revs. add a new test suite for the im_support module. Defining
a new suite was necessary as the im_support JS feature needs
specific keys to be defined in the session, otherwise its files are
simply skipped.
In the mocked version of the longpolling bus used in tests, the
is_odoo_focused function should be defined to prevent crashes when
we simulate incoming messages.
Since the ChatWindowManager is a service, this is no longer
necessary to set the webclient as parent of ChatWindow's instances.
This rev. sets the ChatWindowManager itself as parent, which makes
much more sense, and which allows to properly mock the whole
ChatManager-ChatWindowManager environment in tests.
Those test utils files should be in the test assets bundle such
that they are available for potential other test suites (e.g. the
new im_support suite).
Have an action that opens a dialog, with a specific callback
to execute when the dialog closes
In the dialog, have a button linked to an action that opens
another dialog in target = new
Close this 2nd dialog
Before this commit, the callback was not executed
After this commit the callback is executed
OPW 1853136
closes#25180
Loads the barcode nomenclature only if one has been is defined. Indeed,
from commit 80e89c7a11, the POS config unset the
`barcode_nomenclature_id` field if the barcode support is not activated.
opw-1859928
Commit 45c5a07d89 deals with displaying on the aged balance reports
the lines that zero out each other: an invoice and a payment of the same amount for the same partner
However, that commit overlooked that when there is a chain of reconciliation
that puts the report line to zero, it was displayed as well.
This present commit corrects this by making sure there are amls that detail the report lines
OPW 1858963
closes#25359
- Activate sub-stasks on projects
- Create a product A:
Product Type: Service
Invoice based on: Timesheets on tasks
Service Tracking: Create a task in an existing project
- Create a SO with A, validate
- In the project view, open the created task
- Click on the stat button 'Sub-tasks'
- Create a task from the kanban view
The SO line is not copied on the sub-task.
The `name_create` method doesn't send the `parent_id` key in the values.
Therefore, the SO line is not retrieved.
We fallback on the context key `default_parent_id`.
opw-1857560
Create a resource working 24 hours / day.
If we record it as:
- From 00:00 ; To 24:00 => crash
- From 00:00 ; To 23:59 => 1 minute lost
The `float_time` widget doesn't allow to be more accurate than 1 minute,
therefore it is not possible to record an end time of 23:59:59.999999.
We allow a value of 24:00 which is automatically interpreted as
23:59:59.999999. Only 1 microsecond is lost for such use case, which
should be acceptable for our level of accuracy.
opw-1856943
The context is send to qweb as option, the options are converted into a
frozen dict, the browse records can have a closer cursor, takes the place
in the cache, and raise and exception in qweb (because contact try to
json.dumps options for multi-edition feature in web_editor.
opw-1859848
Usecase to reproduce:
- Enable multiple languages and companies
- Set one language on the admin and another on the demo user.
- Create a product and a translation for its name (both languages)
- Create an inventory adjustement in a company A for this product
- Switch on demo user (inventory manager rights but in company B only)
- Create another inventory adjustement for company B
- Add the invenory line with the product and save
The Inventory Line multi-company rule raise an access error
because the system set product_name on the inventory_line that is
a related field. Since it changes the product name with its translation
it will update it on other inventory line that have this product. The
other inventory line is in company A and the user don't have access to
it thus the access error is raise.
This adds readonly on the product_name since it should not be update
with an inventory line.
opw-1855137
Before this commit, if the user opened the LESS editor and emptied a
file, he may get a compilation error (as intended if the file contained
necessary variables and stuff) but this error also prevented to open
the editor again because some code tried to decode an empty content.
Now, when a file is emptied it is set to an unique line feed.
amount_currency is a field that is expected in multi-currency
The general ledger report has a line
<span t-esc="line['amount_currency'] if line['amount_currency'] > 0.00 else ''"/>
which crashes if amount_currency is None
opw-1859122
Replaces and closes#25240
The code was actually alreadt made in this spirit, there was just as wrong call to the date_invoice field of the model instead of the local variable with the same name, which contained the right value.
by datetime
The library `datetime` defines a MINYEAR and MAXYEAR limit.
If you try to play with dates outside of these years limits,
it crashes.
In the case of the opw, the date within its timezone was
within the limit (year 9999), but in the UTC timezone
it was no longer the case (year 10000).
Actually the condition should use `<=` instead of strict `<`,
and check the year *in utc*
is not outside the limit, but as soon as you try
to compute the date within UTC, datetime crashes :).
However we can assume nobody will need a event in the year 9999
any time soon, or by that time if Odoo still exists,
we should have refactored this module about 3333 times and somebody
would probably have removed this limitation by oversight anyway.
opw-1850024
odoo/enterprise@6c853253bf removed some
code from enterprise that was moved to community in
32db86e3a0. The make_stub_line function
was part of this, but in the process it was renamed to
_check_make_stub_line. Some calls to the non-existing make_stub_line
still existed.
- When paying a sale order with a payment acquirer that saves tokens
after each payments (S2S mode or save token to "ask" or "always") and
while not connected.
The payment token is saved as either the sale order's partner (when the
acquirer is in form mode) or as the public user's partner (for S2S
acquirers).
To fix this issue, if the customer is not connected and pays the sale
order using a form acquirer, we do not create a token.
If the customer pays the sale order using a S2S acquirer, the created
token is then linked to the invoice's partner.
Canceling the delivery order created for a "Make to order" product
cancels the related procurement.
But canceling the receipt order created for a "Buy" product" with reordering rule
didn't cancel the related procurement. In some cases, it can block the application
of the reordering rules.
Now the related procurement is canceled when the receipt order is canceled.
opw:1845345
Steps to reproduce the bug:
-activate the pick-pack-ship route on the main warehouse
-activate the delivery packages option in Inventory > Configuration > Settings
-create a stockable product
-make a quick inventory for 10 unit(s) of this product
-sell 2.30 unit(s) of this product & confirm the sale
-process the done qty in the PICK operation and click the button "put in pack"
-validate the PICK operation
Bug:
check the PACK operation and the full package was not being transferred
opw:1858316
- When paying an invoice with a payment acquirer that saves tokens after each payments (S2S mode or save token to "ask" or "always") and while not connected.
The payment token is saved as either the invoice partner (when the acquirer is in form mode) or as the public user's partner (for S2S acquirers).
This should not happen.
To fix this issue, if the customer is not connected and pays the invoice using a form acquirer, we do not create a token.
If the customer pays the invoice using a S2S acquirer the created token is then linked to the invoice's partner.
The end time of a calendar event is constrained to never be before the start
of te event.
However when updating events, one path would first update the start of the event
before updating the end of the event.
So in case where (s_1, e_1) is updated by (s_2, e_2),
with respectively s_i < e_i,
if s2 > e1 then the update would violate the constraint and thus crash
the calendar update.
opw 1854394
When the initial inventory adjustement is made after the accounting
openeing entry, no AML is created with the initial quantities. The
valuation report is therefore wrong.
Partial revert of 21099f3eaf. Although the existing solution
has also flaws, the fix highlights them even more.
opw-1859204
- Change the one of the following default account on a product category:
Stock Input Account
Stock Output Account
Stock Valuation Account
- Upgrade stock_account
The account is changed back to the default value.
This was due to commit 1bf25fc018 which attempted to solve an error
in a test.
We fix the test by making sure we check the right accounts. We also make
sure to avoid creating 2 identical `ir.properties` (one `False`, the
other with a value). We only update the property if it is `False`.
opw-1859706
When clicking on an action button, the following steps are performed:
1. Buttons are disabled
2. The button call is performed
3. At the end of the call, the buttons are enabled
4. Extra RPC are performed (`read`, `name_get`)
5. When the RPC calls are finished, the form is reloaded
In the case of a validation of a SO, it means that the 'Confirm' button
is enabled at step 3, but hidden at step 5. On a slow network (or an
overloaded server), it means that the user has enough time (step 4) to
click again on the 'Confirm' button and trigger the action more than
once.
The root cause is that we don't retrieve the promise of the `reload`
mechanism (defined in `_callButtonAction`) when executing `on_close`
(triggered after the button call). We return a promise which is resolved
and enable the buttons too early.
We make sure to retrieve the promise of the `reload` and return it, so
that the promise of `saveAndExecuteAction` (defined in
`_onButtonClicked`) is correctly linked to it. This way,
`_enableButtons` is called when the reload is performed.
Co-authored-by: Aaron Bohy <aab@odoo.com>
(well, actually he did most of it)
opw-1859027
Steps to reproduce the bug:
- Create a recurring meeting, with a start date with time (not all day) (for example 09:00),
a duration (for example 5 hours) , each week for example on fridays, for 3 occurences.
-Save
Bug:
- The start_datetime ("Starting at") was increased with the duration of the meeting.
PS: The displayed start and stop in calendar view were computed in function "calendar_id2real_id"
with the virtual id.
opw:1858154
Facing the following cases, only the database admin can merge res_partners:
1. The email addresses are different.
2. The origin contact(s) is (are) linked to some account move lines.
This commit adds a kwarg in the merge function. This argument allows to skip the two tests.
So they can be bypassed when overloading the function (depending of the current user access
rights for instance) in order to merge partners even if they have different email addresses
or with account move lines on the origin one.
It can also be called programatically and bypass the checks.
This commit also makes the merge wizard correct any inconsistence in the
allowed companies/currency company of the merged contacts and the
related user(s).
Closes#24376
Before this commit, the user could lost some unsaved changes in a record when
posting a message in the chatter.
This is due to reloading the data on the record, which is necessary because
a `message_post` may make some changes on the record [1].
With this commit, a dialog will warn the user that the record will be reloaded
in the following cases:
a) posting a message in the basic composer that will reload the record
b) opening the full-composer when the record is dirty
Indeed, any operation after opening the full-composer will always refresh the
record (even closing the dialog).
Known issues:
- a record is not considered as dirty if we only make changes in its
description from a pad.
> the content of the pad will be erased without any warning...
[1] https://github.com/odoo-dev/odoo/commit/803d5cf04835fcf8e7ddb143e1ab140408beef93
opw-1825005
Revision on b09f0c99
The intent of the previous commit was to no drop records in a list
on discard in the following cases:
- when they have been created from a `default_get`
- when they have been created from an `onchange` that result
from a `default_get`
Before the commit above, the kind of records that were abandoned
in those cases are stated as invalid, which happens when a record
has a required field that is empty.
The case of an `onchange` that is not involved in a `default_get`
was not considered in the fixes above. In fact, this is the intent
behaviour in most cases. However, if the items in the list are
created from such an `onchange`, we should not drop them.
This commit fixes the bug where records in a list that are created
from an `onchange` are wrongly abandoned. Here is the new logic to
abandon a record on discard in a list:
- the record that is marked as "do not abandon" should not be
abandoned;
- a record that is registered as a "not new addition" in the
list should not be dropped;
- a record that is registered as a "new addition" in the list,
and has been updated afterwards, should not be dropped;
- a record that is not new should not be dropped;
opw-806650
Avoid to crash the client web with setValue(false).
false.match, false.split, false.length... will not works.
Before this commit, _render call the setValue after comparing '' !== false
Before this commit, if you add 2 times the same item quickly, that raise concurrent update.
With side effect: quotation rollbacked and new one created, or if no concurrent
update 2 times the same product in the cart.
Now we avoid that the user click a second time on "Add to cart" before the end of the
first click which add or move the product to the cart.
Related to #24853
Alexandre Kühn