ERPNext Strict User Permissions Hides Every Purchase Invoice (And Asset and Shipment Are Still Broken)

I am Manoj, ERP implementation lead at Mith Tech in Bengaluru. We enable Strict User Permissions on most of the ERPNext implementations we run for multi-company groups, because the alternative — blank link fields quietly counting as "allowed" — is not something an auditor accepts. That makes this class of bug our problem rather than a curiosity, and it is why we went and audited every doctype in the codebase rather than stopping at the one that got patched.

What actually happens in the query

The permission engine builds list-view filters in DatabaseQuery.add_user_permissions(), in frappe/model/db_query.py. Three properties of that function combine into the bug, and all three are working as designed:

1. It iterates every Link field on the doctype, via self.doctype_meta.get_link_fields() — not just the field you think of as the scoping one. A User Permission on Company with Apply to All Document Types populates user_permissions["Company"], so every Link-to-Company field on the doctype produces a condition.
2. It joins those conditions with AND. Every non-exempt Link-to-Company field must match. There is no "at least one" mode.
3. Strict mode deletes the escape hatch. With strict off, each condition is prefixed with ifnull(field, '') = '' or, so a blank field passes. With strict on, that disjunct is simply not emitted.

Only ignore_user_permissions on the field itself makes the loop skip a field. That single flag is the whole surface area of the fix.

((
  (`tabPurchase Invoice`.`company` in ('XYZ Ltd'))
  and
  (`tabPurchase Invoice`.`represents_company` in ('XYZ Ltd'))
))

With strict on and a permission of Allow = Company, For Value = 'XYZ Ltd', Apply to All Document Types = 1, the list query gets:

((
  (`tabPurchase Invoice`.`company` in ('XYZ Ltd'))
  and
  (`tabPurchase Invoice`.`represents_company` in ('XYZ Ltd'))
))

represents_company is NULL on every purchase invoice from an ordinary external supplier, and NULL in ('XYZ Ltd') is never true. Zero rows. The form view is slightly more honest: open a specific invoice by URL and has_user_permission() produces "You are not allowed to access this Purchase Invoice record because it is linked to Company 'empty' in field Represents Company." That message is the only place the system tells you what happened — and nobody reaches it, because the list view gave them nothing to click.

Why represents_company is blank

represents_company exists for inter-company transactions: when one company in your group buys from or sells to another company in the same instance. On the Supplier master it is gated behind is_internal_supplier, and — notably — Supplier's copy already carried ignore_user_permissions: 1. On Purchase Invoice it is a fetched mirror ("fetch_from": "supplier.represents_company"), typed in Python as DF.Link | None.

So for every ordinary external supplier the field is legitimately NULL, and in a typical install roughly all purchase invoices have it blank. It is an identity field, not a scoping field. The scoping field is company. That distinction is precisely what ignore_user_permissions is for, which is why the one-line fix is correct rather than a hack — and why the accompanying "read_only": 1 makes sense for a value nobody should type by hand.

Our finding: the fix does not generalise

Because the maintainers chose a per-field flag over a framework change, the correctness of the whole system now depends on every doctype having the flag set correctly on every optional link. So we checked. We pulled the full ERPNext v15.116.0 source tarball, parsed all 659 non-child DocType JSON files, and listed every doctype with more than one Link → Company field along with each field's ignore_user_permissions value. Then we re-verified the interesting ones against v15.119.0, the latest release at the time of writing.

Eleven doctypes have more than one Link to Company. Nine are fine. Two are not.

((
  (`tabPurchase Invoice`.`company` in ('XYZ Ltd'))
))

Asset. asset_owner_company is still ignore_user_permissions: 0. It only appears when asset_owner == "Company", so for any asset owned by a supplier or customer — third-party, leased, consignment — it is NULL. In strict mode with an Apply-to-All Company permission, those assets vanish from the Asset list exactly the way purchase invoices did. This is not speculation: the reporter of #57072 hit it in production and said so in the thread on 2026-05-06, and the comment that proposed the ignore_user_permissions approach explicitly named asset_owner_company alongside represents_company. Only the Purchase Invoice half shipped. As of August 2026 there is no released fix.

Shipment. pickup_company and delivery_company are both conditional (pickup_from_type == 'Company' and delivery_to_type == 'Company') and both ignore_user_permissions: 0. On a normal outbound shipment delivery_company is blank; on an inbound one pickup_company is blank. The engine's behaviour is verified and the field metadata is verified, so the Shipment list should go empty for restricted users in both directions.

The generalisable rule is the real takeaway, and it is not about Company at all: Strict User Permissions with Apply to All Document Types is only safe on a doctype where every non-exempt Link field pointing at the restricted doctype is always populated. Any optional or conditional second link to the same target silently ANDs the list to zero. Warehouse, Cost Center, Project, Territory and Branch have the identical failure mode wherever a doctype carries two links to them.

There is precedent for this being handled one field at a time rather than structurally: v15.116.0 and v16.27.0 also shipped "ignore user permissions for link fields having link to Account and Cost Center" on the Company doctype. Same disease, different link target, separate patch.

Diagnose, fix, verify

# bench --site yoursite console
# Which doctypes will strict mode silently empty?

import frappe

print("apply_strict_user_permissions =",
      frappe.get_system_settings("apply_strict_user_permissions"))

# 1. User Permissions on Company that apply to all doctypes
rows = frappe.get_all(
    "User Permission",
    filters={"allow": "Company"},
    fields=["user", "for_value", "applicable_for",
            "apply_to_all_doctypes"],
)
for r in rows:
    scope = r.applicable_for or "ALL DOCTYPES"
    print(f"{r.user:<32} {r.for_value:<20} -> {scope}")

# 2. Every doctype with >1 non-exempt Link to Company
for dt in frappe.get_all("DocType",
                         filters={"istable": 0, "issingle": 0},
                         pluck="name"):
    try:
        meta = frappe.get_meta(dt)
    except Exception:
        continue

    links = [f for f in meta.get_link_fields()
             if f.options == "Company"]
    enforced = [f.fieldname for f in links
                if not f.ignore_user_permissions]

    if len(enforced) > 1:
        print(f"AT RISK  {dt:<30} {enforced}")

# 3. How many rows actually have the second field blank?
print(frappe.db.sql("""
    select count(*) from `tabPurchase Invoice`
    where docstatus < 2
      and ifnull(represents_company, '') = ''
"""))

Choosing between the four options

A fifth suggestion appears in the issue thread and is worth heading off: a custom permission_query_conditions hook. It reads like a fix and is not one. Conditions returned by that hook are ANDed onto the user-permission match conditions, so a hook can only narrow the result set, never widen it. It cannot rescue an empty list on its own.

Readiness checklist

One last thing worth saying plainly: an empty list is not always a permission problem. If your accounts team is staring at a Purchase Invoice list that looks wrong rather than empty, the cause is more often reconciliation state than row-level security — see the payment reconciliation automation guide for that side of it. Rule out strict mode first, because it is the one cause that produces zero rows and zero explanation.

The Purchase Invoice half of this is closed, and if you are on a current release you already have it. The part that is not closed is the assumption underneath it: that a permission model enforced by per-field flags stays correct as doctypes and custom fields accumulate. Asset and Shipment are the two live counter-examples in the standard app today, and the next one will be a Link-to-Company custom field somebody adds to a transactional doctype on your own instance. Audit before you tick the box, not after someone reports an empty list.