Saturday, June 15, 2024
6 changes
4 changes
Miscellaneous changes
Create a [TEST] Product with: - Invoicing Policy: Prepaid/Fixed Price product - Create on Order: Project & Task - Unit of Measure: Days Create a Sales Order with [TEST] prod and a tax Add a timesheet line on the recorded hours Go in Timesheet > Reporting > By Project Add the measure Timesheet Revenues Issue: Revenues are tax included, but should be tax excluded This occurs because we are computing the revenue using the sale order line price total opw-3864227 Forward-Port-Of: od
Original PR description
Create a [TEST] Product with: - Invoicing Policy: Prepaid/Fixed Price product - Create on Order: Project & Task - Unit of Measure: Days Create a Sales Order with [TEST] prod and a tax Add a timesheet line on the recorded hours Go in Timesheet > Reporting > By Project Add the measure Timesheet Revenues Issue: Revenues are tax included, but should be tax excluded This occurs because we are computing the revenue using the sale order line price total opw-3864227 Forward-Port-Of: odoo/odoo#168754
The main goal of this pr is to adapt the requirements to make it work in ubuntu Noble (right now, it will only work when using debian packages) ## FIX requirements_check.py The first step is to adapt and fix the requirements_check in order to have an overview of the current state.  This is showing the difference between an installation from pip compared to the official packaged version in the dis
Original PR description
The main goal of this pr is to adapt the requirements to make it work in ubuntu Noble (right now, it will only work when using debian packages) ## FIX requirements_check.py The first step is to adapt…
The main goal of this pr is to adapt the requirements to make it work in ubuntu Noble (right now, it will only work when using debian packages) ## FIX requirements_check.py The first step is to adapt and fix the requirements_check in order to have an overview of the current state.  This is showing the difference between an installation from pip compared to the official packaged version in the distribution matching the same python version. Red usually means that the package in the corresponding version has a higher version than the pinned one. We expect to have almost the same version as the corresponding minimal supported python version. It is possible that some version are higher (yellow) for historical/security/compatibility reasons. ## Adapt requirements.txc We don't need to fix all versions, but we want to adapt it to work in most cases, mainly we need to be able to install the requirements on ubuntu Noble. If a change is needed, the version of the requirement for 3.12 is pinned to match the version of the package in ubuntu Noble. ### greenlet The first change concern greenlet and gevent, the current version does not install on python 3.12 ### Missing wheel The second changes adapt all packages that did not have a wheel in 3.12. Some of them fail to build, and building them is slow. ### Non compatible packages Finally, some package are not compatible, leading to import error or requirements install errors  Since the requirements versions are the same as the debian package version we expect the build with requirements to be green similar to the PureNoble builds. ### Fix win32 wheel Building wheel on windows is painful because c++ builds tools are quite heavy and not included. Most of the version pinned in 3.12 will have a wheel on win32, except got gevent and greenlet. Since they are not required to run odoo, removing them for win32 ### Simplify psycopg2 dependencies Note that if most changes does only concern 3.12, an exception was made to simplify psycopg2 exceptions Since there is no wheel package in psycopg 2.8.6, the pinned version was 2.9.5, an **exception** for windows (exception in blue) But in Jammy, with python 3.10, the expected version is actually 2.9.2 (column is red) which has a wheel package sor windows  We can fix both issues by pinning 2.9.2 for all python 3.10, not depending on the operating system.  It also looks like we have a wheel package in windows 2.7.7 and python 3.7, so we could simplify even further, but I'm not sure if it was intended or a remaining from change history. Anyway, this will be clean in future version where minimal version is higher than 3.7. Manual forwardport of #168296 Forward-Port-Of: odoo/odoo#169199
- Create a partner, configure it correctly to generate a Peppol BIS xml (Peppol bis3 edi format, fill in peppol eas & peppol endpoint). For example, configure Deco Addict - Create a contact for that partner (e.g. could use Deco Addict, Addison Olson) - Create an invoice for that contact - Open Send & print -> the option to generate the xml file is not visible This is because `ubl_cii_format` field is defined on the parent partner and so we don't have a value for it in child partners. op
Original PR description
- Create a partner, configure it correctly to generate a Peppol BIS xml (Peppol bis3 edi format, fill in peppol eas & peppol endpoint). For example, configure Deco Addict - Create a contact for that partner (e.g. could use Deco Addict, Addison Olson) - Create an invoice for that contact - Open Send & print -> the option to generate the xml file is not visible This is because `ubl_cii_format` field is defined on the parent partner and so we don't have a value for it in child partners. opw-3958830 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169520 Forward-Port-Of: odoo/odoo#169243
There was some miscommunication about the warning message in https://github.com/odoo/odoo/commit/2384a059e25f66117326d9bfde1e40b2dd493962 The warning on the partner should not check the bank account. What needs to be checked is the Recipient bank on the invoice, the warning should be visible in send & print. It is ok to add it in later versions where it is easier to add more warnings. Part of: task-3989435 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.c
Original PR description
There was some miscommunication about the warning message in https://github.com/odoo/odoo/commit/2384a059e25f66117326d9bfde1e40b2dd493962 The warning on the partner should not check the bank account. What needs to be checked is the Recipient bank on the invoice, the warning should be visible in send & print. It is ok to add it in later versions where it is easier to add more warnings. Part of: task-3989435 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169438
2 changes
Miscellaneous changes
Editing the `amount_currency` field of a product line in the "Journal Items" tab on an invoice is not really possible at the moment. On a technical level: The function `_compute_release_to_pay` assigns fields `release_to_pay` and `release_to_pay_manual`. Yet, it is only registered as compute function of `release_to_pay`. This behaviour is not correct; i.e. it causes a recomputation of the `amount_currency` field on the line mentioned above. In this commit a compute function for `rele
Original PR description
Editing the `amount_currency` field of a product line in the "Journal Items" tab on an invoice is not really possible at the moment. On a technical level: The function `_compute_release_to_pay`…
Editing the `amount_currency` field of a product line in the "Journal Items" tab on an invoice is not really possible at the moment. On a technical level: The function `_compute_release_to_pay` assigns fields `release_to_pay` and `release_to_pay_manual`. Yet, it is only registered as compute function of `release_to_pay`. This behaviour is not correct; i.e. it causes a recomputation of the `amount_currency` field on the line mentioned above. In this commit a compute function for `release_to_pay_manual` is introduced. It basically does the job that the old computation function did. To reproduce on runbot: 1. Create an invoice with a single line 2. Got to "Journal Items" 3. Edit the "Amount in currency" of the first line (product) 4. Save the invoice 5. The "Amount in currency" is reset to the original version. The same code also causes an issue in 17.0+; see https://github.com/odoo/odoo/pull/167014 Forward-Port-Of: odoo/enterprise#64695 Forward-Port-Of: odoo/enterprise#63336
__Current behavior before commit:__ When all slots from the first staff user/resource are taken, the `/appointment/<id>` page shows no availabilities even if the following users/resources still have slots. The user/resource selector is also not displayed. This means that it is not possible for a visitor to book an appointment as soon as the first one is fully booked. __Description of the fix:__ A new method `_get_slots_values` has been added to the `AppointmentController` class. This m
Original PR description
__Current behavior before commit:__ When all slots from the first staff user/resource are taken, the `/appointment/<id>` page shows no availabilities even if the following users/resources still have…
__Current behavior before commit:__ When all slots from the first staff user/resource are taken, the `/appointment/<id>` page shows no availabilities even if the following users/resources still have slots. The user/resource selector is also not displayed. This means that it is not possible for a visitor to book an appointment as soon as the first one is fully booked. __Description of the fix:__ A new method `_get_slots_values` has been added to the `AppointmentController` class. This method will compute the available slots for every possible user/resource until there is one that has slots available. And it starts by checking the default one. However if one is specifically selected by the visitor, it will be used even if there is no slots for it. This way the visitor can select it see that it has no availabilities but he can still switch user/resource with the selector. If there is no default nor selected user/resource then the slots are computed for all possible users/resources. A new test has been added to check if the shown staff user is the correct one and if the selector and calendar are visible even when the first one has no availabilities. __Example of steps to reproduce the issue:__ - Create a new `appointment.type` - Set the max scheduling days to 7 - Keep only one schedule time slot (e.g. Monday from 9:00 to 10:00) - Set **Availability on** to *Resources* - Put at least 2 courts in **Resources** - Click on `Share`, select **Assign to** *Any User/Resource* - Open the link - Book the slot of the first court - Come back the slot selector page -> No more slots available although the second court has still one opw-3862746 Forward-Port-Of: odoo/enterprise#62634