Applied fixes:
- a lot of translations were outdated, not matching official ones
- box 205 was missing
- box 289 had translation of missing box 205
- box 200 had translation of the section
- boxes 381a and 381b removed, completely outdated: we already removed all other 3X1 boxes.
- boxes 200,299,479 had wrong computation
- reordering lines to match the report
Source: https://www.estv.admin.ch/estv/fr/accueil/taxe-sur-la-valeur-ajoutee/decompter-tva/formulaires-tva.html
task-3349511
closesodoo/odoo#145328
X-original-commit: c43f34b
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
If you have the backend in a language A but the website in English only,
you can:
1) modify a record's (event, product...) name in language A (say "New
Name").
2) visit the page `/new-name-11` => the server will redirect you to the
English page `/origin-11`, with the only slug that actually exists on
the website. Chrome caches the redirection.
3) give the same name in English as in language A, try to visit
=> the server now wants to access `/new-name-11`
=> Chrome uses the cache to redirect `/new-name-11` to `/origin-11`,
=> the server tries to redirect to `/new-name-11`
=> infinite loop, Chrome puts an end to it after ± 20 redirects.
In effect, Chrome injects a "Too many redirects" layout inside the
iframe, which in turn raises a CORS error when the app tries to update
it.
At the time of this commit, the flow described here should be expected
of users, because the translation UI in the backend is not clear: the
default field displayed is in language A even though the website does
not use it, and the way to update translations is not obvious (you have
to click on the language tag, which doesn't look like a button).
Another way to artificially reproduce the issue would be:
- Create a website.redirect from /dog to /cat
- Same from /cat to /dog
- Go to /@/dog
After this commit, if we detect that behavior, we reload the iframe with
a new query parameter, making the URL brand-new (and not cached) for
Chrome.
opw-3479651
closesodoo/odoo#145306
X-original-commit: 16d47ddf128f31f13e8d0d74597635faf7f9702a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Before, the websocket client was built manually, usign string
concatenation.
Now, urllib.parse() is used to appropriately adapt the database URL.
This update enhances security.
closesodoo/odoo#144303
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Current behaviour before commit:
When pressing crop button, crop widget is not getting
opened and 'connection lost' notification is appeared.
This happens because in wysiwyg.js file _rpc function
does not get the proper arguments from loadImageInfo
function.
Desired behaviour after commit:
Now, _rpc function is removed from wysiwyg.js as it
doesn't need anymore and _serviceRpc is passed directly
through the props. As result crop option works.
task-3546160
closesodoo/odoo#138482
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Steps:
- Open sales.
- Go to products.
- Create a new product.
- Keep the 'Can be sold' option unchecked.
Issue:
- If a product is not sellable then the user should not be able to create
invoicing policy 'Based on Timesheets' or 'Based on Milestones'.
Fix:
- We are raising the user error 'This option is only for sellable products.'
when a user tries to select any of these two options.
task-3378532
closesodoo/odoo#145631
X-original-commit: 94982163f81175c9d2d670dc28704a716696604f
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps:
- Open Project
- Go to Tasks > My Tasks or All Tasks
- Create New Task
- Create Project from Quick Create
- Clicking on Save, will give a Validation Error
Issue:
- Validation Error is raised and thus, we aren't able to add the project and
thus creating a task.
Cause:
- Due to the addition of context, the default_type_ids isn't obtained, and thus
the SQL error occurs as the name of the task stage isn't set which is a mandatory
field.
Fix:
- removing the context from the form view of Quick Create and set the stage
closesodoo/odoo#145599
Task: 3378510
X-original-commit: 83119d5de49ae69d08a0f798453d9c5c56b2276a
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Following fdb692c25b:
- when creating/unarchiving an employee, we should only create global
time-off of the same company as the employee itself
- when computing the working hours relative to the GTO, if we had both
calendar GTO and company GTO (not linked to a specific calendar), we
were not correctly creating calendar GTO; we should merge those
intervals intead of company GTO interval simply overwriting calendar
GTO intervals
closesodoo/odoo#145596
Task-id: 3619083
X-original-commit: 8ec0c6c106352c19e5c7b5613be2f610fa6e0adb
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In the `onMounted` hook of the calendar renderer, the given callback
function will schedule a new function call using `setTimeout` with a
delay of 0 if some conditions are satisfied. The scheduled function will
then trigger a scroll in the calendar view to display a precise timeslot.
If the component is destroyed before the scheduled function is executed,
the scheduled function may trigger an error as the root element of the
calendar will be removed from the DOM when the component is destroyed.
This commit will fix that issue by checking that the root element of the
calendar exists before calling the `scrollToTime` function.
Steps to reproduce the error:
1. Open Knowledge
2. Open the template gallery
3. Select the template "Sprint Calendar"
4. Quickly apply the template
=> If you have the right timing: a traceback will be displayed indicating
that the function `scrollToTime` is not defined on `null`.
TO BE: No traceback should be displayed when applying the template.
task-3627780
closesodoo/odoo#145292
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
When a tour fails, the tour system is supposed to log the failing
step (with the 3 previous/next steps). Before this commit, this
didn't work, and the first 3 steps were always logged, no matter
which step failed.
This didn't work because to determine the failing step, we try to
find the step from the list of steps, with reference matching
(steps are objects).
However, since [1], steps are obtained from a getter which calls
the steps function of the tour, so they always get a new version
of the steps.
This commit fixes the issue by memoizing the steps, such that the
function is called only once, and we keep the same references to
the step objects.
Note that this could be reworked in master to make it more robust
(e.g. finding steps based on ids).
[1] https://github.com/odoo/odoo/commit/81be42d8f9421e796087325c99aa4289d3912352closesodoo/odoo#145385
X-original-commit: 16ffd4d0bcb705c86fedd8dc7e6dd749c35eb5bc
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
On deletion of records, foreign keys are updated.
For larger tables (like account.move, account.bank.statement.line) this could take some time.
adding a "not null btree index" on sparsely populated many2one fields significantly improves performance.
In the analysis of deleting a bank statement line.
Before:
7.4s to delete the bank statement line (missing index on suspense_statement_line_id consuming 99% of the execution time)
3.8s to delete the corresponding account move
After:
With the indexes, a 700x performance improvement was found.
This opportunity is taken to add an index on all many2one fields to account.move & bank.statement.line.
Issue report by @tsb-odoo
closesodoo/odoo#145643
X-original-commit: f10b87991cc72f5e16b587b6c9ede7e338ec79ac
Related: odoo/enterprise#52466
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
SG Government has announced to change the GST-rate
on 01 Jan 2024 MN from 8% to 9%
Changes:
- Added new taxes (8% -> 9%)
- Added tax groups
- Added migration script to l10n_sg to apply those changes
task-3454556
closesodoo/odoo#145686
X-original-commit: 3d406214fb226ffe3aa222c422472bcc549a53cd
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
The issue:
the default currency for Montenegro is LYD (Libyan Dinar) instead of EUR
The fix:
Set it to EUR
opw-3601783
closesodoo/odoo#145668
X-original-commit: 97c57c8dbb0f6ae19619c963552552454f92da93
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Based on 50a91e0c531ec05a432cd8c468b74db27bd30985. By default
pos_stripe does the authorization and capture in two steps. This is
not supported for eftpos payments [1]. It can be supported in two
ways:
- always auth + capture in one step with the `automatic`
`capture_method`, or
- only auth + capture when manual isn't possible with the
`manual_preferred` `capture_method`
Although both could work, `manual_preferred` was chosen because:
- it's a bit simpler to figure out whether to capture the payment in
the frontend (we can just check card_present.brand),
- this keeps non-eftpos transactions the same, which is more in line
with our stable policy
For completeness pos_restaurant_stripe was updated to not capture
these eftpos payments, although this style of tipping isn't used in
Australia.
To test similar steps as in 50a91e0c531ec05a432cd8c468b74db27bd30985
need to be taken:
1/ use an Australian Stripe account,
2/ allow discovery of simulated readers by passing {simulated: true}
to this.terminal.discoverReaders()
3/ manually simulating an eftpos payment via the browser
console (necessary per payment) [2]
To be safe this also guards against the possibility of there being no
`charges` key on the payment intent. This was done elsewhere with
6a6057caf63d7e6a60dac190b2ea1ebb954d8f6a. It does seem that Stripe
rolled back this change (maybe only for Stripe Terminal intents),
because I always receive `charges` with the latest API
version (2023-10-16). Additionally,
50a91e0c531ec05a432cd8c468b74db27bd30985 has been live for 3 months
without issues, it would have caused errors if `charges` was missing.
[1] https://stripe.com/docs/terminal/payments/regional?integration-country=AU#integration-requirements
[2] posmodel.payment_methods[X].payment_terminal.terminal.setSimulatorConfiguration({testPaymentMethod: 'eftpos_au_debit'})
opw-3523604
closesodoo/odoo#142603closesodoo/odoo#145665
X-original-commit: ffddab3aa437c997fd1d63d592b47598a4bad9f5
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Joren Van Onder (jov) <jov@odoo.com>
When changing the fiscal country of the company, the country of all taxes and tax groups belonging to this
company are recomputed. However, moving taxes from one country to another doesn't make any sense since
they are part of a chart template specific to a single country.
This becomes more annoying when there are custom fields that depends of the current country in some localization.
In this case, changing the country of the company will also erased some data coming from the chart template.
At this point, the user will be forced to reload the whole chart template to recover those data.
closesodoo/odoo#145423
X-original-commit: 58393169fb51db387562baaa67e9c9ca52ed066b
Related: odoo/enterprise#52331
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Laurent Smet (las) <las@odoo.com>
The aim of this commit is to leverage the power of the tax prediction
when possible to improve the quality of the tax retrieval of the edi
import.
Context:
The tax prediction happens when the invoice is given manually or with
the OCR but doesn't happen when it's imported by EDI because the tax is
already set by the edi.
Before this commit:
During EDI import, the tax retrieved could always be the same even if
the user make some modification to the previous bill.
After this commit:
The tax retrieved leverage the previous data to get better quality
result regarding tax retrieval.
closesodoo/odoo#145572
Task-id: 3626501
Ticket-id: 3531473
X-original-commit: 62bd397490cfcb21c2c92d67d761f68850054039
Related: odoo/enterprise#52430
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Before this commit, during an onchange, when we received an update command
for an x2many referring to an unknown record on the front end (does not
have a Datapoint Record) during the save, we sent all the contents of
these commands without removing the readonly fields.
In this commit, we're going to filter all the readonly fields according
to the backend (fields). We're not taking modifiers into account because
the command refers to an unknown record, so we don't have the data to
evaluate modifiers correctly.
How to reproduce:
- Go to a form view with an x2many field
- Edit a field that causes an onchange
- The onchange command returns an "update" command for an x2many record
which is not on the actual page (unknown record) with a value which is readonly
according to the backend
- Click on the Save button
Before this commit:
The "update" command doesn't contain the readonly field
After this commit:
The "update" command contains the readonly field
Task ID: 3607260
closesodoo/odoo#145556
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes two issues that occur when a customer has a very long
name within the `point_of_sale` module.
1. If you create a customer with a very long name, this will cause the
left panel to extend, pushing the numpad to the right, making it out of
use.
To fix this issue, we add a `mw-50` class to the container, so that we
limit its growth, and we validate the `text-truncate` class applied to
the customer name.
2. If you use the `point_of_sale` module on a mobile device, the buttons
related to main actions such as refund, customer note, billing etc are
wrapped into a `more` button. When you open that interface, if the name
of the customer is too long, it will overflow the parent container and
so generates an overflow.
To fix that issue, we simply add a `text-truncate` class to the customer
name to be sure it doesn't generate any overflow.
task-3631878
closesodoo/odoo#145531
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
The SFU is a server used to relay streaming between the participants of
a call to provide better scalability and performance than the current
peer-to-peer connections.
The required fields have been added in https://github.com/odoo/odoo/pull/138581
* `/mail/static/lib/discuss_sfu` contains the client code that is used
by the odoo client to interact with the SFU.
From: https://github.com/odoo/sfu/releases/tag/v1.0.0
* The Json Web Token code has been extracted from `web_push` while
adding support for the HS256 algorithm, to be used as the authentication
method between the SFU and Odoo.
* The python code has been updated so that the odoo server requests a
channel from the SFU when going above a participant threshold, and swap
the participants to a SFU connection afterward.
* `rtc_service.js` has been updated to support both peer-to-peer and
SFU modes.
* The `call_context_menu` has been updated to display information
relative to the SFU connection when in SFU mode.
task-2765922
closesodoo/odoo#132153
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Avoid invalidating cache when not needed.
This improves a lot performances.
Closes#143403
Fixes a bug which causes that: self.flush() and self.clear_caches() were called on every property write/update and delete.
Known at least in V14/15/16/17.
closesodoo/odoo#145549
X-original-commit: b444330050a4d98e7ade42a30a6a27522b5cf4c8
Related: odoo/enterprise#52395
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
before this commit, the pricelist concept is added in
label printing in this commit: 168b56e
and missed to adapt the zpl reports to respect the
selected pricelist in the wizard
after this commit, the price printed in the zpl
product label will be based on the selected
pricelist in the wizard
closesodoo/odoo#145518
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Test "Load 100 recipients at once" goes from 2500ms to 1200ms on my
machine.
closesodoo/odoo#145442
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
onChange on each field is extremely costly, and it's not actually used
unless the field is computed or sorted.
Time of test "Load 100 recipients at once" is divied by more than 2.
Part-of: odoo/odoo#145442
`operators` object only contains 3 specific strings as key, and most
domain items are arrays. Checking the type of the item to avoid a costly
and failing `in` check, as well as using direct key access, allows
gaining a lot of time.
The method going from 60ms to 6ms when running the test
"Load 100 recipients at once" on my machine, and the specific line tends
to 0ms.
Part-of: odoo/odoo#145442
Partially revert the 'table-responsive' layout introduced by commit
https://github.com/odoo/odoo/commit/5abccc.
The addition of the 'table-responsive' class in commit https://github.com/odoo/odoo/commit/5abccc
effectively addressed the overflowing of very long product names without
whitespace. However, it inadvertently introduced a new issue by
partially concealing the "Download" dropdowns for digital products.
To mitigate this problem, this commit disables the
'table-responsive' layout when website_sale is installed.
This adjustment preserves the accessibility of the "Download"
dropdowns while still offering a workaround for accommodating lengthy
product names.
task-3335488 (bugfix)
task-4720 (rd-design)
closesodoo/odoo#144680
X-original-commit: ce9c5ff8af739a3f9be3ffa98c6119b0c346a53c
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Exports the sortableDrag function, so it can be used in other modules (like account_reports for example).
closesodoo/odoo#145027
Related: odoo/enterprise#50283
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
If someone wants to show the label of the state_selection field then
it can be shown
like-
<field name="xxx" widget="state_selection" options="{'hide_label': False}"/>
task-3475416
closesodoo/odoo#136901
Related: odoo/enterprise#48060
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Since the refactoring of the JS relational model (d4fe919d),
the list is not fully re-rendered after field updates,
such that a fixed narrow column width is added at first rendering
if there are no triggers shown on any row, and cannot be updated.
We need to override it by providing a `width`, which was already
a supported attribute but not declared in rng.
Task-3512604
closesodoo/odoo#135895
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit we had an issue when a product's description took
more than one page. In this case, the following `<tr>` was overlapping.
By removing this line we remove an old fix that seems not working
anymore... It looks like it was needed when a customer wanted to repeat
the table header on each page. This use case is supported by Odoo as
we suggest it as a customization in the code, see here:
"<!-- In case we want to repeat the header, remove "display: table-row-group" -->"
This feature is still working without this fix except when a line
overflows onto another page but the removed fix doesn't help anyway...
There is another line that refers to this fix for accounting reports
but we prefer to keep this commit minimal and clean it in master.
Note that this bug is also present in 15 but as this issue is quite old
and tricky we prefer to not fix it this until we have other complains.
Feel free to backport this commit if needed.
Steps to reproduce:
- Go to Sales
- Create a new quotation
- Add a product with a very long description that takes at least a whole page.
- Add anoter product.
- Print it as a .pdf.
=> Product descriptions overlaps on page 3.
opw-3411031
closesodoo/odoo#145458
X-original-commit: a809e63eae5224696965781e9ab7e2e195555292
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Since the milk redesign, and the move of the "Add to my dashboard"
action from the search view to the CogMenu (next to breadcrumbs),
the action was available in all views, especially in form views,
which isn't what we want. Adding a form view to the dashboard
results in an empty form view (in creation) being displayed in the
dashboard.
Before milk, the form view naturally didn't allow to add to
dashboard as it has no search view.
This commit checks the view type to determine if the action must
be available or not.
Task 3552870
closesodoo/odoo#145534
X-original-commit: d01c75938948bd0e365d7ca1e4f518ce5b563f5c
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, customers were facing issues when syncing events from Outlook that came from external users when the event organizers were from 'Portal' or 'Public' groups with limited access to calendar events, triggering ACL errors regarding absence of event permissions for creating events. This error should not happen because the events are being synced by a user with permission to create them in Odoo. Additionaly, when inserting events, we were not trying to make the requests with the organizer user's token but with the current user's token instead. This could lead to errors when the current user is not synced and the request could be lost due to the lack of token.
After this commit, the events with external organizers (with limited access rights in Odoo) coming from Outlook synchronization are now created by the attendee in Odoo (synced user) not the external organizer. Additionaly, when inserting, patching and deleting events, first we check if the organizer is synced to make the request with its token, otherwise we use the current user's token to make the request.
closesodoo/odoo#145492
Task-id: 3627270
X-original-commit: 1df1d44
Signed-off-by: Gabriel de Paula Felix (gdpf) <gdpf@odoo.com>
See comment in diff for rationale about the `isLoaded` change.
Also highlighting message before jumping to present can conflict: some
programatic scroll changes are prevented or delayed while there is a
highlight, jumping to present should clear that.
All "previous state" variables need to be reset when re-using the thread
component after making a change that led to reloading the message list
(such as a long jump). They are used to compare value before/after some
changes, but when jumping, the state should be considered clean.
`isJumpingRecent` is obsolete heuristics that has been replaced by
better controlling scroll and visibility check.
Extra `await` in `loadAround` makes no sense.
It's the best guess to fix the following runbot issues. The error
doesn't happen frequently enough to be a guaranteed fix.
runbot-40592
runbot-48557
closesodoo/odoo#145419
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Summary
-------
Currently, duplicating a journal results in the new journal's mail alias
name overwriting the original's.
Steps to reproduce
------------------
* install `account_accountant`
* duplicate the "Vendor Bills" journal
=> you should see that the alias name of the new journal overwrites the
alias of the original journal.
Cause
-----
When duplicating a journal, the new journal inherits the alias of the
original. Because of this, a specific code segment intended to generate
missing aliases for new sale/purchase journals, inadvertently modifies
the name of the alias.
opw-3597349
closesodoo/odoo#143771
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If the snippet names are too long (e.g., after being translated), they
overflow and cause a horizontal scrollbar to appear on the snippet menu.
Steps to reproduce the issue:
- Set 'Finnish' as the language for the connected user in Odoo.
- Go to Website edit mode.
- Bug: Some snippet names are too long and overlfow their parent
elements.
This commit fixes this issue by adding the CSS rule 'ellipsis' to
snippet names.
task-3584011
closesodoo/odoo#145500
X-original-commit: 0ab64009ce81dc02f87c80f7de409a5dcff214c1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Since commit [1], at the creation of a bill, if a part of the quantity
to invoice is already out, we compute the value to impact the stock
valuation accounts. The issue was in this case the included price taxes
was applied 2 times. Once as we make the computation with
`price_subtotal` field, the second time because commit [1] forgets to
remove the extra `compute_all`.
[1]: 8444f5aae8b83c113e1cd2864ec11e92d836780a
closesodoo/odoo#145493
X-original-commit: 55be6781e514c34c1d2b7b9911aebe9f17bd3d12
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Currently, when using the website, you can input your information either during
the first checkout (website_sale) or in the profile (portal). The problem was
that the translation of the VAT was confusing for the user, as they may not
understand what "VAT" is.
We also added a field in the two forms, so it needed translation too.
This commit will change the translation in l10n_br_website_sale, website_sale
and portal to make it more clear for the user, helping them know what to input.
closesodoo/odoo#142165
Task: 3576516
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
At the moment, there are two possible flows to modify the personal information
of the user. Either during the first checkout (website_sale) or by modifying
the information on the account present on the website (portal).
For both of these flows, when the client and the website are Brazilian, the
input for the VAT must be required.
This commit will override the corresponding function to make the input required
under these conditions.
Also, we have added a new field on the two forms. Just before the vat input, we
can now find the l10n_latam_identification_type_id.
Task: 3576516
Part-of: odoo/odoo#142165
Creating a stock move chain through `action_confirm()` + `run_*()`
sometimes needs to carry data from move to move to specify the future
documents to be created. For instance the supplier to choose to create
purchase order or stock route to filter stock rule to be triggered . The
field `route_ids` on `stock.move` has exactly this meaning. Forcing the
route to have the same company than the stock move may be too strict for
some intercompany flows inside which the route to choose are just saved
for future stock move creation.
Task 3527727
closesodoo/odoo#145384
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit adds tests for the computation of the date of
the replenishment wizard.
Taken into account for the date computation:
- vendor lead time
- days to purchase
- security days for purchase
- security days for mrp
- rule lead time
task-3527727
Part-of: odoo/odoo#145384
The previous delay showed in the replenishement wizard did not take
the following delays into account:
- vendor lead time
- days to purchase
- security days for purchase
- security days for mrp
- rule lead time
- manufacturing lead time (BoM)
- days to prepare manufacturing order (BoM)
Made the vendor delay visible by default in the vendor search view
Also changed function orders in stock/product_replenish as it
did not follow the guidelines
task-3527727
Part-of: odoo/odoo#145384
The show vendor button creates an orderpoint.
This commit removes it as it should not create one.
The wizard will be adapted in a future master pr.
task-3527727
Part-of: odoo/odoo#145384
In 16.4, this commit https://github.com/odoo/odoo/commit/c3b7a87462cd41654d0e2bd3beb2f0e065ddfb75
created a notification when replenishing a product.
However, it achieved it by modifying a stock.order_point which was
not the ideal solution as we don't want the order_point to change.
In this commit, we will revert to the previous behaviour,
but we'll keep the notification by delegating it to the wizard itself.
The way the record created were retreived (to display the notification)
was thanks to the orderpoint.
As we do not have access to orderpoints now, we are just retreive
the first record (of a certain type) created just after the start
of the function.
This method has a big problem : concurrencies.
If anyone creates a record on ``manufacturing.order``,
``purchase.order.line`` or ``stock.move`` between the start of
our timer and the creation of our record, a wrong record will be
selected.
task-3527727
Part-of: odoo/odoo#145384
If we begin to run the test at 23h59m59s, the move date could be put
at a day and the freeze for the cron on the following day, and so,
make the test fail.
Let's just define the day explicitely.
Linked to runbot error 36224
closesodoo/odoo#145444
X-original-commit: 9206e16c84038f08606c045dcf138f72ef78aa4a
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Similar to this: https://github.com/odoo/odoo/pull/124425
Issue:
======
The shiping and billing address are the same when choosing pick up
locations which is not true.
Steps to reproduce the error:
=============================
- install website_sale and delivery_sendcloud module;
- create a shipping method (use Sendcloud provider);
- configure the integration with
"Mondial Relay Point Relais International 1-2kg";
- configure option with shipping rule and use location;
- on website create a new quotation with the pubic user;
- process the checkout;
(Check in backend the shipping weight)
- fill City and Zip Code fields with correct value
(example: Paris | 75011)
(- configure the company's country)
Origin of the issue:
====================
Updating the payment method will trigger a cart update which will reset
the access_point_address.
Solution:
=========
Using the context variable `no_reset_access_point_address` introduced
in the commit mentioned above.
opw-3615829
opw-3596705
closesodoo/odoo#145425
X-original-commit: 7d43176d35faad025dd98c52cebb07a8f16e2270
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
This commit converts the industry name in the configurator to lowercase
it in order to optimize the IAP placeholder cache.
task-3626875
closesodoo/odoo#145231
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Claire Bretton (clbr)