Fixes 2 bugs:
- Users were confused when creating a picking type with a duplicated
prefix name. Because of it, they were unable to distinguish between
the 2 auto-generated ir_sequences since they default to the same name
https://github.com/odoo/odoo/blob/fe29860b22563bcae58a2e118b2a5ea79637589e/addons/stock/models/stock_picking.py#L102-L115
Therefore we add a warning when they try to reuse an existing prefix
(within a company), but not reuse the same seq id. We do not want to
completely block duplicated prefixes in case the user really wants it
and/or it is duplicated programmatically by accident (e.g. doing
uninstall + reinstall of a module).
- When users duplicate an existing picking type, the auto-generated
ir_sequence could result in duplicated picking names, which can result
in a block due to the constraint:
https://github.com/odoo/odoo/blob/fe29860b22563bcae58a2e118b2a5ea79637589e/addons/stock/models/stock_picking.py#L440C1-L441
A previous solution involved linking the existing sequence_id to the
duplicated picking type, but this was NOT a good solution because it
could lead to an inconsistency between the prefix used by the picking
types due to one being changed and the other not, i.e.
https://github.com/odoo/odoo/blob/fe29860b22563bcae58a2e118b2a5ea79637589e/addons/stock/models/stock_picking.py#L123-L136
would be applied, but the user may not see that it auto-changes it for
the other picking type
Note that there are some other bugs that still exist related to these
bugs, but there's only so much time in the world to fix this mechanism,
so posterity (i.e. if someone else wants to fix them) they are:
- Previous fix: odoo/odoo#138471 ensures that the company of a picking
type correctly matches its sequence_id's company. Unfortunately it
does not take into account if the prefix has been changed (i.e. the
picking type prefix WON'T match its sequence's prefix). This mismatch
can also occur if the name of the warehouse is changed.
- Previous fix: odoo/odoo#139277 ensures that the sequence names are
unique so that they are more easily noticed/fixed, but the prefix is
left unchanged. Therefore there can still be issues with duplicate
prefixes leading to the sql_constraints being triggered for pickings
that use both the existing and the new sequence value.
Part-of: odoo/odoo#146362
This reverts commit 52219871e8d8357044763375f6f5318622e9894e.
Orig PR for ref: odoo/odoo#122838
Fix was ok for the specific bug it fixes, but then it adds the
additional bug of 2 picking types which can have different prefixes
but the same sequence_id. This on its own is not a big deal, except that
when a prefix is changed for one of the picking types, then the sequence
is updated for both picking types and the prefix of the not changed
picking type will not match anymore. For users not in debug mode, this
would be quite confusing since they cannot see that it is the same
sequence in both picking types.
A better solution is to default the sequences + their prefixes to be
different.
Part-of: odoo/odoo#146362
This reverts commit 9034602a028fb22fbd139cf41a2f5c71d9d8d032. Orig PR
for reference/auto-linking tracking: odoo/odoo#129394
Commit was intended to prevent having picking type sequences created
with the same code, but set up too strict a condition. This caused
issues with the following use cases:
- upgrades: see odoo/odoo#139277
- uninstalling and reinstalling modules that auto-create picking types
see:
- POS = odoo/odoo#138189
- stock = odoo/odoo#134032
- mrp = odoo/odoo#136755
- repair = odoo/odoo#139841 saas-16.4 onwards
For uninstall + reinstall cases, we should indeed do something better to
clean up these sequences so they do not appear to be duplicates of the
re-added operation types (i.e. unlinking them is not a good solution,
especially since the picking type still exists afterwards). That will
be part of a separate task though and low priority since we already warn
users that uninstalling and reinstalling modules can result in
unexpected behavior.
Since the original issue was only that there was no way to distinguish
between the sequences, a "_copy" will be added to duplicated picking
type records + we will add a warning if users tries to use an already
used sequence prefix (since the name is based off of this) but we won't
block them from doing it.
Also, we move the test that was added after the commit that is being
reverted to a better location.
Part-of: odoo/odoo#146362
Anlytic distribution models did not apply to bank recon entries. The corresponding enterprise PR activates the feature, however due to dependencies on non-precomputed fields, the attribute is removed
OPW-3558060
closesodoo/odoo#146235
X-original-commit: b9047febf3c4d67ce409f9f1dba8a9cc7c7165fe
Related: odoo/enterprise#52742
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Since [commit 1], the columns count in the options is updated while
dragging the width handle of a column. That behavior relies on
asynchronous code which is not awaited.
This commit corrects it to be in line with the behavior of all other
options: the count is updated after releasing the drag. It also freezes
the mutex during the resize.
[commit 1]: https://github.com/odoo/odoo/commit/710d000f1872fd99b41d52ec3d6923756bba7cba
task-3576046
closesodoo/odoo#141002
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when editing a snippet that is outdated, an alert
block is displayed above the options, warning about that. However, this
alert does not really catch the attention and it does not prevent the
user to still use the options.
This commit improves this alert block by making it cover the whole
outdated options section, to make it more visible. Moreover, it now
contains two buttons:
- one to replace the outdated snippet by its new version, and
- one to still access the options, despite the fact that they may not
work anymore.
task-3203590
closesodoo/odoo#117560
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The `test_01_multi_domain_assets_generation` was introduced in PR [1].
But afterward, the commit [2] introduced a unique constraint on the
`domain` field. With this additional constraint, this test broke when
run with multiple existing websites as it assigns the same domain for
each of them.
This commit made the dummy domain assigned in this test non-unique,
which doesn't alter the original meaning of the test but, allows to run
it with multiple existing websites.
[1]: https://github.com/odoo/odoo/pull/118526
[2]: https://github.com/odoo/odoo/commit/507db4e179514d171ec82e8ea0cbaf2323a6c30d
runbot-20848
closesodoo/odoo#146666
X-original-commit: 0c522e42a82ec596e69611c556c4fc0d50e6e978
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
4424 VAT to be recovered should be liability_current.
4426 VAT deductible should be asset_current.
4427 VAT collected should be liability_current.
closesodoo/odoo#146572
Taskid: 3634044
X-original-commit: 2581dda5217a6434cee529ed2ef144eb71fca467
Related: odoo/enterprise#52907
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
Problem
---------
In the accounting tour, during the invoice creating step, the message
asking to confirm the invoice was irrelevant.
Landed in 17.0 with this commit:cc6f85af2aac31816b51a0b39c9b119049f9954f
Objective
---------
Change the message into "Once your invoice is ready, confirm it."
Solution
---------
Change the relevant message in the tour JS file.
task-3619638
closesodoo/odoo#144963
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Before this commit, columns in list views could be manually resized
only if there were records in the table. For the ungrouped case it
makes sense, as the table is empty anyway. However, for the grouped
case (either with empty groups, or with all groups being folded),
the list contains no records, but resizing could make sense as
there could be aggregate values displayed on group headers.
Technically speaking, there's no reason to restrict the resize
feature if the table is empty. Functionally wise, a user could get
confused if the feature is sometimes available, and sometimes not.
For that reason, this commit simply removes the isEmpty condition,
meaning that resizing columns is now always available, even if the
table is empty.
Task 3621490
closesodoo/odoo#146622
X-original-commit: 8fbdbb59eb3f37fad1fb75f4ff363f7fa17e6d27
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
On device which are primarily recognized as "touch", when using a
mouse-like pointer, the tooltip can't be opened both on "touch" and on
"hover" (withe the mouse).
This commit fixes it by removing the escaping that prevented the mouse
events' listeners from being registered on touch-enabled devices.
Steps to reproduce:
1. Using Chrome, open the developer tools and click on "Toggle device
toolbar"
2. Install Contacts
3. Go to Contacts and open the form view of any contact
4. Now click again on "Toggle device toolbar" to disable it but do not
reload the page: touch device capabilities will be loaded but you
will be able to use a mouse
5. Click on the question mark next to "Tax ID", nothing happens
opw-3493571
closesodoo/odoo#146621
X-original-commit: 5cbfa9751d6186ac6515a4341676706a807642ec
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
After the previous fix introducing a deepcopy, the pregenerate of the
assets became slower because of the many call to get_manifest (in loop,
recursively)
Since the manifest is immutable here and won't go outside of the call,
we can use the lower level version.
closesodoo/odoo#146602
X-original-commit: acb671f4d1b9c53c9e7d91414e847f26e8026ca3
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Summary
-------
Currently, when you send an invoice, every recipient receives the link
including the access token. Only the invoice's customer and manually
added recipients should receive the token.
Steps to reproduce
------------------
* Create and validate an invoice
* Add a follower `F `to the invoice
* Click on the Send & Print button, then add a recipient `R` who is not
the customer associated with the invoice
* Proceed to send the invoice.
* Access the emails that were sent
* Using an incognito or private browsing window, open the `View Invoice`
link for each of the 3 recipients.
You should see that all the links give access to the invoice.
What should happen is that only partner `R` and the invoice's customer
should haveaccess to the invoice.
`F` should be asked to login.
Cause
-----
Issue was introduced by 95c585f
Fix
---
Add a new notification group for partners that were manually added as
recipients, and give that group access to the invoice.
opw-3385302
closesodoo/odoo#146575
X-original-commit: 755814ea170adbade23692767fcb17b5422863e7
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
This traceback arises when the user tries to click on 'Lot/ serial Number' in
Create Move Line
To reproduce this issue:
1. Install 'stock'
2. Create a new record in Lot and Serial Number from 'products/Lot and Serial
Numbers'
3. Now go to 'operations/Transfers/Deliveries'
4. Create a new record and select the above-created 'Lot and serials' product
5. Save the record and click 'Mark as Todo'
6. Click on the 'Detailed Operations' button and add a line
7. Set the quantity
8. Again add a line click on new then select Lot/serial Number
ValueError:
Expected singleton: stock.quant(5, 24)
when the user tries to click on 'Lot/serial Number' in Create Move Line
a value error occurs because getting many values excepted single value
Which leads to the traceback from here
https://github.com/odoo/odoo/blob/230b680bf92583c9f5e4a3739be1d8602df44331/addons/stock/models/stock_quant.py#L905-L929
After applying this commit will resolve the issue of getting a sum of quantity
mapped with the quant
sentry-4715604118
closesodoo/odoo#146560
X-original-commit: c7612dfc4349bc9b21a48ca5192523f180f9b5e8
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This attribute was not correctly updated with the big attribute revamp.
This commit fixes that.
closesodoo/odoo#146523
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Steps to reproduce:
- open kanban view of department from employee module.
- click on 'Allocation Requests' and 'Time Off Requests'.
Issue:
- When viewing the department's allocation and time-off requests in the employee
module, all department data is displayed, regardless of the department
selection.
Solution:
- The issue is resolved by correcting the domain, ensuring that only data
related to the selected department is displayed. This adjustment results in
accurate department-specific request information.
Task ID-3541358
closesodoo/odoo#145575
X-original-commit: 6bef791f4336725e8ab02b8531bd3507cc9624a5
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Steps to reproduce:
-------------------
- in a second company, giving leave to an employee;
- go to reporting in Time Off app;
- remove all filters.
Issue:
------
We see leaves of the other company's employees.
Cause:
------
The global rule which allows a domain to be added to manage
the multi-company case on the `hr.leave` model takes account
the company of the type of leave.
Solution:
---------
As types of leave can be shared between different companies,
it is also necessary to filter on the employee's company.
In fact, even a time off administrator is not supposed to see
the holidays of employees in companies that are not activated for him.
opw-3594737
closesodoo/odoo#145001
X-original-commit: d59e645b2edf167cb7f108fd7db563799b3db2f1
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Previously, draft quotations were never marked as expired. However, draft quotations can be viewed in the portal if you have the link. In order to prevent customers from paying for draft quotations, we now mark draft quotations as expired when applicable.
task-3577657
closesodoo/odoo#144581
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The commit [1] of this PR [2] has been merged requesting some changes to
be made later, which are fixes to the button that can now be dropped
onto the page from the snippet menu.
This commit makes the following changes requested:
- Before this commit, when we duplicated a button (by clicking on the
"duplicate" button), the style of the new button was generated again in
Javascript in the "_adaptButtons" function even though it is not
necessary since we duplicate the HTML of the copied button. That is why
this commit adds the "adaptAppearance" parameter for the "_adaptButtons"
function.
- Prior to this commit, when a button was dropped between two buttons,
the style of the next button was copied as a priority. After this commit
, the style of the previous button is now copied as a priority.
[1]: https://github.com/odoo/odoo/commit/507b80a12574ce19bcb925d88868fb377b1c4b06
[2]: https://github.com/odoo/odoo/pull/126717
task-3555413
closesodoo/odoo#139621
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
This commit fixes 3 issues with the domain in field tooltips, in
debug mode.
1) it only displayed the domain defined on the field in the model,
not the domain set in attrs in the view, if any.
2) when the domain was the empty array, `domain: ` was displayed.
3) unset values should not appear in the tooltip (invisible,
column_invisible, required, readonly).
opw 3455119
closesodoo/odoo#146563
X-original-commit: 8c4ff1fac9eb003c23770bf74f9d7ffe062f6ce7
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit:
Activities made on the archived record are not shown in the activity
system-tray menu.
After this commit:
Activities made on the archived record are shown in the system-tray
activity menu.
task-3458597
closesodoo/odoo#146462
X-original-commit: d6d91b4f86d3d0ef954160a9de6e42a1bc4e184f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
REMINDER: old taxes = {7.7%, 3.7%, 2.5%}; new taxes = {8.1%, 3.8%, 2.6%}
1. We created 2024 taxes in advance and made them inactive by default
to avoid confusion for our users, while making them available for those
who needed them. Now that we are about to enter 2024 its time to active
new taxes by default and deactivate outdated ones.
We are keeping outdated taxes a bit more for clients that are not closing
their accounting at the end of the year and might need them for upcoming
months.
2. Remove the activation of new taxes that was made in the module migration
since now those taxes are already active.
closesodoo/odoo#146495
Task-id: 3184792
X-original-commit: 69868b3a1e327346138835ee4c91d86a5229f9c4
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Change your language and open any dashboard.
The table titles (e.g. "Top countries" of the Leads dashboard) are not
translated.
It was lost in commit odoo/o-spreadsheet@9616681
With this commit not all link labels are translated. Only odoo links.
I don't think other (regular) links should be translated.
closesodoo/odoo#146574
X-original-commit: a2e406db138d51e710caf61a2809cfa991ea6cb3
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
As the vendor bill names are those from the vendors
and the customer invoices are per document type,
it does not make a lot of sense to care about the gaps
in the traditional sense for LATAM journals.
closesodoo/odoo#145173
Signed-off-by: William André (wan) <wan@odoo.com>
This is because the `env.registry` may not be the latest registry in the
Registries pool, which happens when new modules are installed by a request and
fail. In the `setup_model` the `_m2m` is set to the old registry, but models
will try to read the `_m2m` from the latest registry and raise 'Registry' object
has no attribute '_m2m' error
This commit fix the issue by resetting the env when necessary
closesodoo/odoo#146544
X-original-commit: a433f3175a5105d9028dd9937d5461ae2d5d11fe
Signed-off-by: Raphael Collet <rco@odoo.com>
`field_computed` is decorated with `lazy_property` and will be reset by
`setup_models` If a request comes, read `field_compute` when `setup_models`
just clears some fields. The `field_compute` will be cached with fewer fields
and cause KeyError for the registry in the future.
This commit re-clear lazy_property for registry after fields are modified
X-original-commit: 04e35d7bf3ca98dc722795c75033747697d70d30
Part-of: odoo/odoo#146544
If `setup_models` is called concurrently,
the first one just delete the `registry._m2m`.
then the latter one tries to access `registry._m2m`.
An error 'Registry' object has no attribute '_m2m' will be raised
This commit add a lock to the `setup_model` to fix the problem
X-original-commit: 9ae78193f5c9ae4dcfa28c4ea4be1a7f98e42136
Part-of: odoo/odoo#146544
Make correspondent a compute to benefit from cache.
This reduces the time on populate medium from around 600ms to 200ms.
closesodoo/odoo#146109
Related: odoo/enterprise#52703
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
On my machine, this reduces the time of the qunit suite from around
115s-120s to 100s-105s. This reduces the time of init messaging with
populate medium from around 3s to 1s.
Avoid having to split local id to find record. This is a slow process
that is better avoided.
Make _fields a Map rather than an object.
Name anonymous methods to get better trace and profiling.
Move field update to separate methods. Start making the update method
return whether the value has changed, to go into the direction of
removing reactive from internal code (especially for on change).
Use markRaw or toRaw on technical values that don't need to be observed.
Start better naming variables, especially having a specific name when
the value is possibly a proxy, and keeping the simple name for when it's
definitely not.
Part-of: odoo/odoo#146109
Snailmail letters failed to fail in newer version of Odoo.
The cause is a report attachment was supplied at the creation
of the letter, preventing the snailmail module to generate the report with the required CSS.
Said CSS was also rewritten to be clearer and to fix the follow up
reports.
closesodoo/odoo#146525
X-original-commit: 87c90abaec701cfa0e29391b52780e4c2b9e4694
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Signed-off-by: Solan Delvenne (sode) <sode@odoo.com>
Steps to reproduce [1]:
- Go to website (blog post page) > Change the layout of the cover
(Customize > 'Regular' Cover).
- Click on the cover (in edit mode) > You can type anything inside and
use the text tools (E.g. if you add an image from the toolbar, it will
be added on all blog posts).
Steps to reproduce [2]:
- Go to website (`/calendar` page) > Unpublish an appointment page.
- Go back to the `/calendar` page > Switch to edit mode > You still can
edit the "unpublished" tag on the items cover (add text, images,...
using text tools).
The editor uses some methods (`getContentEditableAreas()`,
`getReadOnlyAreas()`,...) to check if an area should be marked as
editable on load, there is already a cover selector used to define a
record cover as an editable zone, but this selector is targeting the
whole element, leading to the behaviour described in [1] and [2]. We
actually just need to set the savable content (usually the record `name`
and `subtitle` fields) as editable and not the whole element.
The goal of this commit is to fix this behaviour by removing the cover
along with its descendants from the initial editable zones (especially
to prevent the scenario in [2], see: $editableSavableZones) and only
setting the savable fields as editable areas.
opw-3561659
closesodoo/odoo#146407
X-original-commit: 333e437d6acb227f092f1d152fe68d49076cff94
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
This PR improves phone_validation tooling
* fix issue when adding or removing a 'phone.blacklist' record
with a void number;
* improve parsing, try to be defensive with input number to recover
from some commonly found issues with '+' or '00' prefixes;
* add tooling to extract region information from a number.
See sub commits for more details.
Task-3608129 (Whatsapp: Moultifix !)
closesodoo/odoo#146398
Forward-port-of: odoo/odoo#145554
Related: odoo/enterprise#52840
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
After some testing notably with WhatsApp module, it appears usage of phone
numbers could be a bit more defensive to try to accomodate with data users
entered. Notably when failing to recognize a number, we can distinguish
error and try to reformat it based on two commonly spotted errors
* missing "+" in front of a E164-like number (e.g. '32455001122');
* usage of "00" in countries where it is not really standard to use it
instead of a "+" (e.g. '0032455001122');
Those find of numbers generate a 'TOO_LONG' error from phonenumbers library.
In that case we try to reformat it just to see if we can do better with it.
Task-3608129 (Whatsapp: Moultifix !)
X-original-commit: odoo/odoo@85c1306156
Part-of: odoo/odoo#146398
In this commit we add a new tool function in 'phone_validation' tooling
module. This tool 'phone_get_region_data_for_number' returns
* 'code': the region code from phonenumbers library, which is like 'BE' or
'GB' and (should) be the uppercase version of odoo country code;
* 'phone_code': the 'country_code' from phonenumbers library parsed object
which is actually the phone code of the country (might not be unique
e.g. 1 for US and CA);
* 'national_number': the 'national_number' from phonenumbers library parsed
object which is the number without the 'phone_code' prefix (e.g. for a
belgian number +32485001122 it is 485001122).
This will be used in whatsapp (enterprise) to ease finding country (and
partners) based on an input number.
Task-3608129 (Whatsapp: Moultifix !)
X-original-commit: odoo/odoo@646aa8f369
Part-of: odoo/odoo#146398
steps to reproduce:
- configure your POS with anglosaxon accounting and "Update quantities in
stock" at session closing and enable "Use QR code on ticket"
- open the POS, sell a storable product and close the session
- scan the QR code on the ticket to create an invoice
- check the pickings on the session form view
before this commit:
- 2 pickings are created, one at session closing and one from the invoice
after this commit:
- if the session is closed, do not create a new picking
opw-3592418
closesodoo/odoo#146077
X-original-commit: 486fa23e586c1dae490ffe0a91138d6f6dc6d824
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Nicolas Danhier (nda) <nda@odoo.com>
Since PR odoo/odoo/pull/124068, the browser history back no longer works
correctly when navigating from the home menu to applications. It requires
two history backs instead of one.
Why:
Two pushStates are performed on the router, the first to add the menu_id
and the second to apply the action associated with the menu.
These two pushStates are not in the same setTimeout, which causes two
changes to the url. So two entries in the browser history .
Solution:
We perform the two pushStates in the same setTimeout. This causes
only one url modification and therefore one entry in the browser history.
How to reproduce:
- Go to the home menu
- Click on the app A
- Return to the home menu using the toggle menu
- Click on the app B
- Perform a history back
- The home menu is displayed
- Perform a history back
Before this commit:
The home menu is still displayed
After this commit:
The app A is displayed.
closesodoo/odoo#146143
Enterprise: odoo/enterprise/52683
X-original-commit: 8e3152fbfbb4a836ab9663d009fbcacbe3554ae8
Related: odoo/enterprise#52697
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Steps to reproduce issue:
1. Select non english language
2. Open a POS session
3. Select a product
4. Got to payment UI
5. "Customer" is not translated
Explanation:
Concerned element uses a `t-out` with an `or` operator, translation can not apply to it.
Suggested fix:
Use of distinct tags with `t-if` and `t-else` instead, to make translation work.
opw-3636234
closesodoo/odoo#146292
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Example use case:
- Create a product A.
- Update the available quantity of the product.
- Create a basic user without Inventory permissions.
- Go to the product list (product.product or product.template) and get
an error when access to stock.move records to set the qty_available
field (for example).
TT45220
closesodoo/odoo#142472
X-original-commit: e41fbda20582683361a5124db418f152bf80a3ed
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit, attempting to do
`self.env['calendar.event'].write({'partner_ids': [0, 1, 2]})`
would give a traceback as the method that updates attendees
only supports parsing commands, not ids.
This is a problem as that method is called from 'write' and other methods
with the assumption that partner_ids can only contain commands.
This will not be the case when using a gantt view and grouping
by partner_ids for example, and cannot be worked around.
task-3452277
closesodoo/odoo#146446
X-original-commit: 88e191132bf40a4e3090077f1fd0077e649eb7fb
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>
Since [this other commit], we add ZWS characters to the edges of links.
Unfortunately, this breaks the label option of the link tools that has
been introduced in [this commit].
Steps to reproduce the issue:
- Go to website
- Edit a page
- Click on the contact us button in the header
- Using the label option of the link tools, delete the final character
=> Nothing happens.
The final character is not deleted as expected.
[this other commit]: https://github.com/odoo/odoo/commit/ab40f484d55e151e175ccf9d6b3ea3bf34c56b35
[this commit]: https://github.com/odoo/odoo/commit/75166dbcd4962f30624fe19829757acbf8e76022
Related to runbot-44779
closesodoo/odoo#146361
X-original-commit: 593dc52cd5c3362c446395a52a7782f74f445e34
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
The issue:
having 2 invoices/quotations/purchase orders with different customer, each customer has a different language, the 'Unaxed amount' string will get translated into the first language of the first invoice partner.
The fix:
recompute the total when the lang context change
opw-3569173
closesodoo/odoo#146311
X-original-commit: d48a09738bdde4050bc75f82480ff47ddeb8b553
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit and since PR [1], the default "checked" value set on
checkboxes field on the form snippet were lost once the page is saved.
This is because [1] changed the rendering engine of qweb templates from
our own qweb js rendering code to owl templates rendering.
By doing so, `t-att-checked="'checked'"` would toggle the "internal"
checkbox checked value but would not add the checked attribute on the
element.
It's a deliberate choice made in owl. As the checked attributed does not
mean the same as the internal checked value, it makes sense.
Indeed, the checked attribute is about the default value of the checkbox
while the checked internal value is about the current checked state of
the checkbox.
In React, for instance, the same behavior can be seen. And if one wants
to really set the checked attribute, they got to go with
`defaultChecked`.
Same apply with `value`.
Maybe owl will implement the same `defaultXXX` behavior in the future as
it's something that was already discussed on their side.
Step to reproduce:
- Drag & drop a form in the website builder
- Add a new custom field and select "Multiple Checkboxes" type
- Set one of the checkbox checked by default
- It is visually checked, but the attribute is not set
- Save the page
-> The checkbox is back to unset state since the attribute was not set
[1]: https://github.com/odoo/odoo/pull/130467
opw-3607795
closesodoo/odoo#146328
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit add a new delay_type that will add to the date the nb_days then go
the end of the month and finally add a new field called days_next_month.
This field is a Char because we want the field to be of size 2. Also, we added a
constraint that this field must be numeric and between 0 and 31.
Ex of use with Invoice date the 25/11/2023, if we have a payment term with 90
for the nb_days and 10 for the days_next_month:
+90 days = 23/02/2024
End of month = 29/02/2024
+10 days = 10/03/2024
(Also, there is a special case handling when the day of the month is 29, 30 or
31 to avoid exceeding the next month's end. For instance, with a payment term of
30 days end of month and using the 31st of a month, prevent calculation from
moving beyond the end of the next month (e.g., early March instead of end
February)
closesodoo/odoo#143758
Task: 3609320
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Tiffany Chang (tic)