Description of the issue/feature this PR addresses:
When an expense was accepted and then the account move related to the expense was reset to draft/cancelled, the expense's state stayed as payed.
Current behavior before PR:
The expense's state stayed as payed.
Desired behavior after PR is merged:
Change the expense's state to refused with the reason 'Payment Cancelled'.
opw-2559225
closesodoo/odoo#77729
X-original-commit: cfe95a0e3781a23be73541cdae4393b8507cf9c1
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Steps:
- Set a supplier's 'Timezone' at a different timezone from utc.
- Set 'Send Order By: Email' and set any 'Order Time'.
Result:
E-mail will be sent at wrong time.
Explanation:
According to pytz, using tzinfo arg in the standard datetime constructor "does not work" in combination with pytz. Yet lunch_supplier.float_to_time() calls time.replace() which calls this constructor.
Solution:
Don't allow lunch_supplier.float_to_time() to modify tzinfo and use pytz.localize() in _auto_email_send() to specify the right tzinfo.
opw-2541132
closesodoo/odoo#78091
X-original-commit: 6b92fd80c4fc3471a4419369f0c6843fe18bad51
Signed-off-by: Audric Onockx <auon-odoo@users.noreply.github.com>
Signed-off-by: Kevin Baptiste <kba@odoo.com>
es_BO is not available in Transifex and some translations are different from es.
opw:2571715
closesodoo/odoo#77978
X-original-commit: 2f33bb580c5445b0fd77bd0ed8c55d5d4b298ff9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Although the ABI detection was fixed in install, it was forgotten in
post install script.
closesodoo/odoo#78097
X-original-commit: 3a4e98b6fbf6dd3e88e94421496d5c15a517ff64
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
A dependency on python pyopenssl package was added in #61853 and flew
under the radar. As this package is pure python, it should not cause any
arm.
Also, it seems that the gsfonts package is needed on Debian to print
things like barcode badges. Previously, the gsfonts package was a
dependency of python3-renderm package which is itself a dependency of
odoo. The gsfonts dependency was removed in the python3-renderpm Bullseye package.
With this commit the gsfonts dependency is set on the odoo Debian
package directly.
X-original-commit: 248762c80fbf3396d44ea9b55153dcd1d36d3490
Part-of: odoo/odoo#78097
In large database with unique serial number. The index add performance.
closesodoo/odoo#78087
X-original-commit: ccefa18bb2873412e6b0ac9e0f5e61ac82ccc51e
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Steps to reproduce the bug:
- Create a Product A with Costing Method = FIFO
- Create a Product B with Costing Method = FIFO and cost of 10
- Create a BOM of product A > type = Kit
- Add product B in bom line, with qty = 1 and UoM = dozen
- Add product A in `sale.order`
- Confirm order
Problem:
The cost is 10 rather than 120 (10 * 12 = 120)
Solution:
The kit cost must be the total cost of the components multiplied by their unit of measure
opw-2631487
closesodoo/odoo#78086
X-original-commit: 6c48262c8656821aa51669bd77cdf0f35634512f
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
Co-authored-by: fmdl <florent.mirieu@gmail.com>
- Remove unused method get_theoretical_quantity
- Remove unused args of _get_domain_locations_new and simplify it
closesodoo/odoo#78078
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
This commit removes `Add a column` from Grouped
Kanban view of Journal Items.
Creating new Records from `Add a column` should not be supported
from Journal Items and also it is not working for Journal/Account
as required fields are not set. (and also gives Traceback)
closesodoo/odoo#78074
X-original-commit: 21fe5c65fd3170ebfa01ea9a6b530d158f6c0c8e
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
When increasing the quantity of a validated Sale Order, the reserved
quantity in the related pickings aren't updated to match the new
quantity set in the Sale Order. It requires to either let the scheduler
run or clicking the 'Check Availability' button to update the reserved
quantity in those pickings.
If the reservation_method for this picking_type is set to 'at_confirm',
this is not the intended behavior as this picking is already confirmed,
so it should be updated without user input.
The reason is that when the new moves (which adds to the quantity) is
merged to the old one, its status is changed to 'partially_available'
because at that moment, the product_qty is bigger than the
reserved_quantity, which needs to be updated to match the new needs.
closesodoo/odoo#76752closesodoo/odoo#78070
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Allow the quantity decrease of Sale Order line of a MTO product.
When increasing de quantities, the related pickings, RFQ / PO are
increased as well, but it wasn't the case if decreasing the quantity.
It should allow the cascade of the decrease in the related pickings as
it would work for the increase. Also modifies a related Purchase Order
if it wasn't yet validated (and thus still a RFQ).
merge_moves was modified so it would allow the merge of negative moves
with positive ones, while trying to "deplete" as much quantity as
possible for each mergeable move.
But negative moves don't always have all required properties to be
compared to the positive ones (some keys might be missing, such as
'created_production_id'). That means we will merge strictly the positive
moves at first as it was done before. But then we try to merge them "less
strictly", using less keys to compare.
Let's say we have those moves (and all other relevant keys matches) :
- move_1 : {qty : 5, created_production_id: 1}
- move_2 : {qty : 3, created_production_id: 2}
- move_3 : {qty : -6, created_production_id: False}
move_1 and move_2 cannot be merged as they don't share the same
created_production_id. But to merge move_3, we'll need to merge it into
move_1 and move_2. It will then deplete move_1 and decrease move_2.
Which will leave us with :
- move_1 : {qty : 0, created_production_id: 1}
- move_2 : {qty : 2, created_production_id: 2}
move_3 will be unliked as its purpose is done.
Task-2513592
Part-of: odoo/odoo#78070
Issue:
When computing the landed cost for a transfer with quantity 0, the validation of the LC wasn't working since there was a quantity 0
Steps to reproduce :
Create a PO for some items
Confirm, validate the delivery
Edit and unlock the delivery, set one quantity to 0, save
Create a landed cost for that transfer
Compute it
Validate -> Traceback
Why is that a bug:
There should not be a traceback, this is caused by trying to validate a landed cost for a product where there is no quantity, if there is no quantity, it should be part of the landed cost computation
Background:
Following the fix recently applied in 14.0 and replicating for 13.0.
opw-2599799
closesodoo/odoo#78067
X-original-commit: f7b61bff319bf316228500e00785c8c44a30fc4b
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Co-authored-by: atremblay-biktrix <69811674+atremblay-biktrix@users.noreply.github.com>
Before this commit, there were some usages of
RTCPeerConnection.connectionState which is not available on some
browsers, including Firefox.
This commit fixes this issue and make it so that we only use
RTCPeerConnection.iceConnectionState instead.
closesodoo/odoo#78064
X-original-commit: 297442f72e23bc1a03ea857699fcae20b5cd0bbc
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Currently when unistall the hr_timesheet and try to open the project
menu it generates an traceback due to invalid field in domain of the
action.
so in this commit fix the traceback by adding the unistallation hook
so domain will be replaced on unistallation of the hr_timesheet.
also archive the internal project when unistalling the hr_timesheet.
Task-2629395
closesodoo/odoo#78063
X-original-commit: 8fe71cd7ff412a01b6f7dbaf569f7b85fbffd631
Related: odoo/enterprise#21551
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
With this commit we display list selection box after all list header buttons,
previously buttons were displayed before header buttons.
task-2628038
closesodoo/odoo#78057
X-original-commit: 09c5e178c61feb69d6fd27e4bb9df979fa480f41
Signed-off-by: FrancoisGe <fge@odoo.com>
Bug
===
Since fe8c5b9b01 , if you have a team
with set to `assignment_max` and you try to automatically assign the
leads an error is raised.
Technical: in `_allocate_leads` we skip a team if `assignment_max` is
Falsy. So when we prepare the values for the notifications, the key
might not be present in the dict an error is raised.
Task-2658696
closesodoo/odoo#78054
X-original-commit: 7c46b441266ff0336bf86d10ac2ee45d2a2c2959
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the server could return outdated information to the
client about the state of their own rtc session.
The server should not return information about the client's own rtc
session as the source of truth is the client-side state.
A case in which this was causing an issue was when a user toggled their
mute state right before their client pinged the server and received
outdated session information before their most recent state could be
sent to the server.
This commit fixes this issue.
closesodoo/odoo#78028
X-original-commit: fe991edd2bca98b58fc5a49494871475c79bc22f
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The idea of a text edit step is considered clearly communicated to the
end user from the moment the trigger is clicked ( as opposed to the
step waiting for actual input from the end user). This way an end user
can finish the tour faster without actually having prepared custom text
content yet.
task-2580338
closesodoo/odoo#77720
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
1. When the diff amount is for "combine" bank payment method, the
account.move record used to represent the combine amount is modified
to contain the diff amount. The journal entry is modified:
FROM:
```
Debit Credit
Outstanding combine_amount
Receivable combine_amount
```
TO:
```
Debit Credit
Outstanding combine_amount - diff_amount
Receivable combine_amount
Diff account diff_amount
```
2. When the diff amount is for "split" bank payment method, an
account.move moving the diff amount from Outstanding to Diff account
is created. The journal entry is like:
```
Debit Credit
Outstanding diff_amount
Diff account diff_amount
```
closesodoo/odoo#77859
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
There are two changes in this commit:
1. Show input fields for bank payment methods.
2. Move the logic that checks allowed diff amount from backend
to pos ui.
Part-of: odoo/odoo#77859
Since wowl framework is merged pager hitbox area is reduced and harder
to hit, with this commit we increase pager hitbox area.
task-2610578
closesodoo/odoo#78006
X-original-commit: ff788c20e9582adfb387d7111218a26b29519a70
Signed-off-by: FrancoisGe <fge@odoo.com>
Issue: Sometimes, when changing the Maximum (seats_max) on one of
the tickets of an event, it triggered a recompute for the other tickets
Steps to reproduce :
Install Events
Settings > Event > Enable "Tickets"
Create an event template (or use Sell Online default one) with
Check "Ticketing" and set the line price to 0
Create an event :
with that template
and Autoconfirm checked
Add a line for the Tickets:
name: VIP
price: 10
Save the event
Create two attendees for the event, one for each
Event Ticket (event_ticket_id) and confirm them (on the form, not
Confirm Attendee)
Change the Maximum (seats_max) of one ticket and save
-> the Confirmed (seats_reserved) will be recomputed but the
confirmed for the other ticket will increase as well
Side-Note:
I haven't been able to find a deterministic way to reproduce the bug
but it seems that the bug appear the most when doing all the steps at
once, and trying to not log out or refresh the page.
Also it works best on a runbot or at least with runbot data.
Without my modification, the new test passes on my local odoo server,
but fails on a dump of a runbot on my computer, adding my modification
makes it work on either case
Why is that a bug:
The recomputation seems to fail for some reason, we are setting all
the event/ticket in self to 0, but only update the value of those by
fetching a SQL query so there might be a desync there
opw-2642555
closes odoo/odoo#78023
Forward-port-of: #76492
X-original-commit: f4c936c9dc141de27a77006fb87dd2b63d88ec97
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Nathan Marotte <nmarotte@users.noreply.github.com>
This commit fixes visual issues (pixel gap between shapes and bugs in
colors) in some background shapes.
task-2547435
closesodoo/odoo#78013
X-original-commit: 861dba13657f1ca41c40304abd212c521a6615de
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit: In res.config.settings form view when user change something
in form and click on button in form then it will display to save the unsaved
changes, when we click 'Save' button from dialog still dialog remain there
it is not closed(while record is saved in background, just dialog is not closed)
This is because we called 'clearUncommittedChanges' method before executing
client action, 'Save' button on dialog returns client action for reload page
but as we calling 'clearUncommittedChanges' so it will call 'canBeDiscarded'
method of 'BaseSettingController' which again show dialog for unsaved changes.
After this commit: unsaved changes dialog is closed on clicking 'Save' button
from dialog, we called 'clearUncommittedChanges' method only if clientAction is
instance of Component, i.e. if client action is type of function which is our
case, reload is client action which type of function so in that case we do not
need to call 'clearUncommittedChanges'.
task-2662302
closesodoo/odoo#78035
X-original-commit: 5d8376a8f9a8957112afb35854bdb8b050bd6903
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before: the company menu would disapear when the screen was smaller than
some threshold. It is expected in enterprise, but not in community as
it doesn't have the burger menu.
After: The menu is set to always be displayed. To remove it becomes
an enterprise reponsability.
closesodoo/odoo#78034
X-original-commit: 039e24eabf258da6bfad45a839c51116f6d86e0c
Related: odoo/enterprise#21535
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Before: the user menu would disapear when the screen was smaller than
some threshold. It is expected in enterprise, but not in community as
it doesn't have the burger menu.
After: The menu is set to always be displayed. To remove it becomes
an enterprise reponsability.
closesodoo/odoo#78033
X-original-commit: 3b18f1cf8cfdbc497c8acba67970e835dabc2eb2
Related: odoo/enterprise#21534
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
With this, tooltips specified with the "data-tooltip" attribute in
owl templates will be translated.
closesodoo/odoo#78031
X-original-commit: 238f275e6d7e536764b7dbc3e7573dbc082804a9
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit:
- UTM campaigns are accessible for all internal users, but with email
marketing related modules installed, if user who does not have rights
for email marketing tries to access the campaign, an AccessError is
raised. It's because few fields related to email marketing are added
in model `utm.campaign` which are accesible only to the marketing
users.
- When the user is having `mass_mailing.group_mass_mailing_campaign`
group enabled but no rights for email marketing, the root menu of
for the 'Email Marketing' app is visible to that user, which is
not correct.
With this commit:
- While adding marketing related fields to the campaign, we provide the
group("mass_mailing.group_mass_mailing_user") at field level whenever
neccessary so it doesn't raise AcessError. Also, we show those fields
on the campaign views only when `mass_mailing.group_mass_mailing_campaign`
group is enabled for the user. To do this, a compute field has been
introduced to make sure that user has rights to access email marketing
as well as the feature to manage mass mailing from campaigns is enabled.
The reason behind introducing a new compute field is, at view level,
it is not possible to check that user is having multiple groups.
- We've applied the group "mass_mailing.group_mass_mailing_user" on the
root menu of Email Marketing app, so if the user has UI only group
"mass_mailing.group_mass_mailing_campaign" and but no rights for
email marketing, the root menu won't won't appear.
TaskID-2417993
closesodoo/odoo#74113
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit will change the way URLs are edited in discuss public view
to preserve URL params in the resulting URL.
Context:
In order to avoid leaking invitation links, URLs are modified in discuss
public view, but this can sometimes hide precious information such as
the debug mode from the URL.
closesodoo/odoo#78019
X-original-commit: 0a3b31c615bb319b4e0d9304e034df3520e8f33c
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
There is a test_mode to allow experimentation on the IAP server.
To be able to switch between the two, we need to make the
SERVER_URL configurable.
closesodoo/odoo#77977
X-original-commit: 11be1b25c60ae27a5e8078802883a1db867a6452
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: Paolo Gatti <lordkrandel@users.noreply.github.com>
When encoding a string or bytes with base64,
the resulting byte string must be decoded
to get the string back.
* `addons/account_edi_proxy_client/models/account_edi_proxy_user.py`
AccountEdiProxyUser._register_proxy_user()
* `addons/l10n_it_edi/models/account_invoice.py`
AccountMove._prepare_fatturapa_export_values()
* `addons/l10n_it_edi_sdicoop/models/account_edi_format.py`
AccountEdiFormat._l10n_it_post_invoices_step_1()
X-original-commit: 3a705d93543e910b6af4b3b4aa53c523f367782a
Part-of: odoo/odoo#77977
*: mass_mailing, website, website_sale
Before this commit, it was impossible to add `fa-fw` directly on a
`we-button` as it would make the icon half invisible, since the whole
`we-button` would have the font-awesome `.fa-fw` css rule applied on it;
width: ~1.28em.
Then, one would need to insert a `<i/>` tag inside the `we-button` for
it to work.
This commit improves that behavior by handling automatically such cases,
and will preserve the purpose of the `fa-fw` class which is to have a
fixed width for those icons.
Note that the util class introduced in [1] (o_we_button_icon renamed
here in o_we_icon_button) is still useful to handle the case of svg
images, they are not allowed to shrink, the same way the fa buttons are.
[1]: https://github.com/odoo/odoo/commit/e4233643b93b521454cc146c6a2ae876781fb9ba
Related to task-2172311
closesodoo/odoo#77980
X-original-commit: e8ab9d76b802e80bb386812e4c8566825cbc2c92
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Younn Olivier <yol@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Quick fix that need to be automated.
Closes#77981closesodoo/odoo#77994
X-original-commit: 0a07ddbc750e561b63f6f12568baa66eba7c3ba2
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Update the image of buster for the build of the IoT
Update the version of rlated build
closesodoo/odoo#77973
X-original-commit: f9fc28a3a9b8b620c4b1d483e07f3de5de8155c3
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Some themes replace the website.template_header_default template in the
website layout. This poses a problem when changing to another theme
afterwards because of the interaction between the website templates and
the _reset_default_config method:
1) Since version 15.0 the nav tag inside the header templates was
abstracted into a separate template (website.navbar) and added to each
header layout through t-call.
2) The _reset_default_config deactivates or reactivates views that were
enabled or disabled by the currently active theme. However, when doing
so, the default header is activated before the custom header is
deactivated.
As a consequence, after toggling the default header, there are
temporarily two header extensions in the website.layout template. They
both replace the //header//nav element. Because of the abstraction of
the nav element into a separate template by the header extensions, only
the first replacement will work.
task-2662497
closesodoo/odoo#77917
X-original-commit: b83a2110fd3035cc8466c4fa74f6530be5d00597
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
baa