In Fattura Semplificata, copy-paste mistake in the template
after refactoring.
IDCodice for the Sender has to be filled with the CodiceFiscale
and not with the VAT number.
(We only use VAT number if we don't find the CodiceFiscale.)
related PR: odoo/odoo#143122
opw-3597050
closesodoo/odoo#143240
X-original-commit: 2a9344e08edb935f29489286029a75d3d236adb0
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Correct the wording of "Visa Expire Date" to "Visa Expiration Date"
for the visa_expire field to be more grammatically correct.
task-3595978
closesodoo/odoo#143222
X-original-commit: 1722e62193d0b587e508d30b1d460498c1ea4c86
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Signed-off-by: Florent Maisse (mafl) <mafl@odoo.com>
This commit fixes an issue where if one sets no_create_edit and
no_quick_create to true on a m2o while no_create is unset, no dropdown
is shown to tell the user that no record was found. Since the quick create
and create and edit options are disabled by default when create is false,
we no longer need it in the condition and can only rely on quick create
and create and edit.
task-3599696
closesodoo/odoo#143202
X-original-commit: 9da78c1b2bdd85f06e8682b99c8c481e91546ec7
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
condition: install sale_loyalty only
"""
before commit:
right after archived e-wallet program, system will show python pop-up
error tuple index out of range
after commit:
able to open archived e-wallet program
closesodoo/odoo#143196
X-original-commit: 58a1c854b63a65e72b99b3466b3ef63a5e691e63
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The arrow in the inputs of the side panel was stuck to the side of the input,
without any padding.
closesodoo/odoo#143191
Task: 3376873
X-original-commit: 97c2f7832669ce01f70ee0b5474328382b3f8c2f
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Adrien Minne (adrm) <adrm@odoo.com>
This commit prevent the discount product to be shown in the frontend of
the PoS and abling him to download demo data on the flight if he does
not have other products available.
closesodoo/odoo#143154
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
This commit fixes a bug in page creation by the configurator. This only
happened with pages containing only one snippet, like the "Pricing" page
or the "Privacy Policy" page (default themes). Because of this bug, the
snippet that should be placed in the page had its parent element
"<section>" replaced with a "<div>", so the section options were no
longer available in edit mode, such as background options,
delete/duplicate/save the snippet, etc.
When there was multiple snippets, it worked by chance:
`<section></section><section></section>` was parsed as
`<div><section></section><section></section></div>` using the etree lib.
The web_editor `save` method then copied each children and put them in
the targeted oe_structure.
However, with only one snippet:
`<section><div class="container"></div></section>`
it was parsed as it is, then same: each children was copied and put in
the targeted oe_structure... but the only child here is the `container`.
Then the classes of the section were transferred on the oe_structure
element.
Steps to reproduce the bug:
- Create a new website using the configurator.
- Check the "Pricing" box in the list of features to create the
"Pricing" page.
- Once the website creation is complete, go to the "/pricing" page.
- In edit mode, click on the "comparisons" snippet.
- Bug: Some options are missing for the snippet, for example, it's not
possible to delete the snippet or change its background.
task-3570903
closesodoo/odoo#143049
X-original-commit: 68ffe065c6fa03874ee8c99b91ca317d1c2755a3
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
To reproduce the issue:
1. Create a subcontracted product P
2. Create and confirm a planned transfer with 10 x P
3. Set the done quantity to 8
4. Set the done quantity to 7
5. Open the detailed operation (i.e., the MO)
Error: The producing quantity of the MO is 1, it should be 3
When setting a smaller done quantity than the demand (step 8), we
update the expected quantity of the related MO, we set its producing
quantity, and we create a backorder.
When decreasing the done quantity, we update/cancel the related
productions. But here is the issue: in the above case, we simply
decrease the expected quantity of the backorder, so we just lose the
cancelled quantity, the user "can't" produce this quantity anymore.
In such situation (when decreasing the done quantity), we should
consider the last production (i.e., the last backorder) as the WIP one.
So, we should update/cancel the other productions and increase the
expected quantity of this last backorder, so the user can produce it
again.
OPW-3557632
closesodoo/odoo#142513
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
To reproduce the issue:
1. Create a subcontracted product P
2. Create and confirm a planned transfer with 10 x P
3. Set the done quantity to 15
Error: The demand becomes 15
When setting the done quantity, we sometimes have to update the
demande (see [1]), but it should only happen with immediate transfer.
[1] 005b51fe019dfe3f7df25aefaca04a77bd5250aa
OPW-3557632
Part-of: odoo/odoo#142513
This reverts commit a32778d2b24af2774057f5428c53291653ddc6d3, as it was
a temporary fix in wait of the larger one included in this PR.
Task-3383596
Part-of: odoo/odoo#142513
Steps to reproduce:
- Create a subcontracted BoM for a product
- Create a planned reception for this product, with a demand of 10, mark
it as todo.
- Click on the moves details and in the 'Subcontract' wizard, set the
quantity to 5 and click 'Continue'.
- Now set the quantity to 2 and click 'Record Production'.
- Close the wizard without recording the last quantity.
- Validate the picking (there should be only 7 out of 10 quantity done),
and don't generate backorders.
- When checking the related Subcontracted MO (Inventory Overview ->
Filters -> Archived -> Subcontracting), all 3 MO related to this
reception were cancelled.
Issue:
When checking for the still active_productions, it wasn't taking into
account that there could be multiple still-active productions (like when
a production is recorded in multiple times like here). This messes up
with the 'in' condition, cancelling productions that shouldn't be.
Task-3383596
Part-of: odoo/odoo#142513
Currently, when no workorders are defined for a production, updating its
`product_qty` through the wizard won't update its qty_producing, meaning
that if the production gets validated right afterwards, the total
produced will be the same as prior the update.
This is missleading and unconsistent with how things work when
workorders are involved, since in that case the `qty_producing` of the
production will be updated through the inverse of the workorder's
`qty_producing`.
Also removed the verification on `produced_qty` as it will never be set
before the MO is done, and the wizard can't be accessed at this point.
Part-of: odoo/odoo#142513
Steps to reproduce:
- Manufacturing -> Configuration -> Settings -> Enable Subcontracting
- Proudcts -> Bill of Material
- Create a 'subcontracting' BoM for tracked (serial) product A from
supplier S
- Inventory -> Overview -> Receipts -> New planned transfer
- Set S as 'Receive from', A as product with qty 2 and hit save
- Open move details and record both serials.
- Now open the move details again and change one of the two move lines
lot_id to a new one and validate.
Issue:
Updating the subcontracted move's move.line `lot_id` won't change the
subcontracted MO. Which means that the link is lost between the picking
and the productions, breaking the chain in traceability.
When updating to a valid `lot_id`, now checks if there's a related
production that match the old `lot_id` to keep consistency.
Task-3383596
Part-of: odoo/odoo#142513
Steps to reproduce:
- Manufacturing -> Configuration -> Settings -> Enable subcontracting
- Products -> Bill of Material
- Create a 'subcontracting' BoM for product A from supplier S
- Inventory -> Overview -> Receipts -> New planned transfer
- Set S as 'Receive from', A as product, 10 for demand and hit save
- Set 5 in the move's `quantity_done`
- Open the move details and try to record the qty, it's still possible
to record all 10 finished quantity
- If set to full quantity and saved, the move quantity will now be 15.
Issue:
In the case of a subcontracted move, only modifying the move's
`quantity_done` doesn't do much, as recording the components will add
the new `qty_producing` to the existing move's `quantity_done`, leading
to incorrect amounts if both are used.
The proposed solution here is to emulate what's done in the form when
updating the `quantity_done` of a subcontracted move. This is true also
for the generation of lot/serial numbers for the finished products, as
it would be done from quickly validating a MO through the form view.
The checks for lot/serial of component and finished products were moved
in the picking `_action_done()` rather than on the wizard itself.
This allows to set consumption of tracked components without giving a
lot, but still requires them to be set at final validation. The lots can
be assigned through the 'Register components for subcontracted product'
button.
By doing this both methods could be used correctly.
Task-3383596
Part-of: odoo/odoo#142513
Steps to reproduce:
- Manufacturing -> Configuration -> Settings -> Enable subcontracting
- Products -> Bill of Material
- Create a 'subcontracting' BoM for product A from supplier S
- Inventory -> Overview -> Receipts -> New immediate transfer
- Set S as 'Receive from' and A as product and hit save.
Issue:
A warning appears next to the scheduled date saying the preceding
operation (the subcontracted MO) is scheduled from one hour later than
this picking. This only happens for immediate transfers.
When picking's `_set_scheduled_date()` is called, this ultimately leads
setting the subcontracted MO's date planned/finished to that same date.
But since the `date_planned_finished` is implicitely readonly, its value
is recomputed right after it was set, as it depends on
`date_planned_start`, which was updated at the same time.
Also, in case of subcontracted MO, the `date_planned_finished`, the
start and finished date are usually the same, so there's no need to add
the default 1 hour between the two dates. It's done at the creation for
subcontracted MO, but any update would recompute the date to start + 1
hour and raise an useless warning on the subcontracted picking.
Task-3383596
Part-of: odoo/odoo#142513
When Odoo is installed with the latest version of the PostgreSQL client (postgres-client or postgres-client-16) and running in Docker (possibly other environments as well but not reproduced so far), executing `pg_dump` via `exec_pg_command` fails with
Database backup error: Postgres subprocess ('/usr/bin/pg_dump', '--no-owner', '--file=/tmp/tmpmnqiktog/dump.sql', '15TEST') error 1
This seems to be because `os.devnull` is being opened in *read* mode which is incorrect (as it's written to). It's not entirely clear if older `pg_dump` simply ignored the non-writable stdout or if docker adds some restrictions which cause the failure.
Either way this can be solved by either opening `os.devnull` in write mode or switching to the `DEVNULL` constant. While the function is deprecated in 16.0 (7f14631fe8) and removed in master (ae3056f3f4fca82c6aee69bf201532e14829c45e) the latter is not a huge change and it a touch cleaner.
fixes#139687closesodoo/odoo#143198
Forward-port-of: odoo/odoo#142987
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When removing an item in x2many fields from the res.config.settings form, the
client interprets it as a set of link commands for the remaining items, as a
result, the items that should have been removed are not removed.
This generalizes the fix made for the splash screen images in pos_self_order by
which this issue was first observed.
The test is also moved to the point_of_sale module as it is not specific to
pos_self_order. Also note that the test is manually doing what is observed from
the client.
closesodoo/odoo#143165
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
In commit b47be9f254b2f7327ea3e0e92c6b1b97bff016d0 we changed the
background of the popover selector making the title unreadable in
white mode.
This commit applies the text-dark color to make sure the title is
readable. It also removes the primary background on hover behind the
btns to use a color change instead. We will later on improve this
component with the btn-link + contextual class to manage the hover
effect in another task.
When a field is selected the active class is added on the parent <li>
rather than the <button>. This commit applies it on the button to
display an active state on the selected element.
task-3577065
closesodoo/odoo#143164
X-original-commit: 3d664d6e7daedecc5e995636bfe055c9ba800bb2
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
After this fix, UBL now uses the same helper as Factur-X for the import
of the product. Also clean some dead code in UBL.
task-3559040
closesodoo/odoo#143160
X-original-commit: 59f2736023d6065522c4e89deebfa580fda0afd8
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Description of the bug:
task field is displayed in leave type form when company field is False
Steps to reproduce:
- install time off app
- open a leave type form
Source:
When installling time off app,
_compute_{timesheet_project_id, timesheet_task_id, timesheet_generate}
work perfectly, when company = False => project/task = False
and timesheet_generate = True
Then, the post_init is executed. it will set the project and task
according to env.company when company is False. so now project and
task can have values even that the leave company is False.
Then in the xml, we hide project if company is null and task if project is null,
that's why project is not displayed but not task
Solution:
- In post_init method, we only get leaves types with a company set
and stop using env.company to be coherent with the compute methods.
closesodoo/odoo#143016
X-original-commit: e647374
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Step to reproduce the bug:
-Go to the employee app
-Go to an employee form view
-Click on the archive button
-Put a description
-Click on the archive button
-> Odoo error
Bug explaination:
The tracking is not implemented for the html field, so when we archive
an employee the tracking cannot work.
Expected behavior:
The employee is archived and the tracking is done without errors.
Bug resolution:
The tracking has been removed from the html field.
The tracking is now replaced by a message in the chatter
in the write method.
Behavior after this commit:
The employee is archived and the tracking is done without errors
with a mesage in the chatter if a value is entered for the
departure_description field has a value.
task-3576659
closesodoo/odoo#140527
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Add a condition that check if the DB is connected to the iot box before
the start of the websocket client, before, if no DB was connected the
Thread was lauched for nothing
closesodoo/odoo#143132
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
* Create a tax of type `group` and with a `tax_scope` set
* Add a child tax without `tax_scope` set
This will raise an error because the `tax_scope` is not exactly the same
since it doesn't have a value.
We should be able to share sub taxes without a scope, exactly like for
`type_tax_use`. This is also what the message suggests.
closesodoo/odoo#143089
X-original-commit: 6101b2bbeaf996d4c3472ad36d740243bb0a5aa8
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Previously, 'amount_currency' was calculated using data from the purchase line. However, numerous variables could interfere with the accurate computation of 'purchase_price_unit' (e.g., taxes, taxes without account, standard costing method, kit product, and potentially more).
This commit revises the approach by utilizing the pre-calculated value and converting it to the desired currency. This maintains coherence between the balance and 'amount_currency' without necessitating the recreation of a function like '_get_price_unit()' in 'purchase_stock.'
## Reproduce Errors ##
### Tax Included in price without Account:
- Create a currency, CTest, with a conversion factor of 10 (10 CTest = 1 USD).
- Define a new tax:
° No accounts in repartition lines
° Rate: 15%
° Included in the price
- Create a Purchase Order:
° 1 unit | 100 CTest | Tax applied
- Receive the product.
-> SVL value is 10 USD, because tax without account increments the stock value. Refer to 'test_valuation_multicurrency_with_tax'.
-> Check SVL journal entry: credit / debit is 10, but amount currency is 86.96 CTest instead of 100 CTest.
### Reproduce With Kit:
- Create a currency, CTest, with a conversion factor of 10 (10 CTest = 1 USD).
- Create a Kit (storable, fifo), with 5 unit of CPM (storable fifo) in it's BoM
- Create a Purchase Order:
° Kit: 1 unit | 100 CTest
- Receive product
-> Check SVL journal entry: credit / debit is 10, but amount currency is 500 CTest instead of 100 CTest.
OPW-3453703
closesodoo/odoo#143033
X-original-commit: 5ea188fb65507d4bd06ab3361241d121ac2a468b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David Fesquet (dafr) <dafr@odoo.com>
- add populate for mail.notification
- add batch processing and logging for a more pleasant waiting
- adapt existing numbers to find a better balance between usefulness of
data and waiting time
closesodoo/odoo#142734
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This makes the "medium" populate of `res.users` take few seconds rather
than 2min30 on my machine.
The issue was that `write` (not in batch) is calling
`_subscribe_users_automatically` not in batch, which is particularly
slow.
`discuss_channel_nosubscribe` is removed because it was uneffective. The
condition was only on create, but the group change in
`_inverse_notification_type` was systematically triggering the
auto-subscribe outside of create anyway, which is what we want.
Part-of: odoo/odoo#142734
This reverts commit 430f4904ed.
This should not be done in stable, for 3 reasons:
1: There is no migration scripts, so every people that will migrate from previous version will have a second product discount created in their DB
2: Existing DB that will activate discount will have 2 products discounts
3: It breaks an industry module that depends of this data
For those reasons, I'll revert this commit before it is deployed next week.
To correctly do your changes, you just need to do it in master and create a migration script that will rename the xml_id.
closesodoo/odoo#143104
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
Before this commit:
Format and style are lost when copying content that has some style or format
applied on it.
After this commit:
Now, able to copy content with its format and style.
Task-3263360
closesodoo/odoo#142984
X-original-commit: 8083b990845eeb5b1fa6aaaa21617f16d4d5a780
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Without it, like in no-demo testing conditions, tests with rights
depending on Karma fail.
Task-3575692
closesodoo/odoo#142785
X-original-commit: c1ca12f4bf090761fc8c63eafc70ac47ae6851fe
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
To reproduce
============
on POS (without having a connected print), make an order and print the
receipt, the preview will show the receipt not well rendered
Problem
=======
we add the element that contains the receipt to the page, so we have
two copies of the receipt (the page using CSS `@media print` and the added
element)
Solution
========
hide the original element on the page while printing, and bring it back
after
opw-3596341
closesodoo/odoo#142699
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
If you have a survey of several pages, but don't valid all, you don't
have any survey_input_line for some question, so the [0] will crash.
Since the method wait only one input_line maximum, instead to force to
take the first one withtout take care if no reply, we just use the
browser record that will work in both case. If it is empty it will enter
in the 4th case, 'skipped' what is expected and was dead code before.
closesodoo/odoo#142500
X-original-commit: 02f49b726a40dc97f065ca40225411a208d65302
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
withholdings is a legal requirement for many companies in AR that are withholding agents,
where the company is meant to compute, create and share the Vendor WTHs (in this case the WTH
is not electronic, but a PDF report with the details of the WTHs created need to be
shared with the Vendor)
Task :
latam 690
adhoc 27675
closesodoo/odoo#140607
Signed-off-by: Josse Colpaert <jco@odoo.com>
Before the commit, there was a small issue where a foldable badge would be
slightly smaller in height than A4 paper.
This commit fixes this by giving foldable badges more height.
Task-3389338
closesodoo/odoo#143079
X-original-commit: 0bca59b43bb195f8fc5feef315c7694eba6df326
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Suppose a user who imports a new picking thanks to this:
```csv
location_id,location_dest_id,picking_type_id
WH/Stock,Partners/Customers,YourCompany: Delivery Orders
```
Then, on the inferface, for one of the fields, he sets the value as
"Database ID" (for instance "Destination Location/Database ID").
When trying to import the file, an error is raised, which could make
sense since the provided value is not a DB identifier, but the error
is actually incorrect:
> Odoo Server Error. Current transaction is aborted, commands ignored
> until end of transaction block
When looking for the destination location in the database, it will
raise a legit error since the domain does not make sense:
`[('id', '=', tentative_id)]`
Hence this:
> ERROR: invalid input syntax for type integer: "Partners/Customers"
The good point is that everything in the code already handles this:
we catch the error and add some detailed explanations in the import
error report, but... The SQL transaction is now broken. So, as soon
as another SQL request is executed, it will trigger an
`InFailedSqlTransaction` error, we will not catch it and this error
will be returned to the frontend (we lose the import report).
sentry-3969379125
closesodoo/odoo#143010
X-original-commit: b0e86e5c6d4b54134b91dbde3a145b551158b76d
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Before this commit, when changing the event organizer to a new one, if the new organizer was not synced with Odoo a ValidationError was being thrown requesting that the new organizer must be added as attendee when it shouldn't (since the new organizer is not synced with Outlook). Additionaly, there was an extra call being made to the method `_is_microsoft_calendar_valid()` in the user synchronization checking which should be removed.
After this commit, this restriction is removed: the new organizer won't need to be added as attendee during this change of event organizers and the extra call to `_is_microsoft_calendar_valid()` is removed.
Issue from: 3450045
closesodoo/odoo#142989
X-original-commit: 79ec916580452a49147600441eb8d09a98322665
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Before this commit, when Odoo faced an internal error and lost the current synchronization token with Microsoft, after fetching events from Graph API an `410 Gone` was being thrown carrying the `SyncStateNotFound` code.
Since we didn't handle this error code, we were experiencing a traceback after the request:
```
2023-11-15 09:16:15,046 4 ERROR report-one-16-0-staging-1-10315840 odoo.addons.microsoft_account.models.microsoft_service: Bad microsoft request : b'{"error":{"code":"SyncStateNotFound","message":"The sync state generation is not found; generation=25;[highest=28][28][26][27]."}}' !
Traceback (most recent call last):
File "/home/odoo/src/odoo/addons/microsoft_account/models/microsoft_service.py", line 154, in _do_request
res.raise_for_status()
File "/usr/lib/python3/dist-packages/requests/models.py", line 943, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 410 Client Error: Gone for url: https://graph.microsoft.com/v1.0/me/calendarView/delta?%24deltatoken=MOCK_TOKEN_HERE
2023-11-15 09:16:15,051 4 ERROR report-one-16-0-staging-1-10315840 odoo.http: Exception during request handling.
Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/http.py", line 2003, in __call__
response = request._serve_db()
File "/home/odoo/src/odoo/odoo/http.py", line 1589, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/home/odoo/src/odoo/odoo/service/model.py", line 133, in retrying
result = func()
File "/home/odoo/src/odoo/odoo/http.py", line 1616, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/src/odoo/odoo/http.py", line 1820, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/src/odoo/addons/website/models/ir_http.py", line 237, in _dispatch
response = super()._dispatch(endpoint)
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_http.py", line 154, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/odoo/http.py", line 697, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/odoo/addons/microsoft_calendar/controllers/main.py", line 55, in sync_data
need_refresh = request.env.user.sudo().with_context(sync_context)._sync_microsoft_calendar()
File "/home/odoo/src/odoo/addons/microsoft_calendar/models/res_users.py", line 99, in _sync_microsoft_calendar
events, next_sync_token = calendar_service.get_events(self.microsoft_calendar_sync_token, token=token)
File "/home/odoo/src/odoo/addons/microsoft_calendar/utils/microsoft_calendar.py", line 20, in wrapped
return func(self, *args, **kwargs)
File "/home/odoo/src/odoo/addons/microsoft_calendar/utils/microsoft_calendar.py", line 152, in get_events
events, next_sync_token = self._get_events_delta(sync_token=sync_token, token=token, timeout=timeout)
File "/home/odoo/src/odoo/addons/microsoft_calendar/utils/microsoft_calendar.py", line 20, in wrapped
return func(self, *args, **kwargs)
File "/home/odoo/src/odoo/addons/microsoft_calendar/utils/microsoft_calendar.py", line 111, in _get_events_delta
raise e
File "/home/odoo/src/odoo/addons/microsoft_calendar/utils/microsoft_calendar.py", line 105, in _get_events_delta
events, next_sync_token = self._get_events_from_paginated_url(
File "/home/odoo/src/odoo/addons/microsoft_calendar/utils/microsoft_calendar.py", line 20, in wrapped
return func(self, *args, **kwargs)
File "/home/odoo/src/odoo/addons/microsoft_calendar/utils/microsoft_calendar.py", line 76, in _get_events_from_paginated_url
_, data, _ = self.microsoft_service._do_request(
File "/home/odoo/src/odoo/addons/microsoft_account/models/microsoft_service.py", line 173, in _do_request
raise error
File "/home/odoo/src/odoo/addons/microsoft_account/models/microsoft_service.py", line 154, in _do_request
res.raise_for_status()
File "/usr/lib/python3/dist-packages/requests/models.py", line 943, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 410 Client Error: Gone for url: https://graph.microsoft.com/v1.0/me/calendarView/delta?%24deltatoken=MOCK_TOKEN_HERE
```
After this commit, everytime we receive the `SyncStateNotFound` code from Microsoft, we will trigger the full synchronization with Graph API. This way, the outdated token will be replaced with a brand new token. A function which checks if the full sync is required was added in order to be mocked by the new unit test, since it is necessary mocking its return value for testing if a given `HTTPError` with the 'SyncStateNotFound' error code will call the all events fetching.
closesodoo/odoo#142982
Task-id: 3597211
X-original-commit: 54ae2f2b469e3bd5294386b882e57d7519dc044a
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
- Have a delivery order sent to a shipper and done
- Return this delivery order completely (without a shipper, might not be important)
- Return of the return to resend to the customer (with a shipper and therefore a tracking number)
This will lead to a endless loop as the move_origin_ids say so (might be a bug or not)
Anyway, we make sure that the logic makes sure that we do not process twice the same stock move.
closesodoo/odoo#143076
X-original-commit: 73b41f5fa403f2737302441ce0039ee138a408c0
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wolfgang Taferner <w.taferner@wtioit.at>
Steps to reproduce:
- Install modules: 'account_accountant', 'l10n_eg', 'l10n_eg_edi_eta'.
- Switch company to "EG Company".
- Configure "Large Cabinet Accounting" with ETA item code "10001138" and set Customer Taxes to "VAT 14%".
- In "Journal Customer Invoices", disable "Factur-X (FR)" under Advanced Settings -> Electronic invoicing. Also, set Branch to "Deco Addict", ETA Activity Code to "Accounting, auditing, bookkeeping and tax advice activities", and ETA Branch ID to 0.
- Update "Deco Addict" with Tax ID "204899053" and set building number to 2.
- Update "Azure Interior" with Tax ID "204899052" and set building number to 2.
- In Accounting -> Configuration -> Thumb Drive, create a new record using "EG Company" with 123 as both the ETA USB Pin and Access Token.
- Manually set the certificate in the Thumb Drive record.
- Create a new Customer Invoice with Customer set to "Azure Interior", Invoice Date as today, add a line item "Large Cabinet", set the Price to 0, remove "0% taxes" and add "VAT 14%", and set Journal to "Customer invoices in EUR".
- Confirm the invoice and attempt to "Sign Invoice".
Issue:
A traceback occurs with a divide by zero error in the invoice calculation when different currencies are involved.
Solution:
Refined _l10n_eg_edi_exchange_currency_rate function to calculate the currency exchange rate. Now, it ensures the division by amount_currency only occurs when it's not zero, preventing divide by zero errors during currency conversion in invoices.
opw-3580529
closesodoo/odoo#143064
X-original-commit: 14af8243188b86a0d654298feca6dc0980cbebeb
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Before this commit, when creating a move with a product having no label. The
label will be automatically fill with "Bacon Burger" in the report.
By adding a condition on the span, the span will be empty if the label is empty
and can still be modified in studio if needed.
closesodoo/odoo#143050
Task: 3604617
X-original-commit: c0ddba176e9837ed1808b772237dff51c99a430d
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
Before this commit, the modified test sometimes failed on runbot
because it couldn't click on "Create and edit..." in the many2one
dropdown. Here's what happened:
1) call editInput to write something in the many2one input
2) call selectDropdownItem to select "Create and edit..."
This was done without mocking setTimeout.
The problem is that editInput triggers the opening of the dropdown,
but as setTimeout wasn't mocked, that opening was delayed. Then,
selectDropdownItem first clicked on the input to open the dropdown,
and then clicked on the requested item. It might happen that the
click on the input actually closed the dropdown instead of opening
it, if it had been already opened via editInput. In that case, the
test failed because it couldn't click later on on "Create and edit".
This commit also improves the test utils to better log what really
happens: in this case, the dropdown isn't open at all, so we
detect that specific issue and log it with a proper message (which
is different than "the dropdown is open, but I can find the item
you're looking found).
Runbot issue 28207
closesodoo/odoo#143044
X-original-commit: 220d4325866330235ceccd61b8d1d00d8c919ba8
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Issue:
======
When using l10n_ar company , the public user (without sign in) will have
an access error on the address page when clicking on process checkout
from the website.
Steps to reproduce the issue:
=============================
- Install ecommerce + l10n_ar
- Go to website without signing in and add any product to cart and
process checkout
Origin of the issue:
====================
Public user doesn't have the right to read
`l10n_ar.afip.responsibility.type` and `l10n_latam.identification.type`
opw-3591440
closesodoo/odoo#142997
X-original-commit: ed020ce2942c8fb2ef43ea44bd3768fcc14cb45f
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Issue:
======
When we have 1 delivery method enabled that have pickup locations, it
will be selected by default and the pickup locations will never be
displayed.
Steps to reproduce the issue:
=============================
- Set up pickup locations carried for sendcloud (like mondial relay)
- Go through the website with just that shipping method available and
add a product to cart valid with the configuration of sendcloud.
- Go to checkoutout you will get the shipping method selected but no
pick up options
Origin of the issue:
====================
If the delivery method is already selected it will skip showing pickup
locations.
Solutions:
==========
Now there is another check to make sure that it will be skipped only
when the pick up locations are displayed.
opw-3569497
closesodoo/odoo#142958
X-original-commit: 7beb8767cd82f2938ffbb53ec496e1f817af8730
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Steps to reproduce:
-------------------
- add an alternative product B for a product A;
- go to product A page on ecommerce;
Issue:
------
The alternative product B is not displayed below
the product A.
Solution:
---------
Use the `o_dynamic_empty` instead of `d-none` to manage
display of the snippet.
opw-3568699
closesodoo/odoo#143032
X-original-commit: a90cf72bed889424eceef4643c53434d1ab3bf51
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Update the japanese tax group template names to
better fit the needs.
Task id #3315696closesodoo/odoo#143091
X-original-commit: 580495a53cf61bd57c609856b48772c6b5c9fe25
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Steps to reproduce:
- New DB
- Switch to russian
- Install stock app
Bug:
throw back is raised when setting up the data caused by a duplicate
operation type (Sequence Packing/Picking)
Fix:
apply the correct translation
note:
manual PR created since there's no russian translation on transifex
after 16.0
opw-3589539
closesodoo/odoo#143007
X-original-commit: 1486a08fd18fceba8c632141511354e9610f6dcc
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to reproduce:
1. Create a new product with a cost of 10 (std, manual)
2. Create an inventory adjustment to set the quantity to -3
3. Change the product's category to real-time
Now the valuation for this product is -30€ but the accounting part
has 30€, creating a difference of 60€.
Before this commit:
Changing the valuation to real-time while having a negative
quantity/value gives a positive value in accounting.
After this commit:
Changing the valuation to real-time while having a negative
quantity/value gives a negative value in accounting.
opw-3390692
closesodoo/odoo#143000
X-original-commit: 9a0e620d2fa1d5e55d73bc4920f26ef2ba82ce9d
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Walravens Mathieu (wama) <wama@odoo.com>
Paolo Gatti (pgi)