When defining a selection field as field dependency, one must
specify the options of that selection field (or at least an empty
list if options don't matter). Because if that field isn't in the
arch (which is the point of defining field dependencies), and the
model has to process a value for that field, it will crash in
`parseServerValue` (selection case).
There's no scenario to reproduce this in standard, but one can
build one: edit the project task form view arch, in the child_ids
x2many, set mode="tree,kanban", but do not add the kanban nor the
form view inline (s.t. default views are used). Then open the view
in mobile and click to add a record in the relation.
closesodoo/odoo#146435
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Issue:
======
The phone field is required in a billing and shipping address at the
same time but no warning appears.
Steps to reproduce the issue:
=============================
- Install ecommerce
- Log in with mitchel admin and add anything to cart then go to checkout
- Update the saved address which is for shipping and billing and remove
the phone
- Save the adress , the page will reload and no error appears.
- Add the phone and save it will works.
Origin of the issue:
====================
`use_same` wasn't passed in `kw` when updating the address.
Solution:
=========
Force `use_same` when validating the values when we have the address is
the same for shipping and billing.
opw-3617720
closesodoo/odoo#146266
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Isssue:
=======
When using a language with twelve-hour format (arabic) and open
datetime_picker it will raise an error.
Steps to reproduce the issue:
=============================
- Change lang to arabic
- Create a task in a project an try to modify the deadline
Origin of the issue:
====================
When we have `props.focusDateIndex != 0` and `props.range = False` we
will have only that index in the array `this.state.timeValues` ,
iterating over the array in `handle12HourSystem` function will result in
error because it starts iterating from index 0 which is undefined.
Solution:
========
Skip the undefined indexed;
opw-3629657
closesodoo/odoo#145424
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
If ecommerce was installed, website privacy setting "Customer Account"
was hidden and replaced with another setting. Now both of these settings
are shown.
task-3321443
closesodoo/odoo#146746
X-original-commit: 8529bd040ef759fdcbc4597408e3d82650be8424
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: anko-odoo <anko@odoo.com>
Step to reproduce:
- Create a mega menu
- Enter edit mode and select it
- You can duplicate the top level block (but not remove it)
- If you duplicate it, you end up with a second top level block that you
can't delete ever, even by deleting inner elements one by one.
Technical details:
1. The remove button of the mega menu is already hidden thanks to commit
[1] which used the `forceNoDeleteButton` editor option introduced
with commit [2].
2. The table of content snippet also need to hide both the delete and
clone button. It was done in an "non-ideal" way with commit [3].
3. The delete button removal for table of content snippet was actually
improved to use the `forceNoDeleteButton` option of commit [2].
4. It's also commit [1] which prevent the deletion of the top level
block when deleting inner elements one by one: when the last one is
deleted, it regenerates the whole block.
This commit thus simply makes it so `forceNoDeleteButton` also hides the
clone button.
A first solution was made by introducing a new `forceNoCloneButton`
option, but there is good chances that you always want to either hide
both or show both, so merging those options for now is the simplest
solution.
It also takes the opportunity to remove the (now) useless code in the
table of content snippet.
[1]: https://github.com/odoo/odoo/commit/97810a9c40396bb27cb5779937734849d185cf1f
[2]: https://github.com/odoo/odoo/commit/7ef484377a493ebe558242480d0da6b542d6c247
[3]: https://github.com/odoo/odoo/commit/9fb2dad97cfbd412bee3cb5d1358a9835e721f60#diff-ea32a091d6b1a47aeea680fa39bbc9111260cbdaf07e9f388a9d04741806ea8fR128-R129
opw-3604033
opw-3627319
closesodoo/odoo#146745
X-original-commit: 44b006778df913b847c58b3e405d2a177fcb1a7c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, the CSS properties defined by the
`o_link_in_selection` class could be applied to a link outside the
editable. In particular, the link preview in the LinkDialog widget would
display the visual indicator of a link in selection, even though it is
not editable nor selected (this happens because the link preview
contains the classes of the original link being edited).
As the styling provided by `.o_link_in_selection` is only meant to be
applied to links inside the editable, this commit makes sure the CSS
rule is specific about that.
task-3580546
closesodoo/odoo#146679
X-original-commit: b7664dc8e8a0a7909101f45d5a58473ca64d71ca
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Signed-off-by: Rodolpho Cammarosano de Lima (rcdl) <rcdl@odoo.com>
Prior to this commit, a user was able to modify the commercial fields
of a partner in the POS. This is not wanted and not possible in the
backend. This commit adapts it to the backend behavior.
closesodoo/odoo#146475
X-original-commit: 0c55915172f06864c6f29d59d3057fbe0ff42bb5
Related: odoo/enterprise#52885
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Since [1], messages received out of focus are notified to the user via
the tab title. In order to do so, the title service is used. This
service changes the tab title according to its internal state.
When the live chat is embed on a page, the original title of the page
is not coming from the title service. When the service state changes,
the title is replaced without taking into account the original title.
This behavior is not correct.
In practice, this functionality is only used by the `web` bundle. The
error occurs because the code handling this behavior is placed in the
common bundle while it should not. This PR fixes this issue by moving
this code to the `web` bundle.
task-3644431
[1]: https://github.com/odoo/odoo/pull/145216closesodoo/odoo#146752
X-original-commit: 43b67c377b6a236cb009b21afd62d8c593ef9cd6
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
The "Remaining Days/Hours on so" field wasn't displayed on the portal
tasks view, because of an issue with two templates having the same id.
In the view file sale_timesheet_portal_templates.xml, the
portal_timesheet_table_inherit is now depreciated and its content was
moved into the project_portal_templates.xml file.
task-3595003
closesodoo/odoo#146747
X-original-commit: c2ef7a4185f82b84f036ee2825e949f6340b4d40
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Current behaviour before commit:
-When creating a link, the 'unlink' button is
not getting appeared in the toolbar.
-When removing link through 'unlink' button,
the 'unlink' button is not getting disappeared
in toolbar.
-Before this commit, _updateEditorUI method is
responsible for hiding/ showing create-link
button.
Desired behaviour after commit:
-Now, When creating a link, the 'unlink' button
gets appeared in the toolbar.
-When removing link through 'unlink' button,
the 'unlink' button gets disappeared
in toolbar.
-This commit ensures that _updateToolbar
method is responsible for hiding/ showing
of create-link and unlink button.
task-3514639
closesodoo/odoo#146680
X-original-commit: 92ca62162e85a3c617ba73eaa974d342adc3e35a
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
The new, refactored method `_compute_tax_id` caches the results of `account.fiscal.position.map_tax()` to improve performances; however, this makes it nearly impossible to customize the behavior of this method in case other elements are added to the workflow of taxes computation.
Every sale order line with the same fiscal position, company and product taxes have their taxes mapped in the same manner
This commit adds a hook to allow custom modules to specify additional custom cache keys.
closesodoo/odoo#146678
Forward-port-of: odoo/odoo#146271
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Currently it's not possible to send facturae invoices through FACe,
since we did not include administrative centers in the XML.
This commit fixes that by:
- Introducing a new partner type for Administrative Centers, with the
necessary fields
- Adding all Administrative Centers linked to a partner on the facturae
electronic invoice
Since often the three required Administrative Centers (Fiscal, Receiver
and Payer) are the same, we allow the user to specify multiple roles
on an Administrative Center.
Demo data was also added for the Administrative Centers and updated to
pass the facturae validator.
For stable versions, we use a patch module to not break things.
This should be moved to the main module in master.
task-3599447
closesodoo/odoo#146675
X-original-commit: 7c4e846f023f92f48ee465008769848075757a29
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Before this commit, pasting a URL as plain text followed by picking
"Embed Youtube Video" in the command bar failed to embed the video,
inserting the following text instead: "[object Promise]".
This happened because [1], which is the result of a forward-port, failed
to `await` the call to getYoutubeVideoElement, which is an async
function since version 15.2.
[1]: https://github.com/odoo/odoo/commit/c2f0519fec40dcf529218f39829e0a09c0f7af69
task-3611566
closesodoo/odoo#146653
X-original-commit: 4891359210e2f921dbfb6d7c870ec5cf1b60d3f5
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Steps:
- Open Time Off module
- Navigate to user's kanban view
- Without any HR app access, mouseover a leave request
- Approve/Refuse buttons appear even when user lacks necessary permissions
Issue:
- Users without any HR app access rights are still able to see "Approve" and
"Refuse" buttons from the kanban view.
Cause:
- The kanban view does not properly check for HR app permissions before
displaying the "Approve" and "Refuse" buttons.
Fix:
- Updated the kanban view logic to hide the "Approve" and "Refuse" buttons for
users who don't have the necessary HR app access.
Task-3507942
closesodoo/odoo#145352
X-original-commit: 4a30e170d4b0bea0b1178dc67c41bdfe83bbe884
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
This issue occurs when a customer passes an invalid context in the view, at that
time this error will be generated.
Steps To Produce:-
- Go to `Settings >Technical >User Interface >Views`
- Open any view
- pass invalid context like
`context="{'search_default_demo': active_id}, 'search_default_x_stage_id':[3]}"`
-error will be generated
error-SyntaxError
unmatched '}' (<unknown>, line 1)
after this commit, we can display Validation Errors to users instead of a
traceback when they make mistakes in any UI view.
sentry-4684090820
closesodoo/odoo#145193
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Steps to reproduce:
-------------------
- modify the company calendar to get an other value than 8 average hour per day;
- add this calendar to two employees (A and B);
- create a type of leave for the current company;
- create an allocation for the employee A for this type with X hours without saving;
- add the employee B;
Issue:
------
The number of hours is modified.
Cause:
------
There is an inconsistency between `_compute_number_of_hours_display`
and `_compute_from_holiday_status_id` methods.
In the `_compute_from_holiday_status_id` the number of hours is determined
according to order: employee calendar --> company calendar --> constant (8 hours)
In the `_compute_number_of_hours_display` the number of hours directly falls back on
the constant if we don't find an employee for a type of leave that is employee.
In the case of multiple employees, we will always use this constant,
whereas we use the company calendar in the other method.
Solution:
---------
Keep the company calendar if you don't have an employee before falling back on a constant.
opw-3617281
closesodoo/odoo#146730
X-original-commit: 55f24b4f07eaa4527559a2819e264b4809a6b21f
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Before this commit: there was no stat button 'publish' displayed for
payment provider 'pay in store'.
Reason: The stat button is shown when the module is installed but there
was no connected module on the 'payment_provider_onsite' record.
With this commit the module_id is added.
closesodoo/odoo#146349
X-original-commit: 4480fe7c990c498175f8e7ed75a1abf34bef9547
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Valeriya Chuprina (vchu) <vchu@odoo.com>
Steps to reproduce issue:
1. Open Contacts
2. Select a contact
3. Choose:
- Add an address
- Only if contact is individual: Select drop-down menu next to Address fields in form
4. Private Address doesn't show in the options
Explanation:
Private Address was intentionally deleted from `res.partner.type` in *v16.4* (cf. b1f7e56f79).
Suggested change:
Remove Private Address paragraph in `res.partner.type.help`, it should not exist anymore.
opw-3602922
closesodoo/odoo#146298
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Currently traceback appears if no rules are available on the product.
(Steps to reproduce: install sale and stock, but not purchase, go to the product and click "Replenish")
Index is out of range because route_ids is an empty list.
This fix will allow route_ids to be empty.
opw-3637054
closesodoo/odoo#146250
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit fixes a crash that would happen on file upload in the project
sharing portal chatter. This crash was caused by the file size check in
the uploadFiles method of the FileInput component due to the fact that
the PortalFileInput calls this method once per file instead of once for
all files. The fix therefore ensures that the file size check will be
correctly applied in the case of a single file parameter instead of a
files array.
Steps to reproduce:
- Access the portal (with the /my route)
- Go to Projects
- Open the AGR - S00064 - Sales Order project
- Open any task in the kanban view
- Send an attachment in the chatter
- Before the fix, a traceback occurs on file upload
Crash introduced by https://github.com/odoo/odoo/pull/138203/commits/82b4395b2f12e1c86d2bd5c4acd47c321be071d8
opw-3628996
closesodoo/odoo#146214
X-original-commit: 8e2aef9ab607b06eb4667859204cfd7186b3f060
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Current behaviour:
Wrong format used when importing dates
Steps to reproduce:
1. Change your language to German
2. Go to Sales > Orders
3. Export to XLSX
4. Change to dates to german format (ie: 10.09.2023)
5. Favorites > import records > Upload file
6. Click on Test
7. "does not match format '%Y-%m-%d'"
Cause of the issue:
Only default formats were taken into account
because options are empty.
opw-3540715
closesodoo/odoo#146744
X-original-commit: bdc006a81f83efddd693a8d4f4ffaec92da36f4a
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
The Content-Security-Policy[^1] http header was only set on the response
generated by controllers but it was missing from the `/<module>/static/`
route.
It is not strictly necessary to set that header on the responses comming
from that routes as it is not possible to add new static files or edit
existing ones via the interface (not even as admin). Only the developers
and system administrator can access those files.
It is also worth mentionning that using the Odoo internal web server to
deliver static files is suboptimal. Outside of a dev environment, those
files will typically be delivered via a web server[^2] and sysadmins
should configure their web server to set the CSP header on static images.
[^1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
[^2]: https://www.odoo.com/documentation/master/administration/install/deploy.html#serving-static-files-and-attachmentsclosesodoo/odoo#146591
X-original-commit: 55e09d504df9bd134afb6e0b38f03457b5c71e8e
Related: odoo/documentation#6953
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Previous fixodoo/odoo#139277 was added to avoid the python constraints
that didn't allow for duplicate sequence names for picking types. This
constraint is now reverted, but it doesn't hurt to keep the renaming for
debugging purposes (i.e. in case a seq name is unexpectedly duplicated).
The code order of the original fix needs to be updated though since the
seq is created before the search so one is always found and renamed in
many cases.
closesodoo/odoo#143848closesodoo/odoo#145325closesodoo/odoo#146050closesodoo/odoo#146277closesodoo/odoo#146362
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
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>
Aaron Bohy