Steps to reporduce:
1- Install Accounting, Fleet modules
2- Create a bill in accounting with a different currency than the company's default, and add a line with a chosen vehicle_id.
3- Go to the chosen vehicle in Fleet module
4- Navigate to the service created for this bill
Current behavior before PR:
If we create a bill for a vehicle using a different currency than
the company's default. The fleet service that will be created
will be having the company's currency but the value will be the amount
in the currency used in the bill
Desired behavior after PR is merged:
We now create the fleet service using the value in debit
not the unit price or the price subtotal.
opw-3734743
closesodoo/odoo#163228
X-original-commit: 0ef2abaa3e926daa71e004e0583503b7e3167a59
Related: odoo/enterprise#61408
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
Steps to reproduce:
1- Create an allocation with validity date (e.g. 01-01-2024 -> 30-06-2024)
and another one starts after the first one (e.g. 01-07-2024 -> 31-12-2024)
2- Go to Time off module and select a date in the second allocation's period
3- Click on the Time off type dropdown menu
4- You will see the first allocation displayed not the second one
Current behavior before PR:
The display name of some leaves gets computed in a wrong way.
This is happening because after fetching the right allocation
we compute the display name but this time we don't have
the 'default_date_from' in context so since
it became one of the fields that triggers '_compute_leaves'
https://github.com/odoo/odoo/blob/17.0/addons/hr_holidays/models/hr_leave_type.py#L218:L219
we compute the leaves once again but the target_date will be none
and it will get assigned with today's date in 'get_allocation_data'
https://github.com/odoo/odoo/blob/17.0/addons/hr_holidays/models/hr_leave_type.py#L380:L381
Desired behavior after PR is merged:
This has been solved by saving the date attribute in the context
with another name as when computing the display_name we call sudo so clean_context()
removes the 'default_' context keys. Now when it gets removed we are
going to have the same value but with another name.
opw-3797696
closesodoo/odoo#159917
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
Steps to reproduce:
1- Install Point of sale module
2- Allow shipping later configuration
3- Create a POS order with a shipping date
Current behavior before PR:
The expected shipping date was not printed in the pos receipt.
This was happening because it was getting called wrong in xml file
where it was called 'props.shippingDate'.
By checking the JS file we found that the props object structure
as follows https://github.com/odoo/odoo/blob/17.0/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/order_receipt.js#L16:L19
Desired behavior after PR is merged:
The expected shipping date is printed not if exists.
As we it is now getting called correctly 'props.data.shippingDate'
opw-3746053
closesodoo/odoo#155844
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Steps to reproduce:
1- Install Field Service module
2- Create new task and click on products smart button
3- Hover over a product and click on the dropdown menu
4- Click on edit in the dropdown menu
5- Get back to the products page and check the quantity for the product you edited
Current behavior before PR:
When the user clicks on edit in the dropdown menu of any product the quantity gets increased by 1. This is happening because of the global click event so when the user clicks anywhere inside the kanban box the quantity gets updated.
Desired behavior after PR is merged:
This behavior has been adjusted by checking the target where the user click if it is inside the dropdown menu it will not update the product's quantity.
opw-3689864
closesodoo/odoo#153293
Related: odoo/enterprise#56161
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
Steps to reproduce:
1- Install Sales module
2- Activate developer mode
3- Navigate to any storable product
4- Click on 'Replenish'
5- Click on 'developer bug' and Choose 'Set Defaults'
6- Choose 'Scheduled Date' from the 'Default' dropdown menu and Save
Current behavior before PR:
When trying to set a default value for scheduled date in 'Replenish' for a product it will display an error for 'Invalid type' this is happening because when converting the string value to a datetime value it does not handle iso format date and this is the format that gets passed from the UI.
Desired behavior after PR is merged:
It is handled now from the UI side that the format that is been sent is the server valid format of datetime.
opw-3692472
closesodoo/odoo#154209
X-original-commit: 6dc46639935fdc175b2d094b58ef4e66c68466b0
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
Steps to reproduce:
1- Install Members module while Accounting is uninstalled
Current behavior before PR:
When you install Members module without having Accounting module you will not be able to access Members module as it will be hidden on the dashboard. This happens because of the access rights that the Member module has as it is having the access right group of the Accounting module 'group_account_user'. This issue happened after this commit https://github.com/odoo/odoo/commit/f6c60e497520d7916937f4a2a57ed3f8c2e1049b#diff-65a587634b23c60ecc8eea20881920a50eddbc569aa5d0381705b7405e918e2e
Desired behavior after PR is merged:
Now the Members module has the access right group of Invoicing module 'group_account_invoice' which is the only dependency module that Members need. So it will be visible and accessible from the dashboard once installed
opw-3627010
closesodoo/odoo#154070
X-original-commit: d0bd175e10f72649bcd310d6d5b068dc6bfd2b5f
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Desired behavior after PR is merged:
Enhancing the job posting with an XML tag for the title of the position so it can be used for the google rich search.
opw-3713519
closesodoo/odoo#153682
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Steps to reproduce:
1- Install Manufacturing module
2- Create 2 or more new WOs and make sure that their corresponding MOs is not planned
3- Go to Operations > Work orders
4- Mark all of those WOs and write a start date to apply on all of them
5- Check Planning > Planning by Workcenter 'you will not find the scheduled WOs'
Current behavior before PR:
When you try to mark more than one record in Work orders and set start date for all of them at the same time it will not be set therefore it will not be visible in Planning calendar. This is happening because if you are setting the start date for the first time it will call the function that sets the start date first before calculating the finish date so it will not pass the condition where it checks if both dates have values.
Desired behavior after PR is merged:
Now we are checking just the start date if it has value or not and to raise the same user error if the customer tries to delete the finish date we are checking this on change of the finish date from a value to null.
opw-3596100
closesodoo/odoo#151272
X-original-commit: 70394e616e5d75ee33ed048dbd7210c1926c63be
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
Steps to reproduce:
1- Install Sales module
2- Activate Lock Confirmed Sales from Sales settings
3- Create a new order as a Public user and make the payment
4- Check the state of this order in backend
Current behavior before PR:
Upon creating and confirming an order as a public user the order does not get locked even if the 'Lock Confirmed Sales' setting is turned on. This is happening because when checking if the 'Lock Confirmed Sales' group is on or not we check if it is there for the current user which if he is a public user by default will not have this group.
Desired behavior after PR is merged:
Before we had this condition checking if self.env.user has the 'Lock Confirmed Sales' but this won't work if the SO is coming from eCommerce with public user env So now we are checking the creator of the SO that in the eCommerce scenario will be OdooBot and if the SO is created from the backend it will be one of the users who already has the group.
opw-3595964
closesodoo/odoo#148363
X-original-commit: 4cfd125837858f70d63d14f41265b9b9f47a933b
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
Steps to reproduce:
1- Install POS module and French Localization
2- Open a session in POS
3- Add an item to the order then remove it and set the quantity to 0
Current behavior before PR:
When you try to remove an item from POS while using french localization it gives an error 'null exception'. This happens because we are trying to set the quantity to the order after unlinking the order line and setting the order with null.
Desired behavior after PR is merged:
The error pop-up is not there anymore and you can remove any item. Now we set the new quantity to the order before unlinking the order to avoid the null exception
opw-3607956
closesodoo/odoo#144592
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Current behavior before PR:
When you send an email at the receivers end you will see ' ' shown before you open the mail and it disappears once you open the email
Desired behavior after PR is merged:
Corrected and now the ' ' character doesn't appear where I replace it in the HTML template with its equivalent character
Test changes:
The test case that was there was comparing static strings with the HTML entities where my solution is removing those entities so I change the strings to be after escaping those HTML
opw-3481781
closesodoo/odoo#144648
X-original-commit: 1fcd45f19c2d6900ad5d1848a988ab0ae5f287a8
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Steps to reproduce:
1- Install CRM app
2- Go to pipeline and create a new lead
3- Write a name for contact and click on 'Create and edit...'
4- Choose 'individual' as contact type and select the company related to this individual
5- the address will remain empty and will not be auto populated
Current behavior before PR:
The address is not auto populating when creating a new individual contact through a new lead. This happens because when you choose the contact type to individual the address type is not chosen so it is not populating any of the addresses
Desired behavior after PR is merged:
The address is now auto populating as I am passing to the form a default value for the contact type which is 'Contact' which is the default value when you create a contact from Contacts app
opw-3569833
closesodoo/odoo#143408
X-original-commit: ae51afafc606e5ca568864fdf04a0ea618bf242d
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
Current behavior before PR:
In chart of accounts in french localization the accounts with 607 was named 'Ventes de marchandises' where it should be named 'Achats de marchandises'
Desired behavior after PR is merged:
The translation has been updated and now it is named correctly
opw-3536801
closesodoo/odoo#141483
X-original-commit: d6b99af8912573970e6a848719f80d11c22b5041
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
Steps to reproduce:
1- Install Sales and Events modules
2- Create a new Event and event registeration
3- Create a sale order for this event
4- Check the sales smart button in the event's form
5- Cancel the sale order and check the smart button
Current behavior before PR:
When you create a sale order for an event and then cancel it the value of this sale order will not be deducted from the sum of the sale values at the sale smart button in the event form.
Desired behavior after PR is merged:
When you cancel a sale order related to an event the sale smart button value will be updated
opw-3543943
closesodoo/odoo#140547
X-original-commit: b5554f6f7597b44adfa318655bab1eab19158303
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
Youssef Bashandy