Re: [PR] refactor: migrate system buttons to app-button [fineract-backoffice-ui]

[via GitHub]

github-actions[bot] commented on PR #596:
URL: 
https://github.com/apache/fineract-backoffice-ui/pull/596#issuecomment-5788984719

   <!-- e2e-report-backend -->
   ### E2E — real Fineract
   ## 🎭 E2E Tests
   
   **❌ 1 failing** — 77 passed · 1 failed · 0 skipped · 2 flaky, across 24 spec 
files in 7m 12s.
   
   ### ❌ Failures
   
   - **Screens added for platform parity › a report definition can be created, 
edited and deleted; a core one cannot** — `parity-screens.spec.ts`
     - Error: expect(locator).toHaveAttribute(expected) failed
   
   ### ⚠️ Passed on retry
   
   Green overall, but these needed more than one attempt — the shape a flake 
takes.
   
   - **Batch API enclosingTransaction semantics against Fineract › does not 
roll back the earlier steps when enclosingTransaction is false and a later step 
fails** — `batch-api-operations.spec.ts` (1 retry/retries)
   - **Loan product accounting › a cash-accounting product is configured, 
round-trips on edit, and posts to the ledger** — 
`loan-product-accounting.spec.ts` (1 retry/retries)
   
   ### By spec file
   
   | Spec | ✅ | ❌ | ⏭️ | 🔒 | Time |
   | --- | ---: | ---: | ---: | ---: | ---: |
   | backend.setup.ts | 3 | 0 | 0 | 0 | 6.1s |
   | batch-api-operations.spec.ts | 5 | 0 | 0 | 0 | 30.8s |
   | center-servicing.spec.ts | 2 | 0 | 0 | 0 | 17.1s |
   | client-legal-form-search.spec.ts | 1 | 0 | 0 | 0 | 4.9s |
   | client-transfer.spec.ts | 4 | 0 | 0 | 0 | 43.0s |
   | deposit-account-servicing.spec.ts | 3 | 0 | 0 | 0 | 24.7s |
   | deposit-product-configuration.spec.ts | 3 | 0 | 0 | 0 | 14.9s |
   | group-membership.spec.ts | 3 | 0 | 0 | 0 | 44.8s |
   | loan-account-actions.spec.ts | 3 | 0 | 0 | 0 | 22.1s |
   | loan-charge-off.spec.ts | 2 | 0 | 0 | 0 | 22.1s |
   | loan-product-accounting.spec.ts | 1 | 0 | 0 | 0 | 48.1s |
   | loan-servicing.spec.ts | 2 | 0 | 0 | 0 | 19.6s |
   | login.spec.ts | 4 | 0 | 0 | 0 | 6.5s |
   | **parity-screens.spec.ts** | 7 | 1 | 0 | 0 | 59.0s |
   | rbac-backend-restricted-user.spec.ts | 7 | 0 | 0 | 0 | 34.7s |
   | rbac-multi-permission.spec.ts | 9 | 0 | 0 | 0 | 58.4s |
   | full-demo.spec.ts | 1 | 0 | 0 | 0 | 1m 6s |
   | loan-lifecycle.spec.ts | 4 | 0 | 0 | 0 | 2m 7s |
   | loan-schedule-type.spec.ts | 3 | 0 | 0 | 0 | 36.6s |
   | report-parameter-backend.spec.ts | 4 | 0 | 0 | 0 | 23.4s |
   | savings-transaction-correction.spec.ts | 1 | 0 | 0 | 0 | 6.9s |
   | share-account-servicing.spec.ts | 2 | 0 | 0 | 0 | 18.5s |
   | share-product-accounting.spec.ts | 1 | 0 | 0 | 0 | 24.1s |
   | teller-cash-management.spec.ts | 2 | 0 | 0 | 0 | 37.0s |
   
   <details>
   <summary><b>All 78 tests</b> — click to expand</summary>
   
   **`backend.setup.ts`**
   
   - ✅ seed backend reference data — `1.8s`
   - ✅ seed backend reference data — `2.1s`
   - ✅ seed backend reference data — `2.3s`
   
   **`batch-api-operations.spec.ts`**
   
   - ✅ Batch API Operations against Fineract › runs the sample batch scenario — 
