Created by Jideo Pena (Unlicensed) on Feb 22, 2023
Total: 36 . Chart by: Status

BACK OFFICE

Epic Ticket

Story Ticket

User Story

Acceptance Criteria

Test Case ID

Test Result

Bug ID

SM-484 - BO: Customer search Done

SM-600 - As a BO user I want to find a customer by names & date of birth, also account number Accepted

As a BO user I want to find a customer by names & date of birth, also account number

NO ACCEPTANCE CRITERIA

Contains criteria for the following search filter as well:

  • User can successfully search for a customer based on defined criteria (Customer ID, Phone number, Email address, Customer name + date of birth, Account number). In case of successful match, user will be redirected to customer dashboard. In case of multiple results, additional information will be displayed for each result (Date of birth (unmasked), Phone number (and if is verified), Email address, Street and street number)

SM-5402 - QA System Test: UI | Web App | Back Office | User finds a customer by name & birthdate Done

SM-5403 - QA System Test: UI | Web App | Back Office | User does not find a customer by name & birthdate Done

SM-5404 - QA System Test: UI | Web App | Back Office | User does not find a customer by name & birthdate and throws an error Done

SM-1561 - Redesign search to use a radio button Done

N/A

  • The search looks and behaves based on the wireframes

https://www.figma.com/file/XB0SoXYQcsEhQiEYPVKcXu/SaFi---Back-Office-WIP?node-id=2%3A2

NEED ACCESS

NO NEED FOR TEST CASE

SM-602 - As a BO user I want to find a customer by email Accepted

As a BO user I want to find a customer by email

NO ACCEPTANCE CRITERIA

  • User can successfully search for a customer based on defined criteria (Customer ID, Phone number, Email address, Customer name + date of birth, Account number). In case of successful match, user will be redirected to customer dashboard. In case of multiple results, additional information will be displayed for each result (Date of birth (unmasked), Phone number (and if is verified), Email address, Street and street number)

SM-5405 - QA System Test: UI | Web App | Back Office | Valid: User finds a customer by email Done

SM-5406 - QA System Test: UI | Web App | Back Office | Invalid: User finds an invalid customer by email Done

SM-5407 - QA System Test: UI | Web App | Back Office | Error: User finds an empty customer by email Done

SM-598 - As a BO user I want to find a customer by ID Accepted

As a BO user I want to find a customer by ID

NO ACCEPTANCE CRITERIA

  • User can successfully search for a customer based on defined criteria (Customer ID, Phone number, Email address, Customer name + date of birth, Account number). In case of successful match, user will be redirected to customer dashboard. In case of multiple results, additional information will be displayed for each result (Date of birth (unmasked), Phone number (and if is verified), Email address, Street and street number)

SM-5408 - QA System Test: UI | Web App | Back Office | Valid: User finds a customer by customer id Done

SM-5625 - QA System Test: UI | Web App | Back Office | Wrong: User finds a wrong customer by customer id Turn on screen reader support Done

SM-5409 - QA System Test: UI | Web App | Back Office | Invalid: User finds an invalid customer by customer id Done

SM-599 - As a BO user I want to find a customer by phone number Accepted

As a BO user I want to find a customer by phone number

NO ACCEPTANCE CRITERIA

  • User can successfully search for a customer based on defined criteria (Customer ID, Phone number, Email address, Customer name + date of birth, Account number). In case of successful match, user will be redirected to customer dashboard. In case of multiple results, additional information will be displayed for each result (Date of birth (unmasked), Phone number (and if is verified), Email address, Street and street number)

SM-5410 - QA System Test: UI | Web App | Back Office | Valid: User finds a customer by phone number Done

SM-5411 - QA System Test: UI | Web App | Back Office | Invalid: User finds an invalid customer by phone number with less than 10 digits Done

SM-5626 - QA System Test: UI | Web App | Back Office | Invalid: User finds an invalid customer by phone number with 11 digits Done

SM-576 - BO: Accounts view Done

SM-1075 - Accounts list view Done

I as a BOFE user want to see a list of all accounts for a particular customer in table format so I can have an overview on all customer accounts.

To clarify

  • one tab will show main account

  • 2nd tab savings account list + details (&txs) on click

  • 3rd tab for loans, keep it empty

