Backport of bc84eb2035 to 10.0
Countries with several official languages often have multiple names for their
states. Allow to translate the state name for such countries.
Some monolingual countries but, yet, with a need of translation of the addresses
such as China or Germany can add the same flag in their respective l10n_* module
Closes#25340
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
The token field is a technical data that the other users are not able to use.
It may be confusing for users to see token on the user interface.
Still show it to administrator for debug reasons.
The dateutil package uses lazy import to selectively expose its
features: `parser`, `relativedelta`, `rrule`, `tz`.
Depending on installed modules and order of initialization, there was no
guarantee that a given feature was already loaded during the preparation
of the action context.
This patch ensures that we always preload the feature set we need, and
only that feature set. This way we have a consistent `dateutil` lib in
the action context at all times.
When using sudo, the administrator is logged as deleting the action.
For audit reason, log the correct user.
To avoid access rights errors, only group system can delete the action.
An ir.attachment record can be served as a request's reponse if:
- a request triggers a 404
- the ir.attachment record has its url field matching the url of
the failed and is of binary type
Following rev[1], portal users have the right to create these kind of
records, and it is a security concern.
This patch restrict the ability to create and write on the ir.attachment
records that may be served through the dispatch's exception mechanism to
settings users.
As the asset bundles files are served through the use of these special
ir.attachment, we make sure to retrieve only ir.attachment records
created by the superuser in the `get_attachment` method.
As website administrators often need to play with these special
ir.attachment, we also let to this group the permission to manage them.
[1] 61065b6d04
Make sure building reports using local resources are disabled.
This avoids get different report result based on the system if the
given resources are or not present (e.g. custom style)
The token field is a technical data that the other users are not able to use.
It may be confusing for users to see token on the user interface.
Still show it to administrator for debug reasons.
The dateutil package uses lazy import to selectively expose its
features: `parser`, `relativedelta`, `rrule`, `tz`.
Depending on installed modules and order of initialization, there was no
guarantee that a given feature was already loaded during the preparation
of the action context.
This patch ensures that we always preload the feature set we need, and
only that feature set. This way we have a consistent `dateutil` lib in
the action context at all times.
When using sudo, the administrator is logged as deleting the action.
For audit reason, log the correct user.
To avoid access rights errors, only group system can delete the action.
An ir.attachment record can be served as a request's reponse if:
- a request triggers a 404
- the ir.attachment record has its url field matching the url of
the failed and is of binary type
Following rev[1], portal users have the right to create these kind of
records, and it is a security concern.
This patch restrict the ability to create and write on the ir.attachment
records that may be served through the dispatch's exception mechanism to
settings users.
As the asset bundles files are served through the use of these special
ir.attachment, we make sure to retrieve only ir.attachment records
created by the superuser in the `get_attachment` method.
As website administrators often need to play with these special
ir.attachment, we also let to this group the permission to manage them.
[1] 61065b6d04
Agathe Mollé