Friday, December 13, 2024
12 changes · saas-17.2
Miscellaneous changes
Before this commit: Import a statement having transactions including debited charges in their total credited amount. In that case, the retrieved amount is incorrect, it does not include the charges. After this commit: The debited charges are retrieved and included in the amount. opw-3208721 Forward-Port-Of: odoo/enterprise#74962
Original PR description
Before this commit: Import a statement having transactions including debited charges in their total credited amount. In that case, the retrieved amount is incorrect, it does not include the charges. After this commit: The debited charges are retrieved and included in the amount. opw-3208721 Forward-Port-Of: odoo/enterprise#74962
Steps to reproduce: - Install the planning module. - Open Gantt view in day scale. - Create a planning slot from 11am to 12pm for an employee whose working hours are 8-12 and 13-17 - The default hours will be shown as 13 to 12 Issue: - When an employee works two shifts for example 8-12 and 13-17, and we are creating a slot from 11-12, the slot timing will show as 13-12 instead of 8-12. Cause: - here is an example of how the planning slot will be calculated and what i
Original PR description
Steps to reproduce: - Install the planning module. - Open Gantt view in day scale. - Create a planning slot from 11am to 12pm for an employee whose working hours are 8-12 and 13-17 - The default…
Steps to reproduce: - Install the planning module. - Open Gantt view in day scale. - Create a planning slot from 11am to 12pm for an employee whose working hours are 8-12 and 13-17 - The default hours will be shown as 13 to 12 Issue: - When an employee works two shifts for example 8-12 and 13-17, and we are creating a slot from 11-12, the slot timing will show as 13-12 instead of 8-12. Cause: - here is an example of how the planning slot will be calculated and what is miscalculation - When click on cell 9-10 the calculated hours <table><thead><tr><th>Cell</th><th>shift start time </th><th>shift end time </th></tr></thead><tbody><tr><td>9-10</td><td>|8 - 9| = 1<br>|13 - 9| = 4<br></td><td>|12 - 10| = 2<br>|17 - 10| = 5<br></td></tr><tr><td>minimum</td><td>8</td><td>12</td></tr></tbody></table> so that slot timining will be 8 - 12 - When click on cell 11-12 <table><tbody><tr><td>Cell</td><td>shift start time </td><td>shift end time </td></tr><tr><td>11-12</td><td>|8 - 11| = 3<br>|13 - 11| = 2<br></td><td>|12 - 12| = 0<br>|17 - 12| = 5<br></td></tr><tr><td>minimum</td><td>13</td><td>12</td></tr></tbody></table> So that the slot timining will be 13-12 which should not be possible Fix: - We previously relied on the ```_adjust_to_calendar``` method to calculate the resource's working hours. However since the working hour intervals are already computed using ```_work_intervals_batch```, we are removing the method call to reduce code duplication. Calculate the working hours using ```_work_intervals_batch``` and return the appropriate work intervals based on the resource's working calendar. task-3916687 Forward-Port-Of: odoo/enterprise#75594 Forward-Port-Of: odoo/enterprise#64961
This reverts commit 261181bd5ab84418d51310ba7bfa52061ffc893e. Shouldn't touch py files in this module and the change isn't neccesary in this case anyways since in the context of this error, customers will be in the config window. Hopefully they will be able to figure out the correct setting to switch to. Forward-Port-Of: odoo/enterprise#75127 Forward-Port-Of: odoo/enterprise#75113
Original PR description
This reverts commit 261181bd5ab84418d51310ba7bfa52061ffc893e. Shouldn't touch py files in this module and the change isn't neccesary in this case anyways since in the context of this error, customers will be in the config window. Hopefully they will be able to figure out the correct setting to switch to. Forward-Port-Of: odoo/enterprise#75127 Forward-Port-Of: odoo/enterprise#75113
Version: - 17.0 Step to reproduce: - upload sign template - click on sign now button on template Issue: - two sign now buttons are visible to user Cause: - there is an issue in condition to make button invisible as it require both the condition to be true to make button invisible Solution: - change condition which will make button invisible when any one condition true. task-4234996 Forward-Port-Of: odoo/enterprise#71350
Original PR description
Version: - 17.0 Step to reproduce: - upload sign template - click on sign now button on template Issue: - two sign now buttons are visible to user Cause: - there is an issue in condition to make button invisible as it require both the condition to be true to make button invisible Solution: - change condition which will make button invisible when any one condition true. task-4234996 Forward-Port-Of: odoo/enterprise#71350
We need to first check if active_ids exist and get usererror if there are no active_ids present. [Link to Runbot Error builds](https://runbot.odoo.com/web#id=74407&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190324
Original PR description
We need to first check if active_ids exist and get usererror if there are no active_ids present. [Link to Runbot Error builds](https://runbot.odoo.com/web#id=74407&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190324
Add the support for the STORE_SLICE opcode in safe_eval, It looks like an oversight when support for python 3.12 was added. Some code that previously worked in python 3.11 doesn't work anymore on python 3.12 example : foo[:3] = [bar,bar,bar] Forward-Port-Of: odoo/odoo#187867
Original PR description
Add the support for the STORE_SLICE opcode in safe_eval, It looks like an oversight when support for python 3.12 was added. Some code that previously worked in python 3.11 doesn't work anymore on python 3.12 example : foo[:3] = [bar,bar,bar] Forward-Port-Of: odoo/odoo#187867
Before this commit: In case an E-waybill is already generated we post a help message as log note on the invoice with URL that user can check that on the government portal, But whenever user links on the URL it give a error code of 404 In this commit we post the correct URL, and the user is re-directed on the correct page --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190494 Forward-Port-Of: odoo/odoo#190308
Original PR description
Before this commit: In case an E-waybill is already generated we post a help message as log note on the invoice with URL that user can check that on the government portal, But whenever user links on the URL it give a error code of 404 In this commit we post the correct URL, and the user is re-directed on the correct page --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190494 Forward-Port-Of: odoo/odoo#190308
body_content is a better representation of what the email will actually look like when sent. task-4333657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190447 Forward-Port-Of: odoo/odoo#188803
Original PR description
body_content is a better representation of what the email will actually look like when sent. task-4333657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190447 Forward-Port-Of: odoo/odoo#188803
In this commit we fix to two things: 1. For SEZ(intra state) with payment of `IGST`, the `IGST` on Intra used to be sent `False` for E-Invoice 2. For Overseas export, refund claimable is also used to be sent as `False` with same situation payable of `IGST` in case of export In this commit resolve the above issues Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and
Original PR description
In this commit we fix to two things: 1. For SEZ(intra state) with payment of `IGST`, the `IGST` on Intra used to be sent `False` for E-Invoice 2. For Overseas export, refund claimable is also used to be sent as `False` with same situation payable of `IGST` in case of export In this commit resolve the above issues Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190151
Before this commit: We didn't allow passing of `IGST` tax rate while sending E-waybill json to government on an intra state invoice After this commit we allow sending `IGST` tax rate in E-waybill json because there few specific scenario where `IGST` is applicable on intra state transaction e.g. SEZ partner within the company state in this case `IGST` will be applicable --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/o
Original PR description
Before this commit: We didn't allow passing of `IGST` tax rate while sending E-waybill json to government on an intra state invoice After this commit we allow sending `IGST` tax rate in E-waybill json because there few specific scenario where `IGST` is applicable on intra state transaction e.g. SEZ partner within the company state in this case `IGST` will be applicable --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190212
Steps to reproduce the issue: - go to currencies; - search for a rate with something else than a date; - it crashes. This happens because the currency rate model is searched with two fields, a date field (`name`) and a float field (`rate`). This crashes when converting the value to match against, because the value cannot be serialized in SQL both as a date and a float. What we do in such a case is to explicitly convert the value to the field's type. If the conversion fails, we simply
Original PR description
Steps to reproduce the issue: - go to currencies; - search for a rate with something else than a date; - it crashes. This happens because the currency rate model is searched with two fields, a date field (`name`) and a float field (`rate`). This crashes when converting the value to match against, because the value cannot be serialized in SQL both as a date and a float. What we do in such a case is to explicitly convert the value to the field's type. If the conversion fails, we simply ignore that part of the domain. opw-4278234 Forward-Port-Of: odoo/odoo#190495 Forward-Port-Of: odoo/odoo#187838
* STEP TO REPRODUCE: try to _message_log on a channel contain record link (an a tag with data-oe-model and data-oe-link) then click on it -> nothing happen * REASON: when _message_log in mail.channel, it will consider that message as a NotificationMessageView model and we do not have onClick for it unlike MessageView model * SOLUTION: implement onClick for NotificationMessageView just like MessageView Description of the issue/feature this PR addresses: Current behavior before PR: Desi
Original PR description
* STEP TO REPRODUCE: try to _message_log on a channel contain record link (an a tag with data-oe-model and data-oe-link) then click on it -> nothing happen * REASON: when _message_log in mail.channel, it will consider that message as a NotificationMessageView model and we do not have onClick for it unlike MessageView model * SOLUTION: implement onClick for NotificationMessageView just like MessageView Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189811 Forward-Port-Of: odoo/odoo#188380