create client, create loan, add and read back a charge — `5.9s`
   - ✅ Batch API Operations against Fineract › shows a parse error instead of 
submitting when the batch input is not valid JSON — `6.1s`
   - ✅ Batch API enclosingTransaction semantics against Fineract › rolls back 
the earlier steps when enclosingTransaction is true and a later step fails — 
`5.7s`
   - ✅ Batch API enclosingTransaction semantics against Fineract › does not 
roll back the earlier steps when enclosingTransaction is false and a later step 
fails — `9.0s` _(retried 1×)_
   - ✅ Batch API Operations on a mobile viewport against Fineract › the sample 
batch scenario is reachable and works by touch at mobile width — `4.1s`
   
   **`center-servicing.spec.ts`**
   
   - ✅ Center servicing › a center is activated, staffed and given a group — 
`12.3s`
   - ✅ Center servicing › notes are recorded against the center — `4.8s`
   
   **`client-legal-form-search.spec.ts`**
   
   - ✅ Client list: legal form filtering › an entity client appears in the main 
client list — `4.9s`
   
   **`client-transfer.spec.ts`**
   
   - ✅ Client transfer between offices › a proposed transfer is held until the 
destination accepts, and then the client moves — `10.5s`
   - ✅ Client transfer between offices › a rejected transfer leaves the client 
on hold, and withdrawing is the way back — `11.8s`
   - ✅ Client transfer between offices › a client can be transferred in one 
step when the user may act for both offices — `9.6s`
   - ✅ Client staff assignment › an officer can be assigned and then removed — 
`11.1s`
   
   **`deposit-account-servicing.spec.ts`**
   
   - ✅ Term deposit account servicing › an account is approved, activated and 
closed before maturity — `10.2s`
   - ✅ Term deposit account servicing › a deposit is recorded, listed, and 
reversed without leaving the list — `9.1s`
   - ✅ Term deposit account servicing › an application can be rejected instead 
of approved — `5.5s`
   
   **`deposit-product-configuration.spec.ts`**
   
   - ✅ Deposit product configuration › a fixed deposit product survives being 
edited — `5.3s`
   - ✅ Deposit product configuration › a recurring deposit product can be 
created at all — `4.1s`
   - ✅ Deposit product configuration › a savings product carries its accounting 
configuration — `5.6s`
   
   **`group-membership.spec.ts`**
   
   - ✅ Group membership and lifecycle › a group is activated, staffed, given 
members and a committee, then emptied — `19.0s`
   - ✅ Group membership and lifecycle › notes are recorded against the group 
and can be removed again — `7.6s`
   - ✅ Group membership and lifecycle › an empty group is closed with a reason, 
and a group with members is refused — `18.2s`
   
   **`loan-account-actions.spec.ts`**
   
   - ✅ Loan account lifecycle actions › new action menu items appear only for 
active loans — `6.8s`
   - ✅ Loan account lifecycle actions › undo disbursal shows a confirm dialog 
and reverts the loan to Approved — `7.8s`
   - ✅ Loan account lifecycle actions › write off requires confirmation and 
moves the loan out of Active status — `7.6s`
   
   **`loan-charge-off.spec.ts`**
   
   - ✅ Loan servicing commands › charges a loan off through the UI and reverses 
it — `9.4s`
   - ✅ Loan servicing commands › records a goodwill credit through the shared 
transaction form — `12.7s`
   
   **`loan-product-accounting.spec.ts`**
   
   - ✅ Loan product accounting › a cash-accounting product is configured, 
round-trips on edit, and posts to the ledger — `48.1s` _(retried 1×)_
   
   **`loan-servicing.spec.ts`**
   
   - ✅ Loan servicing: notes and transaction adjustment › notes can be added 
and removed, with a confirm dialog on delete — `8.6s`
   - ✅ Loan servicing: notes and transaction adjustment › a repayment 
