[FIX] hr_holidays: fix missing value argument in _search_virtual_remaining_leaves. - #5256
Open
aski97 wants to merge 178 commits into
Open
[FIX] hr_holidays: fix missing value argument in _search_virtual_remaining_leaves.#5256aski97 wants to merge 178 commits into
aski97 wants to merge 178 commits into
Conversation
…issing Before this change, the "New Contract" button was always visible on the employee form (in payroll section), even when no contract date was present. This fix adds a `t-if` condition in the button template to ensure the button is only displayed when the contract date is fulfilled. Task: 6518971
|
This PR targets the un-managed branch odoo-dev/odoo:master-hr-onboarding-vibel, it needs to be retargeted before it can be merged. |
usseif97
requested changes
Aug 31, 2026
usseif97
left a comment
usseif97
left a comment
There was a problem hiding this comment.
Thanks for your work. The fix is to the point 🎯
Here's how bug-fix tasks are handled
You need to include on the PR description, the bug, steps to reproduce & how it solved
Also you should add a test to ensure that the issue doesn't reappear in the future and you should clearly add the test on the appropriate related test file
…sible-vibel [FIX] hr: hide "New Contract" button when employee contract date is missing
aski97
force-pushed
the
master-hr-traceback_time_off_type-vibel
branch
from
August 31, 2026 12:20
0b229cd to
42ac7e4
Compare
usseif97
requested changes
Sep 1, 2026
| with self.assertRaises(ValidationError): | ||
| work_entry_type.count_days_as = 'working' | ||
|
|
||
| def test_search_virtual_remaining_leaves(self): |
There was a problem hiding this comment.
Here you created work entry type without allocation, and it's correct, what about creating another one that require allocation and check if it works
aski97
force-pushed
the
master-hr-traceback_time_off_type-vibel
branch
from
September 1, 2026 08:19
42ac7e4 to
661fccb
Compare
Convert the following services to plugins: - pos_data_service - pos_ticket_printer_service closes odoo#283810 Related: odoo/enterprise#128740 Signed-off-by: Stéphane Vanmeerhaeghe (stva) <[email protected]>
Export `FloatWithoutTrailingZeros` and `floatWithoutTrailingZeros` from the `hr` module so they can be imported and extended in Enterprise to support float fields with custom unit suffixes (e.g., "Days"). closes odoo#284770 Task: 6222665 Related: odoo/enterprise#117687 Signed-off-by: Abdelrahman Mahmoud (amah) <[email protected]>
… for e-Archive invoices
Purpose:
Turkiye e-Archive regulations require invoices generated from e-commerce sales
to include specific tracking and fulfillment information. Previously, the system
did not distinguish between standard sales and e-commerce sales, which is
required by GiB.
Modifications:
-Introduced stored computed field `l10n_tr_sales_type`('normal', 'website') on
'account.move', allowing users to control whether e-commerce nodes are included.
-Made `l10n_tr_sales_type` and `l10n_tr_gib_invoice_type` required when
`l10n_tr_nilvera_customer_status = 'earchive'`.
-Updated e-Archive XML generation to automatically inject required e-commerce
nodes when `l10n_tr_sales_type` is set to 'website'.
-Added validation checks to block export if required e-commerce details are missing.
Key additions for e-commerce sales include:
-Identifies the order as e-commerce sale and includes specific website domain.
-Adds payment details such as agent name, method used (e.g., Credit Card, Wire
Transfer, Payment Provider), and payment date.
-Includes logistics data like carrier/driver name, Tax ID (VKN/TCKN), and
shipment/delivery date.
Related Upgrade PR: odoo/upgrade#10981
task-6236315
closes odoo#274723
Related: odoo/upgrade#10981
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <[email protected]>
Issue: When moves share the same `sequence_number` in a journal but have different suffixes (e.g. `INV/2026/00010` and `INV/2026/00010A`), the `made_sequence_gap` flag was incorrectly set Cause: `_update_sequence_made_gap`, introduced in commit odoo@1789308 selects the previous and next moves ordered by `sequence_number` without filtering by suffix This causes two issues: - Moves from different suffix sequences are used as neighbors, leading to incorrect gap detection - Duplicate `sequence_number` values across suffixes are not accounted for, so only one move is considered per number Steps to reproduce: - Install `account` - Post 12 invoices to get a sequence up to `INV/2026/00012` - Reset `INV/2026/00012` to draft, rename it to `INV/2026/00010A` - Reset `INV/2026/00010A` to draft, rename it to `INV/2026/00009A` and confirm Before the fix: `INV/2026/00011` is red Expected: `INV/2026/00011` should not be red because `INV/2026/00010` exists - Delete `INV/2026/00009` Before the fix: `INV/2026/00010` is red Expected: `INV/2026/00010` should be red (gap in no-suffix sequence) - Reset `INV/2026/00009A` to draft and confirm it again Before the fix: `INV/2026/00010` is not red Expected: `INV/2026/00010` should still be red (different suffix) Notes: Suffix changes are treated as distinct sequences following the same gap rules as any other sequence This was agreed with R&D — the gap flag is meant to signal inconsistencies within a sequence, not across suffixes opw-6454823 closes odoo#285107 X-original-commit: 9c67949 Signed-off-by: Corentin Heinix (cohe) <[email protected]>
Japanese translation "海外取引先" for domestic was clearly wrong.
Also fixed the misspelling ("Oversea" -> "Overseas") and removed the unnecessary "Customer" context from the name.
closes odoo#284870
X-original-commit: 8495f7a
Signed-off-by: Nicolas Viseur (vin) <[email protected]>
Microsoft issues a new refresh token on every access token refresh (rolling 90-day sliding window). The previous code discarded it, causing users to be forced to re-authenticate every 90 days once the original token expired. Closes odoo#253543 closes odoo#280851 X-original-commit: 93b7cd5 Signed-off-by: Renaud Thiry (reth) <[email protected]>
The `_get_so_mapping_from_project()` method returns a mapping where the key is
the move line ID and the value is a `sale.order` record (or `None`).
Because of the issues described below, a valid `sale.order` could be available
for reinvoicing, but the corresponding move line might still not be mapped to
that sale order. As a result, the move line is not added to the reinvoiceable
sale order.
However, the implementation has two issues:
`project_per_accounts` is built as a dictionary mapping an analytic account ID
to a single project. If multiple projects reference the same analytic account,
each new assignment replaces the previous one. As a result, only the last
project associated with a given analytic account is retained.
**Example:**
* Analytic Account **AA1** is linked to **Project A** and **Project B**.
* The dictionary becomes `{AA1: Project B}`.
* **Project A** is lost, even though it also references **AA1**.
**Steps to reproduce:**
1. Create an analytic account **AA1**.
2. Create **Project A** and **Project B**, both linked to **AA1**.
3. Create **Sale Order SO1** linked only to **Project A**.
4. Create a vendor bill (or expense) that generates an AML using **AA1** for a
product configured with **Reinvoice Costs = At Sales Price**.
5. Validate the document.
**Expected behavior:**
The product should be added to **SO1** for reinvoicing.
**Actual behavior:**
The move line is not mapped to **SO1**, so no sale order line is created.
The `project` variable is reassigned on every iteration of the loop. After the
loop completes, it only contains the project (or lack of one) corresponding to
the last processed analytic account. This can cause valid projects found earlier
in the loop to be discarded.
**Example:**
* Move line has analytic accounts **AA1** and **AA2**.
* **AA1** maps to **Project A**.
* **AA2** has no linked project.
* After the loop, `project` is `None`, even though **Project A** was found.
**Steps to reproduce:**
1. Create analytic accounts **AA1** and **AA2**.
2. Create **Project A** linked to **AA1** only.
3. Create **Sale Order SO1** linked to **Project A**.
4. Create a vendor bill (or expense) whose AML is distributed between **AA1**
and **AA2**, where **AA2** is processed after **AA1**.
5. Validate the document.
**Expected behavior:**
The move line should still be mapped to **SO1** because **AA1** references
**Project A**.
**Actual behavior:**
The last processed analytic account (**AA2**) overwrites the previously found
project, causing the move line not to be linked to **SO1**.
* `project_per_accounts` stores **all** projects associated with each analytic
account instead of keeping only the last one.
* The project lookup preserves all valid project candidates instead of
overwriting previously found results during iteration.
* As a result, the method can resolve the related `sale.order` in more cases,
improving the overall accuracy of the mapping.
> **Note:** This change prevents valid project associations from being lost
> when multiple projects share an analytic account or when multiple analytic
> accounts are processed for the same move line.
**OPW:** 6294615
closes odoo#285042
X-original-commit: f7cb8ec
Signed-off-by: Maxime de Neuville (mane) <[email protected]>
It makes no sense to mention (Production) on pdp registration wizard when you are in prod mode closes odoo#285186 X-original-commit: 85189a0 Signed-off-by: Anton Romanova (roan) <[email protected]> Signed-off-by: Sven Führ (svfu) <[email protected]>
Getting the official Nilvera PDF on an invoice took three steps: wait for the status cron to run, wait for the invoice to be accepted by GİB, then click "Fetch Nilvera e-invoice PDF". The sync button next to the Nilvera status only refreshed the status and stopped there, so the user had to come back to the invoice later for the document itself. Fetch the PDF right after the status refresh for the invoices that came back successful, and drop the now redundant button from the form view. Pending invoices are filtered out beforehand so they are not polled a second time by the PDF routine. A commercial invoice does not stay on 'succeed'. Once GİB accepts it and the recipient answers, the status is overwritten with 'commercial_approved' or 'commercial_answered_automatically', and both are terminal successes. Group the three in a constant and use it at every PDF gate. In the PDF routine those invoices previously matched none of the status branches, so they were dropped without being fetched, reported pending or reported failed. 'commercial_rejected' stays out: a rejection is not a success, and its PDF is already fetched by the rejection handler. Also show the sync button when the status is "Unknown": e-archive invoices stay unknown until GİB generates its report at 20:00 GMT+3, which is precisely when the user wants to poll again. The status cron already covers that status, the view was the odd one out. task-6434404 closes odoo#284131 Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <[email protected]>
. Add a smart button that list the employees linked to the working schedule . Update Work_Resource smart button to include only the material resources . Show a “Shared Across Employees” warning when navigating from the Employee model, with an option to duplicate and edit the record for the current employee, automatically linking the newly created record to that employee. task-6106525 closes odoo#283506 Signed-off-by: Romain Carlier (romc) <[email protected]>
Neutralization archives the outgoing mail servers so a copy of a database cannot send anything, but it keeps smtp_user and smtp_pass on those records. The credentials therefore travel with every dump taken from a neutralized database, and an archived server holds a password that still authenticates against the real relay. Clear them alongside the deactivation: a neutralized database is meant to be copied and handed around, and it has no use for a credential it is not allowed to use anyway. The stub relay inserted right below keeps the fallback to the command-line SMTP settings blocked. closes odoo#285184 X-original-commit: 01e51b2 Signed-off-by: Krzysztof Magusiak (krma) <[email protected]>
Copying an image attachment already linked to another record could leave a redundant duplicate behind instead of reusing the existing one. opw-6463012 closes odoo#285136 X-original-commit: 8c9ba58 Signed-off-by: David Monjoie (dmo) <[email protected]> Signed-off-by: Mohammadmahdi Alijani (malj) <[email protected]>
Adding non-deductible fiscal position to taxes that were missing it in the data. task-6389423 closes odoo#285046 X-original-commit: f39946d Signed-off-by: Laurent Smet (las) <[email protected]> Signed-off-by: Petr Nazin (nape) <[email protected]>
Screen readers generally do not automatically announce that a link opens in a new tab when a user navigates to it, creating a potential barrier for non-visual users who may become disoriented if the current page is replaced without warning. Commit 2135b3c already fixed it, but this new approach follows more closely the Interaction framework. closes odoo#284949 Signed-off-by: Robin Lejeune (role) <[email protected]>
task-6341281 closes odoo#281743 Related: odoo/enterprise#127545 Signed-off-by: Yannick Tivisse (yti) <[email protected]>
Before this change, priorities in list views always displayed all stars, including empty ones. Records with low or no priority showed multiple empty stars, creating unnecessary visual clutter. After this change, only filled stars are displayed by default. Records with no priority show a single empty star, and hovering over the priority field reveals the complete set of stars. task-6365816 closes odoo#278023 Signed-off-by: Aaron Bohy (aab) <[email protected]>
Before this commit, four fields are written on records whose model never declares them: the only way to know a record holds them is the python that sends the value, or the component that reads it. This commit declares them with the other fields of their model. closes odoo#285622 Related: odoo/enterprise#129826 Signed-off-by: Alexandre Kühn (aku) <[email protected]>
Pre-validation errors were raised as a pop-up over the Send wizard, and `_l10n_jo_edi_send` short-circuited on the config errors, hiding the invoice-level ones until the configuration was complete. The invoice form carried a yellow banner and a developer-only "Download XML" link. Both error sources are now reported together by `_l10n_jo_edi_get_validation_errors` and shown as one danger alert on the wizard. The banner and the XML link are gone; a JoFotara rejection raises a RedirectWarning with an "XML" button. JoFotara fields move into their own group on the Other Info tab, the checkbox reads "To JoFotara (Demo)" in demo mode, and demo-mode invoices and POS receipts are watermarked. task-6321488 closes odoo#284481 Signed-off-by: Florian Gilbert (flg) <[email protected]>
Before this commit, clicking a notification of an inaccessible record in
the messaging menu opened no dialog, and the nightly build failed on
FAILED: [4/8] Tour access_inbox_records_tour -> Step .o_dialog
.o-mail-Message-body:text(Message in inaccessible record).
Element has not been found.
This happens because the messaging menu shows the message in a dialog
from the rejected promise of the action, while the action service
restores the controller displayed before the failure, and `_updateUI`
closes every dialog at the end of a restore. A dialog the user had
opened before the failed click is closed the same way.
This only shows since "[IMP] web, project: enable test_documents_full
eslint": the group check that commit moves to the end of a cog menu
`isDisplayed` ran on every view, and its await delayed the mount of the
controller, so the stack was still empty when the error arrived and the
error path restored nothing.
One solution could have been to keep the dialogs on every restore, but
the `soft_reload` client action is returned by a wizard and counts on
that close to dismiss it: the accounting onboarding then leaves its
"Accounting Periods" dialog open, and `account_tour` fails on its step
9. The added "soft_reload closes the dialogs" test pins it.
This commit fixes the issue by keeping the dialogs open when the restore
recovers from a controller error, as such a restore brings back the
controller that was already displayed. The option travels through a
private `_restore`, so the public `restore` keeps its signature.
https://runbot.odoo.com/odoo/error/946461
closes odoo#285058
Signed-off-by: Aaron Bohy (aab) <[email protected]>
Before this commit, the module cards shown in the uninstall wizard had a fixed height. That height was just enough for the app icon, so as soon as a card had a bit more text than expected, the text no longer fitted and a small scrollbar appeared inside the card. This is what happened in debug mode, where the technical name of the module is displayed under its title: the extra line did not fit and every card ended up with its own tiny scrollbar. This commit removes that fixed height. The cards now simply take the height they need, which is the same as before in the normal case, and slightly taller in debug mode instead of scrolling. task-6518056 closes odoo#285590 Signed-off-by: Adrien Dieudonné (adr) <[email protected]>
The workcenter planning method _get_first_available_slot used to build small candidate windows and repeatedly check them against existing workorder/leave intervals using the intersection of the candidate window with the busy times to detect conflicts. When a conflict was found, the candidate window would be shifted forward (or backward) to the end (or start) of the intersection and the process repeated until a free slot was found. This approach becomes disproportionately expensive when the candidate windows are small and the loop will then have to iterate many times. For example if the duration is 1 second and the busy intervals are hours long, the planner will have to do a full-merge of the intervals for each second of the busy interval. Therefore we introduce an Intervals.overlapping_with helper and use it to retrieve the entire busy interval that the conflict is inside of at once, allowing the planner to jump directly to the end (or start) of the busy interval instead of jumping only to the end of the conflict intersection (which may be very short when the duration is small). This reduces repeated full-merge work and prevents pathological slowdowns on short-duration planning. Now the full-merge of the intervals is done only once per busy interval instead of once per candidate window inside the busy interval. opw-5437256 closes odoo#285308 X-original-commit: b3a2736 Signed-off-by: Steve Van Essche <[email protected]> Signed-off-by: Krzysztof Magusiak (krma) <[email protected]>
Shop product lookup and facet computations used different searchable fields. In particular, facets searched raw website_description HTML, so CSS tokens could match a large part of a catalog even when the displayed result set was small. Use one shared field list for product lookup and facets, replace internal and raw website descriptions with the eCommerce description. opw-6391984 closes odoo#285045 X-original-commit: efdb9e3 Signed-off-by: Youssef El Fatihi (yoelf) <[email protected]>
Steps to reproduce: - Have a paid order with a product ordered once - Open the ticket screen, select that order and its line - Scan a product barcode with a keyboard-wedge scanner Issue: "Maximum Exceeded - The requested quantity to be refunded is higher than the ordered quantity. 6 is requested while only 1 can be refunded." When the line holds enough quantity no dialog is shown at all and a refund quantity taken from the barcode is silently set. Cause: A keyboard-wedge scanner types the barcode as a burst of keystrokes. The number buffer discards such bursts by waiting barcodeService.maxTimeBetweenKeysInMs before handling the keys it collected and dropping any batch of more than two, but only when its holder asks for it with `useWithBarcode`. TicketScreen never set the flag, so its buffer handled every keystroke on its own and the digits of the barcode reached _setToRefundDetail as the refund quantity. ProductScreen, OrderSummary and PaymentScreen all set it. Fix: Set `useWithBarcode: true` on the ticket screen number buffer. Since the keys are now handled with a delay, capture the buffer before the selected order or orderline changes, so that a keystroke is applied to the line that was selected when it was typed and not to the next one. opw-6465148 closes odoo#285456 X-original-commit: 4b8da7e Signed-off-by: Manu Vaillant (manv) <[email protected]> Signed-off-by: Pedram Bi Ria (pebr) <[email protected]>
**Problem:** Deleting one task of a recurrence suite ends the recurrence, but the tasks that stay behind keep the "Recurrent" option ticked. They look recurrent while no recurrence exists any more, so closing one of them never produces the next occurrence. **Steps to reproduce:** 1. Create a project with "Recurring Tasks" enabled 2. Create a task, tick "Recurrent" and mark it as done 3. Repeat on each generated occurrence until 3 or 4 tasks exist 4. Delete the last generated task 5. Open one of the tasks left in the suite **Current behavior:** The remaining tasks still show "Recurrent" ticked, but marking one as done creates no new occurrence and the recurring tasks smart button is empty. **Expected behavior:** Ending the recurrence should turn the "Recurrent" option off on every task that was part of it. **Cause of the issue:** `unlink` deletes the `project.task.recurrence` when the last task of the suite is removed, and `recurrence_id` is set to NULL on the other tasks by the database. Nothing resets their `recurring_task` boolean, so it stays `True` with no recurrence behind it. The two other places that end a recurrence, `write` and `action_unlink_recurrence`, already clear the flag on the whole suite. **Fix:** Aligning `unlink` with those two paths keeps a single meaning for `recurring_task`: it is only ticked while a recurrence actually exists. The suite has to be read before the recurrence is deleted, since the one2many is empty afterwards, and the tasks of the batch being deleted are left out so that no write lands on records that are about to disappear. opw-6425292 closes odoo#285468 X-original-commit: 17965a7 Signed-off-by: Xavier Bol (xbo) <[email protected]>
*: pos_online_payment_self_order Before this commit: - Self-orders with a total amount of zero are still redirected to the payment page, which was unnecessary. After this commit: - The payment step is now skipped for zero-amount self-orders, providing a smoother checkout flow. task-5106938 closes odoo#285088 X-original-commit: 3dcf412 Signed-off-by: David Monnom (moda) <[email protected]> Signed-off-by: Anantkumar Parmar (paan) <[email protected]>
Removes the dependency on test_cloc for base_import_module. closes odoo#282854 Signed-off-by: Krzysztof Magusiak (krma) <[email protected]>
Fix the top border of the dashboard buttons being cut off when selected. Also set a consistent width for all cart buttons using CSS. closes odoo#285700 Related: odoo/enterprise#129874 Signed-off-by: Victor Feyens (vfe) <[email protected]>
Before, whenever a user wanted to split move lines in different equal by size packages, user had to manually add new lines. Now by provividing the size of a package, it can be done automatically. This functionality takes into account current locations and preserves them for newly created move lines. Moveover, if several move lines are picked, it is impossible to split them together, only separately. Moveover, Package size can be calculated automatically by providing a Package Type. We check the UoMs that have this package type, and get the relative factor with the move UoM. If several UoMs have this package type, then the first one is picked. task-6034274 closes odoo#268294 Related: odoo/enterprise#123868 Signed-off-by: Steve Van Essche <[email protected]>
Currently, when a BoM contains components with child BoM, clicking `Compare BoMs` shows the immediate components only in list view. Users still need to open each BoM separately to edit nested components. This change will adds a new smartbutton that shows: - Components: number of components of the BoM - SubAssembly: number of sub BoMs inside the BoM Clicking the smartbutton opens the list of exploded components by following the hierarchy order, which provides a complete view of the BoM structure in a single place, allows user to update nested components and without navigating manually. About `forced_order_ids` context: ------------------------------------------------------------------------------ - The action uses a `forced_order_ids` context key to preserve the exploded hierarchy order instead of the model's default ordering when the list view performs a `search_fetch()`. - When opening the exploded list view -> product form -> BoM of that product, `forced_order_ids` should be reset to `False`. Otherwise, if the same child BoM is added multiple times, the BoM show repeated BoM lines. [video](https://drive.google.com/file/d/1M5k4XXGvr8KASzhBsRRByV3vepM8BBn1/view?usp=drivesdk) - When the user searches for a component through the search panel, `forced_order_ids` should filtered using the records returned by the super() call, which only contains the matched records. Without that filtering, the search would stop working correctly and would return all `forced_order_ids`. [video](https://drive.google.com/file/d/1De0IfTyPPTjk02rCOh2yJPHa9wI0Zi_W/view?usp=drivesdk) - It is also used to change the order of the fields in the search view, because when the list is opened from the `Components/SubAssembly` smartbutton, the component search should be on top, in other cases the BoM search should be on top. Ent PR odoo/enterprise#120254 task-6247051 closes odoo#267605 Related: odoo/enterprise#120254 Signed-off-by: Steve Van Essche <[email protected]>
The framework provides a wrapper to compose SQL queries safely: as long as the format string is written in the source, the resulting object is safe from injection, and the parameters of nested fragments are merged automatically. Convert the remaining queries in our scope to use it, where applicable. The generated queries and their parameters are unchanged. task-6297256 closes odoo#284155 Signed-off-by: Victor Feyens (vfe) <[email protected]>
This feature was added as a dedicated module because it was added in stable version 19.3 . We can now merge it directly into track module where it belongs. Task-6515688 closes odoo#285267 Related: odoo/upgrade#11164 Signed-off-by: Thibault Delavallee (tde) <[email protected]>
*= l10n_fr_pdp, l10n_account_edi_ubl_cii_tests. Refactoring of the export of factur-x. The export now relies on a dict of nodes, and uses the function dict_to_xml to generate the xml instead of relying on a qweb template. task-5999127 closes odoo#284130 X-original-commit: 265a3e1 Signed-off-by: Antoine Boonen (aboo) <[email protected]>
The customer name is written in `floating_order_name` which is never passed to the preparation receipt in self order. This commit fixes it. closes odoo#285374 X-original-commit: a013ec4 Signed-off-by: David Monnom (moda) <[email protected]> Signed-off-by: Louis Travaux (lotr) <[email protected]>
Change `optimize_full` to reset the user-provided search domain. This way, we don't propagate the context when a search is performed inside `Field.search` methods. X-original-commit: cc54237 Part-of: odoo#285678 Signed-off-by: Raphael Collet <[email protected]> Signed-off-by: Krzysztof Magusiak (krma) <[email protected]>
When the security domain uses a many2one field that needs the `search_domain` context, the field itself might not be present in the user-given domain. When this happens, we assumed to search on all records which is too much in the case of attachments. The practical example is product.document where a simple fetch could not be done anymore on databases having a lot of attachments. opw-6486492 closes odoo#285678 X-original-commit: 3d30f91 Signed-off-by: Raphael Collet <[email protected]> Signed-off-by: Krzysztof Magusiak (krma) <[email protected]>
Go to `/my/tasks`. The search on milestones is really slow. Performance improvement for a portal user: - before: ~3.6s - after: ~60ms For portal users, complex record rules require joining the `project` table. Because the query includes a `limit=1`, the postgresql query planner assumes it will find a matching row almost immediately. Hoping for a "fast exit", it chooses to sequentially scan the `project_id` index to perform a Merge Join. However, if it doesn't find a match early on, it ends up scanning the entire index, resulting in a massive slowdown. We update the `search_count` constraint from `limit=1` to `limit=80`. By increasing the limit, we alter postgresql's cost estimation. The planner can no longer assume a cheap "fast exit" is guaranteed, which forces it to abandon the flawed Merge Join strategy. Instead, it correctly evaluates the query and chooses the index on `milestone_id` to retrieve the records. task-6373729 closes odoo#285754 X-original-commit: e4cadb4 Signed-off-by: Piryns Victor (pivi) <[email protected]> Signed-off-by: Lucas Lefèvre (lul) <[email protected]>
Steps to reproduce: - Enable presets on a restaurant PoS and tick "Amount of Guests" on the preset used for tables - On device A, open a table and enter the number of guests - On device B, open the same table Issue: Device B pops the guest count numpad again, even though the guest count was already entered on device A. Cause: ensureGuestCustomerCount guards the popup on order.uiState.guestSetted. uiState is only serialized to IndexedDB (SERIALIZED_UI_STATE_PROP, used by serializeForIndexedDB); it is never sent to the server, so the flag is local to one browser and a second device always considers the guest count as not yet asked. Fix: Seed that flag in initState, which is called once per record and only when there is no stored uiState to restore: an order that already has a server id was created on another device, which went through the guest flow for the preset it carries. A reload still restores the real flag, and an order switched to a guest preset afterwards is still asked. opw-6470180 closes odoo#285670 X-original-commit: 9586c41 Signed-off-by: Manu Vaillant (manv) <[email protected]> Signed-off-by: Pedram Bi Ria (pebr) <[email protected]>
pyOpenSSL 24.3.0 deprecated passing its own X509/PKey objects to Context.use_certificate()/use_privatekey(), and started accepting cryptography objects instead. Odoo pins pyopenssl 24.1.0, but the distro builds run the version shipped by the OS: since the test added by f0fb287 covers that path, they now add a warning in the logs. Make the older versions accept the cryptography objects as well, so that the callers can always pass those, whichever version is installed. Reference: pyca/pyopenssl@b0cb4b4 This fix is based on https://github.com/odoo/odoo/blob/a2b4f618328f3ce3f654fd2c1ee4410365706a7e/odoo/addons/base/models/ir_mail_server.py#L34-L46 Fix Runbot #944176 closes odoo#285676 X-original-commit: c9f92c9 Signed-off-by: Julien Castiaux (juc) <[email protected]> Signed-off-by: Louis Gobert (loug) <[email protected]>
Access tokens can only be matched by exact value. Accept `in` and `not in` operators. Task-6481193 closes odoo#285796 X-original-commit: b488871 Signed-off-by: Denis Ledoux (dle) <[email protected]> Signed-off-by: Thomas Lefebvre (thle) <[email protected]>
**Problem:**
Opening a Project Update activity from the activity menu (the clock icon in the
systray) lists every project update of every user, instead of the ones carrying
the current user's activities.
**Steps to reproduce:**
1. Schedule an overdue activity on a project update
2. Have a colleague create another project update with no activity
3. Click the clock icon in the systray
4. Under "Project Update", click the "Late" count
**Current behavior:**
The list opens unfiltered and shows all project updates, including the ones of
other users and the ones carrying no activity at all.
**Expected behavior:**
The list shows only the updates carrying the user's own activities, restricted
to the bucket that was clicked.
**Cause of the issue:**
The activity menu never builds a "my activities" domain. `openActivityGroup` in
`mail/static/src/core/web/activity_menu.js` narrows the generic act_window it
opens purely through context keys — `search_default_filter_activities_my` plus
`search_default_activities_overdue` / `_today` / `_upcoming_all` — and the only
domain it forwards comes from `_get_activity_groups`, which is limited to
`[('active', 'in', [True, False])]`. A `search_default_<name>` key is resolved
against a filter of that name in the model's search view, and is silently
dropped when no such filter exists. `project.update`'s search view never
declared them, so every key the menu sends is discarded and the action opens on
an empty domain.
**Fix:**
`project.project` and `project.task` — the addon's two other
`mail.activity.mixin` models — already declare this block of invisible activity
filters, as does every other model reachable from the activity menu. Declaring
them on `project.update` is what makes the menu's context keys resolvable, and
keeps the model consistent with the rest of the codebase instead of
special-casing `project.update` on the client side.
opw-6416397
closes odoo#285840
X-original-commit: 9c4c797
Signed-off-by: Xavier Bol (xbo) <[email protected]>
Issue: A warning `IndexError: tuple index out of range` is logged on RunBot when upgrading from 18.0 to 19.0 for employees without any version Cause: `_get_version` on `hr.employee` falls back to `versions[0]` when no version matches the given date But if the employee has no versions at all, `versions` is empty and `versions[0]` raises an `IndexError` Steps to reproduce: - Create a database with `hr_attendance` installed in 18.0 - Upgrade to 19.0 Before the fix, a warning is logged during the upgrade Notes: An employee without any version is a transient state during upgrade `hr/saas~18.4.1.1/end-migrate.py` backfills a version for every employee still missing one (`current_version_id IS NULL`) once the whole upgrade chain is done Since it only runs at the very end, an employee can still be found without a version by earlier steps (e.g. modules reloading their demo data), which is when this warning was logged Confirmed on an upgraded RunBot database that employees without a version before the upgrade do end up with one once fully completed runbot-241187 closes odoo#285807 X-original-commit: 5c58e71 Signed-off-by: Romain Carlier (romc) <[email protected]>
…ining_leaves. Steps to reproduce: 1. Go to Time Off > Configuration > Time Off Types. 2. Open any Time Off Type and click on the "Time Off" smart button. 3. Click on "New" and select a "Time Off Type". 4. A TypeError is raised. Reason: The operator 'op' retrieved from 'PY_OPERATORS' expects two arguments. However, only the field value was being passed causing a TypeError during evaluation. Solution: Pass 'value' as the second argument to 'op' inside the 'is_valid' function. Task: 6522318
aski97
force-pushed
the
master-hr-traceback_time_off_type-vibel
branch
from
September 1, 2026 11:34
661fccb to
0fc1f57
Compare
arpi-odoo
force-pushed
the
master-hr-onboarding-vibel
branch
from
September 1, 2026 11:57
57a0e0e to
b692efe
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Steps to reproduce:
Reason:
The operator 'op' retrieved from 'PY_OPERATORS' expects two arguments. However, only the field value was being passed causing a TypeError during evaluation.
Solution:
Pass 'value' as the second argument to 'op' inside the 'is_valid' function.
Task: 6522318