personalReadOnly: true (#6369) correctly makes the personal surface see-only in most places: the generated
<Entity>MyController refuses create/update/delete, and the my list has no New button.
The my form still renders an Add button for each composition-child panel:
<button x-h-button data-variant="primary" data-size="sm" @click="addChild(child)">
e.g. gen/<module>/views/my/Payslip-form.html offers Add for the PayslipLine panel although
PayslipLineMyController returns 403 for every write (children correctly inherit the read-only scope).
So it is safe - the server refuses - but it is an affordance that always fails, on exactly the surfaces
(a payslip, a leave-balance account) where the point is that the owner may look and not author. The Save and
Delete triggers are already suppressed on the same page; only the child panel's Add leaks.
Ask: suppress the child Add button when the personal surface is read-only.
personalReadOnly: true(#6369) correctly makes the personal surface see-only in most places: the generated<Entity>MyControllerrefuses create/update/delete, and the my list has no New button.The my form still renders an Add button for each composition-child panel:
e.g.
gen/<module>/views/my/Payslip-form.htmloffers Add for the PayslipLine panel althoughPayslipLineMyControllerreturns 403 for every write (children correctly inherit the read-only scope).So it is safe - the server refuses - but it is an affordance that always fails, on exactly the surfaces
(a payslip, a leave-balance account) where the point is that the owner may look and not author. The Save and
Delete triggers are already suppressed on the same page; only the child panel's Add leaks.
Ask: suppress the child Add button when the personal surface is read-only.