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>
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>
Aditya Dubey