pacioli: Un marcador de consentimiento de envío autorizaba la cancelación de documentos preexistentes designados por el invocador

Impacto

El control de consentimiento en la capa de documentos de pacioli-guard requiere un marcador generado por un humano, de un solo uso, vinculado al documento y vinculado a la acción antes de que una credencial con API Key Scope.require_consent pueda enviar o cancelar un documento. Debido a que ERPNext realiza escrituras adicionales en documentos como consecuencia de una acción gobernada, se permite que las acciones anidadas "aprovechen" (ride) el consentimiento establecido por la acción contenedora en lugar de requerir un marcador propio.

El predicado de aprovechamiento devolvía true para cada cancelación, sin importar qué acción autorizaba el marcador contenedor. El aprovechamiento nunca alcanza consent_verdict, que es donde se aplica la vinculación entre el marcador y la acción. En consecuencia: cualquier Document.cancel() ejecutada dentro de una acción que había establecido consentimiento alcanzaba docstatus = 2 sin marcador, sin verificación de vinculación de acción, sin consumo de uso único y sin registro de auditoría de denegación.

Esto es accesible con el permiso exacto que un operador asigna documentadamente al intermediario, y la identidad del documento cancelado está controlada por el invocador:

• Sales Invoice.on_submit (sales_invoice.py:507) llama incondicionalmente a process_asset_depreciation(), alcanzando depreciate_asset_on_sale (:1508-1516).
• Esto itera las filas de artículos de la factura y llama a frappe.get_doc("Asset", d.asset). Sales Invoice Item.asset es un Link escribible simple sin read_only y sin fetch_from, por lo que el invocador lo proporciona en el cuerpo de la solicitud. La validación que lo restringiría se encuentra detrás de if d.is_fixed_asset: (:428-429), un campo configurado por el servidor.
• La cadena alcanza depreciation.py:481 y luego asset_depreciation_schedule.py:215-217, que llama a current_schedule.cancel() en un docstatus == 1, enviable Asset Depreciation Schedule a través del ciclo de vida del documento (solo should_not_cancel_depreciation_entries está configurado, no ignore_validate, por lo que before_cancel sí se ejecuta y el aprovechamiento fue lo que lo admitió).

Por lo tanto, un solo marcador que autorizaba submit Sales Invoice X cancelaba un documento enviado que el humano nunca vio ni aprobó. Cancelar dicho documento revierte su efecto contable en el libro mayor.

El mismo patrón existe bajo permisos más amplios, por ejemplo Unreconcile Payment.on_submit (unreconcile_payment.py:59-64), que recorre una tabla secundaria que llena el invocador y alcanza accounts/utils.py:857/:859 gain_loss_je.cancel() en asientos de diario enviados.

Quiénes están afectados

Únicamente los entornos que optaron por el control de consentimiento: la credencial debe poseer un API Key Scope con require_consent activado. pacioli-guard es inerte para entidades principales sin dicha concesión, y el límite base de alcance de credenciales (auth_hooks) no se ve afectado por este problema.

El control de consentimiento en la capa de documentos se publicó por primera vez en 0.9.6, que es la única versión publicada en el rango afectado.

Riesgo residual declarado

Bajo una cancelación gobernada, una cancelación en cascada de un documento preexistente todavía se aprovecha. Esto es fundamental para revertir acciones (una cancelación de factura común hace que ERPNext cancele las notas de crédito/débito y los diarios generados mediante accounts_controller.py:2001-2005) y no puede restringirse sin una señal de que la cancelación en cascada es consecuencia específica del documento contenedor. Sin embargo, esa justificación no cubre todo lo admitido: al menos una instancia es dirigida por el invocador de la misma forma que el problema solucionado aquí, Asset Repair.on_cancel (asset_repair.py:215-222), que cancela un Serial and Batch Bundle nombrado mediante un enlace que el invocador completa en una tabla secundaria. pacioli-guard tampoco detecta escrituras que establecen flags.ignore_validate o que omiten por completo el ciclo de vida del documento (SQL directo, escrituras de campos con db_update/db_set); estos residuales están documentados por el proyecto y se mantienen sin cambios.

Créditos

Descubierto mediante una revisión interna el 2026-07-28 que rastreó el predicado contra el código fuente de Frappe 16.28.0 y ERPNext v16 en lugar de la documentación del proyecto. El comentario anterior en el código aseguraba que no se conocía tal mecanismo; dicha afirmación se redactó sin el barrido de código correspondiente.