transaction can be viewed and adjusted with a corrected amount — `11.0s`
   
   **`login.spec.ts`**
   
   - ✅ Login › login page displays correctly — `1.5s`
   - ✅ Login › login form has required fields — `1.4s`
   - ✅ Login › submit button is disabled when form is empty — `2.2s`
   - ✅ Login › submit button is enabled when form is filled — `1.3s`
   
   **`parity-screens.spec.ts`**
   
   - ✅ Screens added for platform parity › a manual journal entry can be read 
whole and reversed — `5.3s`
   - ✅ Screens added for platform parity › an entry that is already reversed is 
not offered again — `5.3s`
   - ❌ Screens added for platform parity › a report definition can be created, 
edited and deleted; a core one cannot — `19.4s` _(retried 2×)_
   - ✅ Screens added for platform parity › a core report opens read-only with 
only its in-use setting — `5.4s`
   - ✅ Screens added for platform parity › a pending loan is approved from the 
queue, in a batch — `6.0s`
   - ✅ Screens added for platform parity › a fixed deposit is listed as a 
deposit, not as a savings account — `5.9s`
   - ✅ Screens added for platform parity › an office has a screen, and it 
carries its custom fields — `4.7s`
   - ✅ Screens added for platform parity › a savings account carries notes, and 
the note survives a reload — `7.2s`
   
   **`rbac-backend-restricted-user.spec.ts`**
   
   - ✅ a genuinely restricted Fineract user › holds exactly the permissions 
their role was granted — `240ms`
   - ✅ a genuinely restricted Fineract user › reaches the screen their 
permission covers — `4.2s`
   - ✅ a genuinely restricted Fineract user › is refused a screen their 
permission does not cover, by URL and by the backend — `5.3s`
   - ✅ a genuinely restricted Fineract user › is refused a write screen they 
can read the list for, and the write itself — `6.1s`
   - ✅ a genuinely restricted Fineract user › is not offered the actions it 
would be refused for — `5.0s`
   - ✅ a genuinely restricted Fineract user › is shown an action it cannot 
take, disabled and saying what it needs — `5.3s`
   - ✅ a genuinely restricted Fineract user › the superuser the rest of the 
suite uses is unaffected — `8.6s`
   
   **`rbac-multi-permission.spec.ts`**
   
   - ✅ a route declaring more than one permission code (OR semantics) › is 
admitted by either declared code alone — `5.5s`
   - ✅ a route declaring more than one permission code (OR semantics) › is 
admitted by the other declared code alone — `4.3s`
   - ✅ a route declaring more than one permission code (OR semantics) › is 
refused when holding neither declared code, by the router and by the backend — 
`5.4s`
   - ✅ ALL_FUNCTIONS_READ, against the real Fineract permission catalogue › 
reaches read screens across modules it holds no specific code for — `9.8s`
   - ✅ ALL_FUNCTIONS_READ, against the real Fineract permission catalogue › is 
refused every write screen, and the writes themselves — `7.0s`
   - ✅ a restricted session across a real page reload › keeps the same 
permission boundary after reloading, not just after a fresh login — `9.8s`
   - ✅ a second real action-level gate, distinct from loan repayment › is shown 
the Approve action disabled and naming what it needs, refused by the backend 
too — `6.2s`
   - ✅ Security module writes (users, roles), against the real backend › 
reaches the list screens but is refused the write screens — `10.1s`
   - ✅ Security module writes (users, roles), against the real backend › is 
refused creating a user and modifying a role, by the backend itself — `290ms`
   
   **`full-demo.spec.ts`**
   
   - ✅ Full feature demo recording › walk through loan schedule type, 
lifecycle, custom fields, collateral, and disbursement — `1m 6s`
   
   **`loan-lifecycle.spec.ts`**
   
   - ✅ Loan lifecycle: creation, approval, disbursement › create, approve, and 
disburse a Cumulative loan — `32.8s`
   - ✅ Loan lifecycle: creation, approval, disbursement › create, approve, and 
disburse a Progressive loan — `34.5s`
   - ✅ Loan lifecycle: creation, approval, disbursement › an approved loan can 
be returned to pending approval — `30.4s`
   - ✅ Loan lifecycle: creation, approval, disbursement › the delinquency tab 
reads a real loan, and the empty data tabs stay hidden — `29.7s`
   
   **`loan-schedule-type.spec.ts`**
   
   - ✅ Loan Schedule Type (Cumulative vs Progressive) › loan products list 
shows a schedule type chip per product — `9.8s`
   - ✅ Loan Schedule Type (Cumulative vs Progressive) › create a Progressive 
loan product end-to-end and verify it round-trips — `15.7s`
   - ✅ Loan Schedule Type (Cumulative vs Progressive) › loan creation shows the 
schedule type badge for a Progressive product — `11.0s`
   
   **`report-parameter-backend.spec.ts`**
   
   - ✅ Dynamic report parameters against Fineract › keeps the parameter form 
available when a report has cascading lookups — `5.0s`
   - ✅ Dynamic report parameters against Fineract › changing Office changes the 
Client Listing row set — `6.6s`
   - ✅ Cascading report parameters against Fineract › sends the parent value to 
the child lookup and clears the child when it changes — `7.5s`
   - ✅ Chart reports against Fineract › renders a chart report as a chart 
rather than a table — `4.3s`
   
   **`savings-transaction-correction.spec.ts`**
   
   - ✅ Savings transaction correction › a deposit is reversed and a hold is 
released — `6.9s`
   
   **`share-account-servicing.spec.ts`**
   
   - ✅ Share account servicing › an account is approved, activated, traded and 
closed — `12.3s`
   - ✅ Share account servicing › an application can be rejected — `6.2s`
   
   **`share-product-accounting.spec.ts`**
   
   - ✅ Share product accounting › a share product is mapped to equity and 
round-trips on edit — `24.1s`
   
   **`teller-cash-management.spec.ts`**
   
   - ✅ Teller cash management › a cashier is listed, receives an allocation, 
and settles cash back — `24.8s`
   - ✅ Teller cash management › settling more than the cashier holds is refused 
and the form stays usable — `12.2s`
   
   </details>
   
   <details>
   <summary><b>Slowest 10</b> — what the shard counts should be tuned 
against</summary>
   
   | Test | Spec | Time |
   | --- | --- | ---: |
   | Full feature demo recording › walk through loan schedule type, lifecycle, 
custom fields, collateral, and disbursement | `full-demo.spec.ts` | 1m 6s |
   | Loan product accounting › a cash-accounting product is configured, 
round-trips on edit, and posts to the ledger | 
`loan-product-accounting.spec.ts` | 48.1s |
   | Loan lifecycle: creation, approval, disbursement › create, approve, and 
disburse a Progressive loan | `loan-lifecycle.spec.ts` | 34.5s |
   | Loan lifecycle: creation, approval, disbursement › create, approve, and 
disburse a Cumulative loan | `loan-lifecycle.spec.ts` | 32.8s |
   | Loan lifecycle: creation, approval, disbursement › an approved loan can be 
returned to pending approval | `loan-lifecycle.spec.ts` | 30.4s |
   | Loan lifecycle: creation, approval, disbursement › the delinquency tab 
reads a real loan, and the empty data tabs stay hidden | 
`loan-lifecycle.spec.ts` | 29.7s |
   | Teller cash management › a cashier is listed, receives an allocation, and 
settles cash back | `teller-cash-management.spec.ts` | 24.8s |
   | Share product accounting › a share product is mapped to equity and 
round-trips on edit | `share-product-accounting.spec.ts` | 24.1s |
   | Screens added for platform parity › a report definition can be created, 
edited and deleted; a core one cannot | `parity-screens.spec.ts` | 19.4s |
   | Group membership and lifecycle › a group is activated, staffed, given 
members and a committee, then emptied | `group-membership.spec.ts` | 19.0s |
   
   </details>
   
   
   📼 [Download the HTML report, videos and 
traces](https://github.com/apache/fineract-backoffice-ui/actions/runs/35787088713)
 — see the `playwright-report-backend` artifact.
   
   <sub>Generated by [run 
35787088713](https://github.com/apache/fineract-backoffice-ui/actions/runs/35787088713)
 from `12b6493`. The run executed a fork branch, so treat its contents as 
unverified.</sub>


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@fineract.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org