NO ACCEPTANCE CRITERIA

  • BOFE user can search for customer in BOFE app. After selecting particular customer, user can click on each account (main, savings, loan, overdraft) menu item to see full details.

SM-5412 - QA System Test: UI | Web App | Back Office | User views the overview of the customer's account Done

SM-1076 - Account details view Accepted

I as a BOFE user want to see account details for a particular customer upon clicking on the account, so I can have detailed information for particular account

  • main accounts

  • saving accounts

does not include transactions of accounts or loans accounts

NO ACCEPTANCE CRITERIA

Acceptance criteria:

Main account with details:

  • Status
  • Account name
  • Account number
  • Account ID
  • Created at
  • Updated at
  • Interest rate
  • Gained interest

Saving account (pockets) list:

  • pocket name
  • pocket balance
  • pocket goal

Saving account (pockets)

  • change name (subject to the maker-checker process)

SM-5413 - QA System Test: UI | Web App | Back Office | User views the detailed information of the particular account Done

SM-594 - BO: Customer profile view Done

SM-1067 - View Customer Profile Done

I as a BOFE user will see customer details after successful search of particular customer

https://safibank.atlassian.net/wiki/spaces/ITArch/pages/62881997/View+customer+details

https://www.figma.com/file/wr5Ax3toq5y0ODhgh3WjiG/SaFi---Back-Office?node-id=1163%3A10755

Sections

  • First name

  • Middle name

  • Last name

  • Date of birth

  • Place of birth

  • Nationality

  • Age (calculated on frontend from date of birth)

  • Gender

  • Phone number

  • Email

  • Country of residence

  • ZIP Code

  • Street and number

  • Province

  • City/ Municipality

  • Barangay

  • Other

SM-5414 - QA System Test: UI | Web App | Back Office | User views the customer profile Done

SM-2685 - Customer Profile View - ID card Done

In case of missing or invalid invalid information, the actual ID card photo should be present.

https://safibank.atlassian.net/wiki/spaces/ITArch/pages/96272406/Customer+Profile+View+-+Documents

  • latest ID document info (type, document number and verification checkmark) will be displayed in Customer Profile. Buttons to view all ID documents and all other non-ID documents will be present as well.

SM-5415 - QA System Test: UI | Web App | Back Office | User views the customer profile id card Done

SM-3823 - Mask sensitive customer data Done

Birthdate + Mobile number should be masked and can be opened by clicking the view button beside it <To ensure critical information are not readily exposed>

  • in dashboard

  • in profile

  • NOT in search results

 From figma:

  • Birthdate + Mobile number should be masked and can be opened by clicking the view button beside it <To ensure critical information are not readily exposed>

  • in dashboard

  • in profile

  • NOT in search results

SM-5416 - QA System Test: UI | Web App | Back Office | User views the place of birth and phone number which are both masked Done

SM-2540 - Display customer additional info Done

In order to  help customer with his/her inquiries, problems, complaints, I need to see customer details.

Note: The side effect of the linked task will be that also customer GET will contain the extra info

  • additional info

  • KYC fields other than PEP, US citizen

Customer profile view - Additional information

https://www.figma.com/file/wr5Ax3toq5y0ODhgh3WjiG/SaFi---Back-Office?node-id=1457%3A18749

  • Display correct question / answer pairs as a list in the Customer Profile page. Display if customer indicated PEP or US citizenship.

SM-5417 - QA System Test: UI | Web App | Back Office | User views the customer onboarding questionaire responses Done

SM-670 - BO: Audit Log Done

SM-1134 - Set up audit log POC Done

  • Collect necessary events emitted by domains and store them in Audit Log DB.

  • BOFE should be able to reconstruct

    • History of changes for editable customer attributes

    • Communication history (between a customer and the bank)

      • And extra MS is expected to hold data like full customer emails - such will not be stored in the Log

  • Emit audit log event from customer-manager via dedicated audit log topic
  • Catch and store that event in the audit-log-manager in timescale DB instance
  • Get the event data from audit-log-manager using a rest endpoint

OUT OF SCOPE - NOT PART OF SYSTEM TEST

SM-1135 - Log changed customer & account data Done

Be able to access attribute change history for main entities (customer, account)

Design final change events for these

  • event design in Confluence
  • account change and customer change events emitted by customer/account-manager respectively
  • ability to query those events form the audit-log-manager

SM-6009 - QA System Test: UI | Web App | Back Office | User checks if all changes are logged in the customer history Done

SM-6010 - QA System Test: UI | Web App | Back Office | User checks if all changes are logged in the main account history Done

SM-6012 - QA System Test: UI | Web App | Back Office | User checks if all changes are logged in the alkansafe history Done

SM-1627 - Audit-log-manager infra Done

Create GH workflow to

  • Build-and-push

  • Deploy

Init helm charts

  • audit-log-manager is deployed in DEV env, link added to confluence
  • every merged PR causes redeploy

OUT OF SCOPE - NOT PART OF SYSTEM TEST

SM-1050 - BO: User management Done

SM-1127 - Sign in to BOFE Done

Integrate with SSO login

https://developer.okta.com/code/react/

  • Integrate with SSO login

https://developer.okta.com/code/react/

SM-5399 - QA System Test: UI | Web App | Back Office | User signs in to BOFE with SSO Done

SM-1130 - Role-specific changes to UI Done

  • see confluence story and access matrix to restrict access to certain parts or data in BOFE

  • mobile number and date of birth are personal info and should be masked behind “show info“ button. Click should be logged and info revealed only to users with appropriate roles.

NO ACCEPTANCE CRITERIA

SM-5400 - QA System Test: UI | Web App | Back Office | User wants to check CC team's access rights for Customer Profile Done

SM-5974 - QA System Test: UI | Web App | Back Office | User wants to check CC team's access rights for Subscriptions Done

SM-5975 - QA System Test: UI | Web App | Back Office | User wants to check CC team's access rights for Accounts Done

SM-5976 - QA System Test: UI | Web App | Back Office | User wants to check CC team's access rights for Transactions Done

SM-3576 - Show logged user info in the top header + logout Done

Show logged user info in the top header + logout

  • Show logged user info in the top header + logout

SM-5401 - QA System Test: UI | Web App | Back Office | User signs in to BOFE and user info shows in the top header Done

SM-1051 - BO: Maker - checker workflow Done

SM-1132 - FE: Maker/checker list Done

Curently show all pending changes in both lists. Once we have user managements follow up with SM-3271 - Limit maker/checker lists to only show changes related to the logged in user Done

NO ACCEPTANCE CRITERIA

  • List of change requests (maker/checker) with filter (date, status, change type, customer id, ticket id) and table view of (date, ticket, creator, approver, change target, description, status) in rows with ability to approve or reject the change if applicable.

SM-5642 - QA System Test: UI | Web App | Back Office | User checks all the filters and tables views in pending approvals Done

SM-1133 - FE: Checker change rejection/approval Done

NO USER STORY

Role: BOFE checker (based on the OKTA setup)

Objective: I as a BOFE checker, want to approve or reject changes

Reason: As checker, I need to see what change was proposed, by whom and why, so I can review and decide if they should be approved (updated) or rejected (discarded).

Functional requirements:

Approve

Upon reviewing the proposed changes (and additional information, like Jira ticket), the Approve change button can be clicked and the approve flow triggered:

  1. change will be marked as pending

  2. approval logged in the audit log

  3. change will be executed

  4. change logged in the audit log

  5. notification for Maker will be triggered, see: (blue star)Maker notifications

  6. confirmation dialog will be displayed

See Maker-checker design for detailed flows and triggering notifications.

Reject

Proposed changes can be rejected by clicking the Reject change button and rejection flow triggered:

  1. change marked as rejected

  2. rejection logged in the audit log

  3. notification for Maker will be triggered, see: (blue star)Maker notifications

  4. confirmation dialog will be displayed

NO ACCEPTANCE CRITERIA

  • Acceptance / Rejection flows will be triggered and in correct order, without errors.

SM-5793 - QA System Test: UI | Web App | Back Office | User approves the changes of the customer's personal information Done

SM-5794 - QA System Test: UI | Web App | Back Office | User resets the changes of the customer's personal information Done

SM-5795 - QA System Test: UI | Web App | Back Office | User rejects the changes of the customer's personal information Done

SM-5796 - QA System Test: UI | Web App | Back Office | User approves the changes of the customer's address Done

SM-5797 - QA System Test: UI | Web App | Back Office | User resets the changes of the customer's address Done

SM-5798 - QA System Test: UI | Web App | Back Office | User rejects the changes of the customer's address Done

SM-5799 - QA System Test: UI | Web App | Back Office | User approves the changes of the customer's financial and employment info Done

SM-5800 - QA System Test: UI | Web App | Back Office | User resets the changes of the customer' financial and employment info Done

SM-5801 - QA System Test: UI | Web App | Back Office | User rejects the changes of the customer' financial and employment info Done

SM-5802 - QA System Test: UI | Web App | Back Office | User approves the changes of the customer's contact information Done

SM-5803 - QA System Test: UI | Web App | Back Office | User resets the changes of the customer's contact information Done

SM-5804 - QA System Test: UI | Web App | Back Office | User rejects the changes of the customer's contact information Done

SM-3270 - Show pending changes for particular tab/section Done

Show pending changes for customer profile

  • When new change request is submitted, the edit button will be disabled and “Pending change“ will be visible instead. Upon confirming the change, the button will “Applying changes“ while the changes are being saved to database. Upon successful save, the edit button will appear again.

SM-5865 - QA System Test: UI | Web App | Back Office | User requests change in user information and edit button will be disabled and replaced by pending change Done

SM-1055 - BO: Transaction overview Done

SM-1088 - Transaction search by date Accepted

Role: BOFE user (Bank employee - BO agent, CC agent, BO or CC supervisor, head of unit, administrator)

Objective: I as a BOFE user can search for transaction(s) by date when transactions were executed

Reason: In order to see all transactions for particular account that are in date range that I as as BOFE user selected

Functional requirements:

  • all transactions that are in selected date range will be displayed for particular account

  • user can choose option to use date range to search for transactions (e.g. last day, last week, last month or last year)

  • user can choose the option to define date range (“from“ and “to“ date) to search for transactions

    • user should have an option to manually type date for transaction search or use calendar to search for dates

Execution steps: user chooses “search“ option, selects search by date, selects date range and initiates search by date.

  • by clicking on “search“ all transactions for selected dates will be displayed regardless of the status of transaction, type of transaction

SM-5418 - QA System Test: UI | Web App | Back Office | User searches for transactions by date Done

SM-1089 - Transaction search by amount Accepted

Role: BOFE user (Bank employee - BO agent, CC agent, BO or CC supervisor, head of unit, administrator)

Objective: I as a BOFE user can search for transaction(s) by amount of the transaction

Reason: In order to see all transactions for particular account that are in amount range that I as as BOFE user selected

Functional requirements:

  • all transactions that are in selected date range will be displayed for particular account

  • user can choose the option to define date range (“from“ and “to“ amount) to search for transactions in particular range by manually typing the amount for transaction search

  • user should have an option to type amount with max. 2 decimal places

Execution steps: user chooses “search“ option, selects search by amount, selects amount range and initiates search by amount.

  • by clicking on “search“ all transactions for selected amount range will be displayed regardless of the status of transaction, type of transaction

SM-5419 - QA System Test: UI | Web App | Back Office | User searches for transactions by amount Done

SM-1090 - Transaction search by credit/debit Accepted

Role: BOFE user (Bank employee - BO agent, CC agent, BO or CC supervisor, head of unit, administrator)

Objective: I as a BOFE user can search for transaction(s) by credit/ debit status

Reason: In order to see all transactions for particular account that are in inbound or outbound for particular account.

Functional requirements:

  • if user selects debit option, only all outgoing transactions for particular account will be displayed

  • if user selects credit option, only all incoming transactions for particular account will be displayed

Execution steps: user chooses “credit/debit“ option, selects either credit or debit, and initiates search by credit or debit

  • by selecting credit all incoming transactions for selected account will be displayed regardless of the status of transaction, type of transaction. By selecting debit, all outgoing transactions for selected account will be displayed

SM-5682 - QA System Test: UI | Web App | Back Office | User searches for transactions by credit or debit Done

SM-1091 - Transaction search by status Accepted

Role: BOFE user (Bank employee - BO agent, CC agent, BO or CC supervisor, head of unit, administrator)

Objective: I as a BOFE user can search for transaction(s) by status

Reason: In order to see all transactions for particular status that I as a BOFE user selected

Functional requirements:

  • all statuses that are defined by transaction squad should be displayed and could be selected

  • statuses

    • realized transactions

    • unrealized transactions

    • Waiting transactions

    • Reservations

    • Storno

Execution steps: user chooses particular status and initiates search by this status

  • all transactions for selected status will be displayed for particular account regardless of other search criteria

SM-5679 - QA System Test: UI | Web App | Back Office | User searches for transactions by status Done

SM-1087 - Transaction (history) view Done

Role: BOFE user (see access matrix)

Objective: I as a BOFE user want to see a transaction history upon clicking on particular account, so I can have an overview on transactions per particular account.

Functional requirements: 

  • e.g. past 10 transactions will be displayed automatically with expansion option to see more transactions for the account to see older transactions

  • transactions should be arranged / displayed chronologically from newest to oldest

  • each transaction will have information (if available):

    • date of transaction (“from”, “to” dates)

    • reference ID

    • status of transaction

    • type of transaction (e.g. “Pocket transaction“)

    • beneficiary

    • amount of transaction (debit / credit indicator)

    • Balance

  • filter to search for transactions should be displayed so user can search transactions by:

  • Actions on main account:

NO ACCEPTANCE CRITERIA

  • All transactions for particular account are visible, search filter can be applied and particular transaction(s) are displayed based on search criteria.

SM-5866 - QA System Test: UI | Web App | Back Office | User searches for transaction history on a particular account Done

SM-1056 - BO: Transaction adjustment Done

SM-1093 - Manual transactions Done

Will be used for reversals too (in regulatory)

Can be in a same page as reconciliation reports

POST /transaction/intrabank

There will be no design

Simple form

  • account from

  • account to

  • amount

  • note

NO ACCEPTANCE CRITERIA

  • admin page with new transaction input form
  • new transactions requests audit log
  • correctly inputed transaction will be subject to the maker-checker process
  • when approved will be correctly executed nad logged

SM-6160 - QA System Test: UI | Web App | Back Office | User wants to do an approved manual transaction Done

SM-6161 - QA System Test: UI | Web App | Back Office | User wants to do a rejected manual transaction Done

SM-6162 - QA System Test: UI | Web App | Back Office | User wants to do a approved manual transaction with the same account ID Done

SM-6163 - QA System Test: UI | Web App | Back Office | User wants to fill out the manual transaction then reset Done

SM-1092 - Transaction reversal Accepted

NO USER STORY

Role: BOFE user (see access matrix)

Objective: As a BOFE user, want to easily reverse the transaction, in case of error in transactions (double-posted).

Reason:

Functional requirements:

BOFE user will search for particular transaction determined by reconciliation process and will use the action button “Reverse transaction“. This action will open the manual transaction page with this transaction data, but in reverse order (sender <> beneficiary). Is subject to the maker-checker process, including valid ticket id.

NO ACCEPTANCE CRITERIA

  • Clicking on transaction reverse button will open manual transaction page with sender, beneficiary pre-filled in reverse order.

OUT OF SCOPE - NOT PART OF EPFS

SAF-930 - Manual Money Transfer (Bank transfer) Backlog

New request to initiate money transfer for customer via BOFE

Bank personnel to be able to do Online Fund Transfer within Intrabank or Interbank on behalf of the customer.

Agent will get the ff. information:

Recipient Bank:

Recipient's Name:

Recipient's Acct number:

Amount: <In PHP>

Purpose of Transfer: <For 50,000php and above>

NO ACCEPTANCE CRITERIA

OUT OF SCOPE - NOT PART OF EPFS

OUT OF SCOPE - NOT PART OF EPFS

SM-4149 - Flagged transactions in account tx view Done

NO USER STORY

OUT OF SCOPE - NOT PART OF EPFS

NO ACCEPTANCE CRITERIA

OUT OF SCOPE - NOT PART OF EPFS

OUT OF SCOPE - NOT PART OF EPFS

SM-4150 - Flagged transaction reject/release Done

NO USER STORY

OUT OF SCOPE - NOT PART OF EPFS

NO ACCEPTANCE CRITERIA

OUT OF SCOPE - NOT PART OF EPFS

OUT OF SCOPE - NOT PART OF EPFS

SM-1676 - BO: Customer profile changes Done

SM-1070 - View customer editing history Done

Role: BOFE user (see access matrix)

Objective: As a BOFE user, I want to see relevant changes in particular product or screen, that I am currently viewing.

Reason: BOFE users need to identify why particular changes happened, when and by whom.

Functional requirements:

 

List of relevant changes in sections:

  • Customer profile

  • Customer documents

  • Main account changes

  • Saving account changes

  • Loans

  • Cards

NO ACCEPTANCE CRITERIA

SM-5741 - QA System Test: UI | Web App | Back Office | User views the customer history Done

SM-1069 - Edit customer details Done

NO USER STORY

Role: BOFE user (see access matrix)

Objective: I, as a BOFE user want to edit / change personal information on particular customer.

Reason: Up-to-date customer information.

 

UI requirements:

  • Each section has an edit button, that will reveal editable fields.

  • Fields has validation based on the data restrictions.

  • Reset button (clear changes) and submit button.

NO ACCEPTANCE CRITERIA

  • After clicking the edit button, customer data can be edited. Fields have validation to provide feedback if wrong values are inputed. Clear button will clear active edits. Submit button will create pending change. Valid ticket id must be provided in the next step and approval is subject to the maker-checker process. Edits will be applied only if approved by checker.

SM-6167 - QA System Test: UI | Web App | Back Office | User checks all the editable fields Done

SM-1712 - BO: General UI/UX Done

SM-2780 - Local date / time format Done

OUT OF SCOPE - NOT PART OF EPFS

NO USER STORY

Role: BOFE users (all)

Objective: As a BOFE user I want to see dates in my local format, that I am familiar with.

Reason: Working with sensitive client data, the date and time format can’t cause any confusion or second-guessing and has to be standard across the whole BOFE.

Functional requirements:

All date data should be formatted as

3 letter abbreviation of the month - day number with leading zero - 4 digit year

Example:

  • Jun-25-2022

  • Jan-01-2022

Time formatted in 12h format with colon.

Example:

06:32 AM

04:39 PM

OUT OF SCOPE - NOT PART OF EPFS

NO ACCEPTANCE CRITERIA

  • Correctly formatted date and time (Jun-25-2022 06:32 AM) in view and edit fields.

OUT OF SCOPE - NOT PART OF EPFS

OUT OF SCOPE - NOT PART OF EPFS

SM-3618 - Update design of verified phone number Done

NO USER STORY

OUT OF SCOPE - NOT PART OF EPFS

NO ACCEPTANCE CRITERIA

OUT OF SCOPE - NOT PART OF EPFS

SM-4024 - Extract & Unify Amount Display Component Done

NO USER STORY

OUT OF SCOPE - NOT PART OF EPFS

NO ACCEPTANCE CRITERIA

OUT OF SCOPE - NOT PART OF EPFS

SM-2458 - BO: Reconciliation reports - manual Done

Manual reconciliation:

  • pick date (or range) for the reconciliation

  • get all transactions from the system for that range containing information depicted below

  • download as CSV file

SM-4199 - Download report of daily transactions Done

NO USER STORY

Manual reconciliation:

  • pick date (or range) for the reconciliation

  • get all transactions from the system for that range containing information depicted below

  • download as CSV file

NO ACCEPTANCE CRITERIA

  • (Admin) reports page
  • Report date picker
  • Export button to extract all transaction data from the system
  • Download as CSV file

SM-5719 - QA System Test: UI | Web App | Back Office | User downloads the daily transaction report Done

SM-4588 - BO Microservices security - authorisation and authentication Done

NO STORY TICKET

OUT OF SCOPE - TECH STORY

NO USER STORY

OUT OF SCOPE - TECH STORY

NO ACCEPTANCE CRITERIA

OUT OF SCOPE - TECH STORY

Attachments:

701a33c0-1675-4fc7-a123-20d7f181612a#media-blob-url=true&id=71a59cd5-9461-492d-9ba8-850a9d637d5f&collection=&contextId=19074&mimeType=image%2Fpng&name=Screenshot%20from%202022-09-12%2012-08-50.png&size=5460&height=88&width=750 (image/png)
3074b53f-ac50-4f89-884f-8057128cc914#media-blob-url=true&id=499ad26a-d66c-438e-b023-210a449088e5&collection=&contextId=19074&mimeType=image%2Fpng&name=Screenshot%20from%202022-09-12%2012-08-41.png&size=5074&height=106&width=856 (image/png)
Screenshot from 2022-09-12 12-08-50.png (image/png)
Screenshot from 2022-09-12 12-08-41.png (image/png)