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

State: Killed

PR State: open

PR Author: David Tran

PR Author Email:

PR: #1290

Committer: David Tran

Committer Email: david.tran@tvtmarine.com

Commit: f204e4fb2d9e4a010c2386d21b9ef777d17c13cc

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 d5acfaf89b7beffa9ff6c3289432ee0507e55683)
                                            

Branch: 19.0

Age:

Up-time: Not finished