Monday, September 2, 2024
5 changes · saas-17.4
Resolved issues and error corrections
Job application forms now avoid adding an internal warning message to applicant notes in the first place. This prevents custom website form fields from being accidentally removed, preserving important candidate information for recruiters.
Original PR description
Before this commit, the commit 5045bd712f21e2f92e97ab9cb8a7221e0340ca54 avoid displayed the warning message in the chatter and alters the description field of applicant model to remove the warning message as well. The problem is the update on the description field does not take into account the custom fields added to the website form and also remove them. This commit makes sure the warning message is not added in the chatter and description instead of letting the warning message in the description and erased it afterwards.
Fixes an issue where resumed restaurant orders could appear paid at the register but remain as drafts in the back office. The update keeps the table and order selection aligned, improving order synchronization and preserving access to tip collection when needed.
Original PR description
Steps to reproduce: 1. Open a session for the restaurant config. 2. Create an order without payment in 3 tables. 3. Return to the 3rd table and pay the order. 4. When in receipt screen, you're…
Steps to reproduce: 1. Open a session for the restaurant config. 2. Create an order without payment in 3 tables. 3. Return to the 3rd table and pay the order. 4. When in receipt screen, you're offered a choice to "Resume Order" or create a "New Order". Choose "Resume Order". 5. The screen will have a search word by default without showing anything, however, there is an automatically selected order. Load that order by clicking "Load". 6. ISSUE: Pay the order. But it remained draft if you check it from the backend. The solution is to make sure that when resuming to an order, we also set the table linked to it as the `selectedTable`. We should run the `_setOrder` override if the session is restaurant and the selected order is linked to a table. Because of the mismatch of the paid order and the selected order, the orders-to-sync are not computed properly (see `getPendingOrder` which depends on the selected table). Now that `setTable` is called when selecting an order, the order in TipScreen is not properly selected because it's already ".finalized". However, the cashier should still be able to access it to capture tips later, thus, we also need to adapt setting of order in `setTable` to include tables orders that are in TipScreen. This commit also contains the following change: - `isResumeVisible` should be true if there is at least one order to select. TASK-ID: 4105312 Backport of: https://github.com/odoo/odoo/pull/176341
Point of Sale session closing once again shows the detailed list of cash in and cash out transactions instead of only a total. This helps store staff review cash movements more clearly before closing a session, while removing an unnecessary total-only display.
Original PR description
This commit reverts the previous change where the detailed list of cash in/out transactions was removed from the session closing screen, leaving only the total amount. The total amount display will also be removed as it was not necessary according to the updated requirements. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Selecting a Mercado Pago payment method in Point of Sale no longer immediately marks the transaction as cancelled before it is sent. This fixes a checkout issue so stores using Mercado Pago can properly initiate payment requests and avoid blocked sales.
Original PR description
Currently, when selecting the Mercago Pago payment method, the payment is directly shown as being cancelled, even though is wasn't even sent in the first place. Steps to reproduce: ------------------- * Go to the **Point of Sale** App * Under **Configuration** select **Payment Mehods** * Create a new payment method and configure it with Mercado Pago * Under **Configuration** select **Settings** * Add the payment method to the shop * Open shop session * Create an order and go to pay it * Select the Mercado Pago payment method created > Observation: Transaction cancelled Why the fix: ------------ When adding selecting the payment method we would calll `send_payment_request` which would fail at multiple location because we were trying to retreive a property from `underfined`. opw-4142677
The point of sale now correctly lowers the cart price when a product variant has a negative price extra. This prevents customers from being overcharged and keeps in-store pricing aligned with product setup.
Original PR description
In the point of sale products with variants with negative price extra have their price computed as if they have no price extra. Steps to reproduce: 1. Create a product with variants of type "never create" and give a negative price extra to one of the variants 2. Observe that adding that product in the cart will show that the price is the whole price, and not the expected lower price. Task: 4148183 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr