Name: [FIX] pos_loyalty, sale_loyalty: backport two upstream loyalty fixes

State: Failed finished in 83m

PR State: open

PR Author: David Tran

PR Author Email:

PR: #1290

Committer: David Tran

Committer Email: david.tran@tvtmarine.com

Commit: c855d12ce8bceca251d4c4707fe9d0fa67df3a97

Description:

                                            [FIX] sale_loyalty: allow invoicing-only users to open sale orders

Steps to reproduce:
1. Create a user in the Invoicing group (account.group_account_invoice)
   only, without any Sales group.
2. As that user, open any sale order form (draft or confirmed with
   loyalty history).

Issue:
The form never opens; the client raises "You are not allowed to
access 'Loyalty Coupon' (loyalty.card) records". This blocks a user
who already has read/write access to sale.order in core, via the
access_sale_order_invoicing_payments rule in sale's own security
CSV, from doing their job.

Cause:
Two non-sudo reads in the sale.order extension hit loyalty models
that are restricted to the Sales groups: the gift card stat button
count queries loyalty.card directly, and the loyalty summary looks
up the coupon point name via coupon_point_ids.coupon_id without the
sudo already used one line above for loyalty.history.

Fix:
Gate the gift card count query behind a has_access('read') check, so
a user without access simply sees a zero count (the stat button
stays hidden), matching the has_access guard sale.order already uses
in _create_invoices(). Read the coupon point name through sudo(),
consistent with the loyalty.history read beside it, since the
loyalty summary is meant to be visible to anyone who can already
read the order.

Signed-off-by: David Tran <david.tran@tvtmarine.com>
(cherry picked from commit 84536036b471ced708a149c40c7f01dbf9a2d2fc)
                                            

Branch: 19.0

Age:

Up-time: