| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This error occurs when attempting to duplicate two actions in 'Server Actions'.
Steps to reproduce:
- Search 'Server Actions'
- Select any two Actions and 'Duplicate'
Traceback:
ValueError: Expected singleton: ir.actions.server(606, 701)
After this commit:
We are now able to duplicate multiple records.
sentry-6218495006
closes odoo/odoo#194118
Signed-off-by: Raphael Collet <rco@odoo.com>
|
|
Before this commit:
- Lot-serial dropdown not visible in the small UI.
After this commit:
- Displayed the lot-serial dropdown in the small UI.
opw-4551161
closes odoo/odoo#196957
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
|
|
Before this commit, if a many2one field was loaded with its data,
it would not get connected. For example, in the Chilean localization,
the account_move is loaded when capturing an order, but it would not
get linked, causing an error.
opw-4479284
closes odoo/odoo#196994
X-original-commit: 86fd956e8828117c82d74baa0d7ae04cff93b745
Signed-off-by: David Monnom (moda) <moda@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
|
|
|
|
Before this commit, the credit note's tax lines were causing an issue
during reconciliation because they were reconciled with both the invoice
and with the cash basis entry.
Reproduce:
* Enable cash basis accounting.
* On the tax that will be used, set:
Tax Exigibility: Based on Payment.
* Allow reconciliation on the associated account.
* Add a product without tax and save.
* Then, add a tax.
* Try to create and post a credit note for this invoice
opw-4281749
opw-4439671
opw-4358532
closes odoo/odoo#196933
X-original-commit: 09da61a1ef67be78f50c042afe650b2c3bea7539
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
|
|
When creating multiple preparation printers for different pos categories
you could have a case where an empty receipt is printed.
Steps to reproduce:
-------------------
* Create 2 PoS categories CAT 1 and CAT 2
* Create a first preparation printer for CAT 2
* Create a second preparation printer for CAT 1
* Create a product P1 for CAT 1
* Assign the two printers to a PoS
* Open PoS and add the P1 to your order
* Send the order in preparation
> Observation: Two receipts are printed and one of them is empty
Why the fix:
------------
When going over each printer to print the relevant changes, if the first
printer in the list has no changes it would always print an empty
receipt because `last_preparation_change` would always be empty. To fix
this we rely on `changes` to check if there are any changes to print on
this printer
opw-4462586
closes odoo/odoo#196808
Signed-off-by: David Monnom (moda) <moda@odoo.com>
|
|
*: holidays,holidays_attendance
The base.group_user did not have the access right to read overtime_id,
which is necessary for filtering allocations that do not have
a null overtime_id. The access right was granted to base.group_user
only when the allocation state is either draft or confirm.
In the test_expiration_date_2 the user needed to be a user_hruser
to have the access rights to edit the number_of_days.
task-4452360
closes odoo/odoo#196815
X-original-commit: 2bb61e4d534d23bf81a0b36f6ffcc27c0f6a6a0b
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
Current behavior:
As of now, whenever a journal is set to "Hash on Post", the user is
granted the secured group rights. This allows the user to see the
lock icon in the status bar, the extra default filters in the list
views of Journal Entries and Journal Items, and access to the Secure
Entries wizard.
However, if only entries from journals with "Hash on Post" are secured,
these features are not necessary. The user trusts Odoo to hash any and
all entries that are posted in that specific journal.
Expected behavior:
When "Hash on Post" is active, the user does not need any additional
user group. However, if even one entry is secured and does not belong
to a journal with the "hash on post" feature, the user will then need
access to the new features, such as the lock icon, default filters,
and the Secure Entries wizard.
Approach:
This commit removes the calls to _activate_group_account_secured()
when setting a journal to "Hash on Post". It also removes it from
the Secure Entries wizard. Instead, we add the key
'journal_restrict_mode' to the chains_to_hash, which indicates the
value of the journal's restrict_mode_hash_table field. If at least
one chain with moves does not have 'journal_restrict_mode', only
then we call _activate_group_account_secured() from _hash_moves().
This will only happen when the Secure Entries wizard is used,
hashing entries from all journals.
task-4348380
closes odoo/odoo#196748
Signed-off-by: William André (wan) <wan@odoo.com>
|
|
**Problem**:
The close icon on the file upload notification is misplaced, appearing at the
top-left instead of the expected position on the right.
**Solution**:
Adjust the button's position to appear on the right side of the notification.
**Steps to Reproduce**:
1. Open the Editor.
2. Upload a file.
3. Observe that the close button appears on the top-left instead of the right.
opw-4512322
closes odoo/odoo#195209
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
|
|
Issue: In the POS settings, even after disabling the preparation display option, it remains enabled after saving.
Steps to reproduce:
-In POS configuration
-Ensure the Pay after option is set to each order.
-Disable self ordering and uncheck the preparation display option, save.
Explanation: In res_config_settings.py of pos_self_order, https://github.com/odoo/odoo/commit/8ee8010cf67f20c4eb28a334cc943bfedf2dd0d1 added a check to ensure that the preparation display is enabled if self-ordering is active. However, it was still automatically enabling the preparation display even when self-ordering was disabled.
opw-4225668
closes odoo/odoo#192869
X-original-commit: fd924988cf514566bec5007bc292ec7b0e991e35
Related: odoo/enterprise#76696
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Signed-off-by: Guillaume Teboul-Tornezy (gute) <gute@odoo.com>
|
|
**Problem**:
In Safari, relying on the browser to add a space after automatic link creation
causes the cursor to be incorrectly positioned. This issue arises due to DOM
manipulations (adding and removing nodes) during the process.
**Solution**:
To ensure proper link insertion and cursor positioning, explicitly add the space
after the link and set the selection programmatically.
**Steps to Reproduce**:
1. Open the Editor on Safari.
2. Add the text "test.com".
3. Press the space key.
4. Observe that the link is created, but the cursor moves to the start of the paragraph.
opw-4441817
closes odoo/odoo#194989
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
|
|
Forward-port https://github.com/odoo/odoo/pull/193483 messed up and
removed important code of https://github.com/odoo/odoo/pull/172787.
This commit adds it back.
task-4547597
closes odoo/odoo#196801
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
|
|
With the introduction of Invoicing Enterprise (access to bank recon etc)
a new user group was created "Invoicing & Banks" (`group_account_basic`)
This group should also be able to access the customer statement / partner ledger (from the partner smart button)
Task-4465208
closes odoo/odoo#196936
Related: odoo/enterprise#78807
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
|
|
**Problem**:
When `u` or `s` tags are applied, changing the `font-size` wraps the
text inside these tags instead of applying it to the tags themselves.
For example,
`a<u>b</u>c` → `a<u><font>b</font></u>c`,
which results in an inconsistent appearance.
**Solution**:
Ensure that the `span` for font size is applied to the highest non-block
ancestor to maintain proper styling.
**Steps to Reproduce**:
1. Add text.
2. Apply underline.
3. Increase font size.
4. Observe that the underline remains the original size instead of
scaling with the text.
opw-3086072
closes odoo/odoo#196943
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
|
|
Before this commit, when the login screen was left idle using an
employee login, the screensaver would appear as expected. However, upon
user interaction (e.g., moving the mouse), the system would update the
previous screen to the screen saver. This causing issues during login
where the screensaver would be displayed.
opw-4494087
closes odoo/odoo#196472
Signed-off-by: David Monnom (moda) <moda@odoo.com>
|
|
The domain on the view overrides the domain on the model.
As both domains are correct, this commit moves the partial domain on
the view and adds it to the partial domain on the model.
task-4514485
closes odoo/odoo#196851
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
|
|
Versions
--------
- saas-17.4+
Steps
-----
1. Go eCommerce products page;
2. click on a product;
3. use browser's "Go back" button to go back.
Issue
-----
There's no going back.
Cause
-----
Commit 2efaa12fdb17 modified the `_setUrlHash` method used to manage
product attributes. One of the changes it made is modified the current
URL using `window.location.hash` instead of `window.location.replace`.
While both methods can make identical changes to the URL, a key
side-effect of `Location:replace()` is that the URL being replaced
won't get saved in the session's `History`[^1].
As this method is called the moment the page loads, modifying the URL
via `location.hash` will store the initial product page URL without
attribute hashes in the session history. Then when trying to navigate
back, the method will be called again immediately to apply attribute
hashes, again modifying the session history, making it virtually
impossible to leave the page without clicking a new URL.
Solution
--------
Use `history.replaceState` to update the current state, and not create
any new entries.
opw-4416701
[^1]: https://developer.mozilla.org/en-US/docs/Web/API/Location/replace
closes odoo/odoo#196858
X-original-commit: 90a9bcf8bc853e26080c2c254224a7c74d088bfc
Signed-off-by: Levi Siuzdak <sile@odoo.com>
|
|
Issue:
Curently, the reservation state of a production is computed from the
status of the move raws that are not picked. This includes moves wihtout
demands which should not infer with the reservation state at all.
Steps to reproduce:
- In the settings, Enable "Multi-Step Routes"
- Go to Inventory > Configuration > Warehouse Management > Warehouses
- Put your warehouse in 2 steps-manufacturing
- Create a final product (FP) tracked by Serial number, and 2 storable
components: COMP1 and COMP2
- Create a BOM for FP:
- Component lines:
- 1 x COMP1
- 0 x COMP2 !!
- Operations:
- OP1 with an instruction of type "register production"
1. Create an MO for 1 x FP > Confirm
2. Validate the pick transfer for 1 unit of COMP1
> Currently OP1 is marked as ready
3. Mark the component line of COMP1 as "picked"
> OP1 is in waiting status
Same result as 3:
3'. Go to the shopfloor > register production from the MO card
> This will pick the COMP1 raw move and OP1 will disappear because of
> the "ready" filter
Cause of the issue:
Since you manufacture in 2 steps, the state of the raw move of COMP2
is waiting even though its demand is 0 (before and after you validated
the pick move for COMP1). However, only non picked moves are considered
to be relevant in the computation of the reservation state of the MO:
https://github.com/odoo/odoo/blob/d8fc04f5875dbd3098e58f382d0cea3c7c7c38af/addons/mrp/models/mrp_production.py#L613-L621
Once you pick the COMP1 move which should be the only relevant one the
reservation state of the MO becomes computed solely based on the state
of the COMP2 raw move and becomes "waiting". In turns, this triggers a
recomputation of the state of the workorders and flagging it as waiting:
https://github.com/odoo/odoo/blob/d8fc04f5875dbd3098e58f382d0cea3c7c7c38af/addons/mrp/models/mrp_workorder.py#L148-L165
opw-4383004
closes odoo/odoo#196682
X-original-commit: 88235a0fd3415a608ac1b0322a6b1f048f8bcaed
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
|
|
The payment post-processing cron is run every 10 minutes to ensure
smooth operations, but waking up crons incurs a non-negligible
performance cost.
Since the `payment` module is automatically installed with the
`account` module, most databases have the `payment` module installed
with its cron, even if they didn't enable any provider.
This commit disables the cron until a provider is enabled.
task-4467217
closes odoo/odoo#196814
X-original-commit: 5104b13448beaf4e08c8aac8fea91a8e6273e203
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
|
|
This fix prevent blank screen (when offline) & inifinte loop (when in 3G or other low connection) on order screen.
- **Offline Mode:** When accessing the order screen offline, now the screen loads previously fetched orders and displays a "Limited Functionality" popup.
- **Slow Connection (3G):** Infinite loop (caused by repeated call to `await this.pos.getServerOrders()`) is fixed by ensuring orders load only once, even on slow connections using the flag `loadingOrderState`
closes odoo/odoo#196810
Task-id: 4550978
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
|
|
different than the move
closes odoo/odoo#196899
X-original-commit: d7036f82439b82c42ec8fb8076793ff817803367
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
|
|
The nocontent message for inventory counts was still referring to old
concepts from before the 17.0 Milk redesign (like the "CREATE" button
or the Import action in the Favorites menu).
This commit updates the message to correctly reference the new design
actions, corrects the English and escapes translations inserted into
HTML.
task-4550935
closes odoo/odoo#196908
X-original-commit: 80cebc8dd79a500aa68d0d2a662687dda5f928e6
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
|
|
explicitly.
Behavior Before the Commit:
Whenever you change the account type of a Cash and Bank account to a different type,
please ensure that the Reconcile option is set to True. However, if you later switch
the account type back to Cash and Bank, the Reconcile option will remain True and
will not automatically revert to False.
Fix: explicitly set reconcile to False for account_type 'Cash and Bank' in compute_reconcile
method.
Behavior After the commit:
Reconcile will be changed to false on changing the account type to Cash and Bank.
opw-4450088: https://www.odoo.com/odoo/my-support-tasks/4450088
closes odoo/odoo#196893
X-original-commit: 592038ca9b7c6e6376b2a845ba6304cb93e3b0e1
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
|
|
steps to reproduce:
- In the settings enable: Multi-Step Routes, Operations > Packages
- Create a storable prodcut
- Update the on hand quantity:
- 10 units in package PK
- Inventory > Configuration > Warehouse Management > Locations
- Create 2 warehouse locations: WH/LOC1, WH/LOC2
- Go to the barcode app and proceed with the scans:
1. Scan the internal transfer picking type
2. Scan WH/STOCK as a source location
3. Scan the package name (PK)
4. Scan WH/LOC1 as destination location
- Leave the barcode app without validation
- Go to the barcode app and proceed with the scans:
1 -> 3
4'. Scan WH/LOC1 as destination location
- Try to validate the picking
> Invalid operation: You cannot move the same package content more than
> once in the same transfer or split the same package into two location.
Cause of the issue:
As both pickings were treated via the barcode app, they generated picked
move lines related to the package. Both of these move lines have updated
the reserved quantity of the stock.quant present in stock:
- WH/STOCK, quantity: 10, reserved_quantity: 20.
When you try to validate the second picking, you will launch an
`_action_done` of its move line that will create a new quant in WH/LOC2
and update the quant in stock:
- WH/STOCK, quantity: 0, reserved_quantity: 10.
- WH/LOC2, quantity: 10, reserved_quantity: 0.
The error is raised just after since 2 quants with either a quantity or
reserved quantity are found:
https://github.com/odoo/odoo/blob/6349fb0362d881672616bb4b800bd32be82f9a5f/addons/stock/models/stock_move.py#L1910-L1917
Fix:
Since the check is made in order to check the consistency of result
packages moved by the current validation the "reserved_quantity" should
not matter.
opw-4456484
closes odoo/odoo#196634
X-original-commit: 3c2d34b426dcc839510f5c0754783a216c736874
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
|
|
**Current behavior:**
With a FIFO + real-time product, `ProductA`:
Creating a sale order with multiple order lines for ProductA,
processing the resulting delivery in 2 separate pickings via
backorder (1st delivery for the 1st line, 2nd delivery for the
2nd line), then invoicing the delivered product separately
result in an invoice with invoice lines which do not reflect the
value of the product at delivery time.
**Expected behavior:**
The SVLs generated from the deliveries should inform the
generated AccountMoves.
**Steps to reproduce:**
1. `FIFO-prod`: FIFO and real-time valuation & costing
2. Receive 12 units of `FIFO-prod` @ $100 per
3. Create a sale order with order lines:
* `FIFO-prod` `10 units` `price_unit=$100`
* `FIFO-prod` `2 units` `price_unit=$100`
4. Confirm the sale order, on the delivery, only receive the
first move for the 10 qty, backorder the other 2 qty
5. Receive the backorder, create an invoice- edit the invoice
lines so that 5/10 of line 1 and 2/2 of line 2 are invoiced,
then post/confirm
6. Edit the `standard_price` of `FIFO-prod` (e.g., $100 -> $50)
7. Create another invoice for the remaining quantity and post
8. Observe that the COGs lines on the invoice have been
calculated with a different price unit than the other invoice &
unit_price for the out SVLs
**Cause of the issue:**
When getting the price unit of a given anglo saxon invoice line,
there is no check that all the collected COGS lines are linked
to the sale order line which corresponds to the product and
product_qty that we are attempting to value.
This creates an imbalance in the qty calculation later here:
https://github.com/odoo/odoo/blob/f2728b2fe13a355ecb301a3714639b8a07f418b4/addons/stock_account/models/stock_valuation_layer.py#L202-L211
when the valuation is actually performed.
**Fix:**
Only consider posted COGS lines for the sale order line with the
product qty that is getting valued when calculating
`qty_invoiced`.
opw-4321363
closes odoo/odoo#196859
X-original-commit: 4046f01afd08e2702897fe9e208f95bbd899dd98
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Vincent Ethan <etvi@odoo.com>
|
|
Sign the CLA in name of Letzdoo https://www.letzdoo.com
closes odoo/odoo#196914
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
closes odoo/odoo#196599
X-original-commit: cfe602426aac9ddb446de1e265062cd8d0c990bc
Related: odoo/enterprise#78598
Signed-off-by: Laurent Smet (las) <las@odoo.com>
|
|
When AE localization extends the default invoice report,
they replace the `<th name="th_taxes"><span>Taxes</span></th>` with
`<th name="th_taxes"><span t-if="...">VAT</span><span t-else="">Taxes</span></th>`.
Then when AR localization is installed, it will replace the first div
with the t-if. We end up in a situation with a `<span/>` followed by
a `<span t-else=""/> which raise an error because it is expecting
a `t-if`.
task-no
closes odoo/odoo#196863
X-original-commit: 1fe06a9bb2d9c28d954f1b24309e95815fe27e90
Signed-off-by: Laurent Smet (las) <las@odoo.com>
|
|
In SEPA payment files, when a structured reference is used, it is put
in the section `RmtInf/Strd/CdtrRefInf/Ref`. This section has a
maximum length of 35 characters. Since we only use structured references
that are always less that 35 characters, this should not be a problem.
However, the way we validated the structured reference was by performing
a `re.match()`, which only matches from the beginning of the string. So
if more characters would be after the structured reference, it would
still match and it would be possible to go beyond 35 characters.
In this commit, we fix this by using a full match instead of a match
from the beginning.
opw-4357554
closes odoo/odoo#196841
X-original-commit: 6583505a482094ec24907509c19aa8d853588b1d
Signed-off-by: Hugo Poncelet (hupo) <hupo@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
|
|
|
|
The `previous_product_uom_qty` keyword argument was passed as a
positional parameter to `_action_launch_stock_rule`, preventing that
method's overrides from passing it back with its key name when other
overrides pack the kwarg with the `**` operator.
This commit ensures that the argument is now passed correctly with its
key name. It also makes the overrides kwargs-agnostic by packing and
unpacking them with `**`, thus preventing future issues related to
signature changes in the parent method.
closes odoo/odoo#193457
Related: odoo/enterprise#77839
Related: odoo/documentation#11823
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
|
|
This commit adds the possibility to fetch attributes of a template
configured on Gelato to automatically create the corresponding variants
in Odoo. When such variant is included in a sales order, the order is
forwarded to Gelato to trigger the printing and dropshipping of the
product.
task-3935688
Part-of: odoo/odoo#193457
Related: odoo/enterprise#77839
Related: odoo/documentation#11823
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Co-authored-by: Antoine Vandevenne (anv) <anv@odoo.com>
|
|
Before this commit, it wasn't possible to filter products by category
when searching. This functionality was available in previous versions
but was removed during refactoring.
opw-4439314
closes odoo/odoo#193503
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
|
|
The upgrade script is supposed to create xmlids for
french banks that were already created from csv, if
it matches custom records that have unusual bic, it
is better to skip the whole record. Replacing the
spaces or unsupported characters in the xmlid will
result in custom records looking like they come from
standard module.
closes odoo/odoo#195740
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
|
|
The Partner Autocomplete service was unreliable when used on a database
hosted under a subdomain of odoo.com (i.e. from *.odoo.com).
This was caused by a combination of the CORS policy of the Autocomplete
API of Clearbit and the caching of the browser.
If the user performed a first request with search query "Odoo" from
https://a.odoo.com, the browser would cache the results, including the
`Access-Control-Allow-Origin` header set to `https://a.odoo.com`.
The same request performed from https://b.odoo.com would lead to a CORS
policy error as the browser would use the cached response from earlier
request.
This commit addresses the issue by disabling the caching of the requests
made to the Clearbit Autocomplete API.
closes odoo/odoo#196480
Signed-off-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>
|
|
This commit :
- adds missing VAT 0% export (goods) tax
- correct erroneous fiscal position
- reactivate taxes that were deactivated with https://github.com/odoo/odoo/commit/401a961258e991151370899d4b61809879d5a5a8 after reconsideration
closes odoo/odoo#196753
Task: 4453629
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
|
|
Since HS Code field is now also used in USPS connector, the help text of
`hs_code` field on `product_template` needs to be updated. Also the POT
file containing module titles and descriptions is updated.
Task-3759325
closes odoo/odoo#196770
X-original-commit: bcd172900049d1a24e3b9ac15030c0b1e8661558
Related: odoo/enterprise#78698
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Mohammad Abdulmoneim (abdu) <abdu@odoo.com>
|
|
Current behavior:
The previous closing amount is used instead of the cash opening when printing the session report so the expected cash amount is wrong.
Steps to reproduce:
Open a PoS session with 100€ in the cash register and close it.
Reopen the session and enter 50€ in the cash register.
Make a sale for 10€, using cash payment.
Close the session and print the session report.
The expected cash amount will be 110€ when it should be 60€.
Fixes opw-4497263
closes odoo/odoo#196771
X-original-commit: 822a946122d8d7f3faf18767d42717f1e9654f9c
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Signed-off-by: Pierre Courtoy (pco) <pco@odoo.com>
|
|
Scenario:
- create a sale order and confirm it
- create two partial down payments for that sale order and confirm them
- create a invoice for the remaining amount and confirm it
- send and print the invoice (with Send to Tax Agency selected)
Result:
Traceback error is raised:
> ...
> File "addons/account/models/account_tax.py", line 2475, in _dispatch_negative_lines
> line.setdefault('discount_amount', line['discount_amount_before_dispatching'])
> KeyError: 'discount_amount_before_dispatching'
Why:
bbe04fb62916ae326c830e89b2664dfd32b62b75 was modifying the list
base_lines while looping over it, so we would not iterate over all
elements, for example:
> l = [5, 6, 7, 8]
> for i in l: print(i);l.remove(i)
shows 5 and 7
Notes:
Without the fix, the added test fails with the error given above.
The same code is in 17.0 but doesn't cause this error because we have
two loops. One that sets 'discount_amount_before_dispatching' and after
that one that remove downpayment from base_lines. But the fix should
still be backported because it works by chance.
opw-4496310
closes odoo/odoo#194949
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
Steps to reproduce:
- Install Accounting
- Create a tax with the following configuration:
* Tax Type: Purchases (also reproducible with Sales)
* Included in Price: [any]
* Affect Base of Subsequent Taxes (include_base_amount): [checked]
* Base Affected by Previous Taxes (is_base_affected): [checked]
* Distribution:
% | Based On | Account | Tax Grids
-----------------------------------------------
| Base | | +Tag_1 +Tag_2
100.00 | of tax | Account X | +Tag_3
-100.00 | of tax | Account Y | -Tag_4
(Or FR localization and "20% EU G" purchase tax can be used)
- Create a bill
- Add a line with the created tax
- Check journal items
Issue:
The tax tags of the base line are also added to first tax line.
Cause:
When a tax is "include_base_amount", the tags of its base line is
propagated to the tax lines of the following taxes.
However in this case, as there are several tax lines for the same
tax, the system propagate the tags to the second one as if it was
coming from another tax.
Solution:
Check if the tags are coming from another tax before adding them.
opw-4510882
closes odoo/odoo#195837
Signed-off-by: Laurent Smet (las) <las@odoo.com>
|
|
eTransport platform
Romania requires its companies to send information of all transports of goods on Romanian territory to a specific web service on their eTransport platform.
This commit implements a way to gather all the necessary data needed to send the eTransport document (from a stock.picking or a stock.picking.batch) and the actual sending of this document to the eTransport platform.
Authentication:
the authentication needed to interact with the eTransport platform is the same as (and was already implemented in) the l10n_ro_efactura module. see [eFactura PR](https://github.com/odoo/odoo/pull/144061)
eTransport flow:
1. Add the necessary eTransport data to a delivery/batch transfer
2. send the eTransport document to ANAF
3. the document gets processed by ANAF
4. Fetch the status of the document:
- which can result in an error, in which case the flow starts again from the beginning with the corrected data
- or in a success
5. optionally send corrected document data to ANAF in which case we go back to step 3.
task-id: 3810735
closes odoo/odoo#196201
X-original-commit: 68c70be7c0bd8954b3c3c4d45d53c9b1a70de50e
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Allesio Pellicciotta (peal) <peal@odoo.com>
|
|
This commit creates a new widget "dynamic_selection", that enables us to
create selection fields with dynamic options on the views.
To make it possible, we need 2 fields; one as the string of available
options separated by comma, and the other as the actual selection field
we want to make dynamic.
The available field are passed in the xml through the options of the
widget. Of course, the mentioned available must also be present (usually
with invisible=1) for this field to function. Otherwise, it will just
show an empty selection.
Task-id: 3358316
X-original-commit: 0dcbfe13a2da634bc5bbd2e8862820387b090d22
Part-of: odoo/odoo#196201
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Allesio Pellicciotta (peal) <peal@odoo.com>
|
|
HTML content is often saved as XML (i.e. through templates) and saved as such in
the database. This introduces issues when elements are written under their
`self-closing` format (i.e. `<a/>` or `<br/>`) as browsers will incorrectly
parse these values as HTML by adding a closing tag at an arbitrary position
which may modify the initial nodes configuration. This can be prevented by
post-processing untrusted content before the html parsing.
This commit is an overhaul of:
https://github.com/odoo/odoo/commit/26b922ef5cad42da7e188195e919e54878d472fc
https://github.com/odoo/odoo/commit/1a8a943d8373864165cb513b3767b866d626fad8
https://github.com/odoo/odoo/commit/4e547b24a323f8e59a11c5b78cbea38effc37938
in order to apply the conversion at critical entry points for editor assets:
- HtmlField is an entry point for data coming from the server, stored on the
record. Every access of the record data should not be trusted and go through
the post-processing.
- HtmlViewer is an entry point as it can be used as a standalone (see
`website_knowledge`, or the HistoryDialog) for data coming from the server.
- Editor is an entry point as it was developed to be useable as a standalone.
task-4547973
closes odoo/odoo#196442
Related: odoo/enterprise#78532
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
|
|
**Current behavior:**
With Anglo-Saxon accounting, for some tracked product, with FIFO
and real-time valuation:
Making a purchase order in some foreign currency, having some
exchange rate for today, receiving the product, then dating the
vendor bill to some future date with a different exchange rate
will result in exchange difference journal entries when the bill
is posted.
**Expected behavior:**
We shouldn't see exchange difference entries, as there are
pending corrective valuation entries which have simply not been
posted yet.
Reconciliation should be deferred until these moves are no
longer in draft.
**Steps to reproduce:**
1. Activate another currency, define some rate for today and
another (different) rate for tomorrow
2. Create a product with FIFO and real-time costing & valuation
3. Create an initial purchase for the product, receive then bill
normally
4. Create another purchase order and receive the product
5. Create the invoice, set the invoie date for tomorrow
6. Post the invoice -> Open the `Exchange Difference` journal to
see the entries which should not have been generated
**Cause of the issue:**
After creating the AMLs which represent the difference in
reception/bill unit price of the product, they are caught here:
https://github.com/odoo/odoo/blob/971400771a31c05641a8672f6b1d85afaa9c4a19/addons/account/models/account_move.py#L3575
and designated as future moves, not to be posted at this time.
At the end of the `_post()` stack: https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/addons/stock_account/models/account_move.py#L229
where there would normally be some `correction_amls`, they
weren't created here because the AMLs for the price diff were
not posted- so the price diff entry is generated.
**Fix:**
Wait for pending (`state == 'draft'`) AMLs that are part of some
`AccountMove`'s valuation to be no longer in draft before
allowing reconciliation with a currency exchange difference.
opw-4266652
closes odoo/odoo#196469
X-original-commit: 81006955b0c0fa07ab8c363ffa592b1293442e8c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Vincent Ethan <etvi@odoo.com>
|
|
Running the “test_workcenter_with_resource_calendar_from_another_company”
without demo data occurs an error because the resource calendar.
closes odoo/odoo#196756
X-original-commit: 4f8de061f66dc95dc8d42cdb226338cb94cdd4d9
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
|
|
This commit adds python 3.13 opcodes that would be necessary to
use safe_eval and qweb
closes odoo/odoo#196794
X-original-commit: 594e4afffe6f9f6ab14de82622ccd10e9f23d4d6
Signed-off-by: Walravens Mathieu (wama) <wama@odoo.com>
Signed-off-by: Florian Vranckx (flvr) <flvr@odoo.com>
|
|
closes odoo/odoo#195108
X-original-commit: a9558087affdeffaa9a5bf41d4076bed4b3f4bcd
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
The "Form" template uses col-X classes, unlike most snippets that use
col-lg-X classes. This discrepancy was not completely accounted for in
the width resizing logic, causing the form field width to default to 1
when resizing was attempted on a form field without col-lg-X class and
with none integer width.
Steps to reproduce :
- Enter edit mode.
- Drag and drop a "Big Boxes" block into the page.
- Drag and drop a "Form" block into one of the "Big Boxes" columns.
- Select a field of the form.
- Resize it by dragging the right resize handler.
- Bug: The width of the field is set to 1 col.
task-4370763
closes odoo/odoo#196610
X-original-commit: 56529b826512f8294bd5cf3ff2f9cc8e0b21bea5
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
|
