Created by Jakub Ukrop, last modified by Jan Rychlý on Dec 22, 2022

List of change views

Section

Event example

Audit log query

Customer profile (includes address, contact, survey)

Also includes Subscriptions

Also includes ID cards

email changed, address changed

targetType: "CUSTOMER"
targetId: customer ID

or

targetType: "SUBSCRIPTION"
targetEntityMeta.customerId: customer ID

or

targetType: "ID_CARD"
targetEntityMeta.customerId: customer ID

Customer documents
[changes for all documents]

document added, document verified, document removed

targetType: "DOCUMENT"
targetEntityMeta.customerId: customer ID

Main account

account name changed, account status changed, account frozen, amount blocked

targetType: "ACCOUNT"
targetId: main account ID

Pocket
[changes per 1 pocket]

pocket locked

targetType: "ACCOUNT"
targetId: saving account ID

Loans

Loan taken

targetType: "LOAN"
targetId: laon account ID

Overdraft

Top-up

targetType: "OVERDRAFT"
targetId: main account ID [overdraft is bound to main accout]

Card
[changes per 1 card]

card limit changes

targetType: "CARD"
targetId: card ID

Tickets

N/A managed by Jira

-

Notes

Activities

Activity is a common data type for displaying details about any kinds of changes or events. We generate descriptions for activities and display details (including an optional comparison to current data, relevant for pending back-office Changes only).

There are several kinds of entities that we convert to Activities:

  • Change - a pending back-office change object that is part of the maker-checker flow.

  • AuditLogEvent - an event returned by auditlog-manager; these further divide into

    • Events about BO Changes getting accepted, rejected or failing to be applied - these are audit logs from backoffice-manager

    • Events about general changes from other managers - this can be the accepted BO Change getting applied OR the customer making a change themselves in the mobile app.

    • Events about things happening that don’t change anything such as customer being searched or sensitive customer information being unmasked.

Activities are used mainly in ChangesGrid (“My changes” and “Pending approvals” page) and HistoryView (the bottom of most customer pages)

  • ChangesGrid converts only Changes to Activities

  • HistoryView converts only AuditLogEvents to Activities.

The Activity TypeScript types are in src/components/business/ActivityView/types.ts.

Activity can be flagged with isSimple if the text description gives enough information about the event - in that case, no details modal in HistoryView will be available for that event.

The Activity.type and Activity.details props are tied together, that way when TS knows an activity is of a certain type it will also know what the details look like. The isSimple flag can also be mandated for certain activities by defining it as isSimple: true in ActivitySpecifics.

Example PRs

  • simple activity (+ maker-checker) #7719

Checklist for adding new activity

  • Types src/components/business/ActivityView/types.ts - a new type needs to be added - either in the ActivitySpecifics together with the details or in SimpleActivitySpecifics

  • Routes src/components/business/ActivityView/routes.ts - only relevant for Change activities; when listing changes in a grid (My changes/Pending approvals) there is a link to the relevant page that the change is about.

  • Descriptions src/components/business/ActivityView/descriptions.ts - brief text descriptions of the activity, mainly used for one-line description in the lists/girds; this means adding a new case and also a new translation key

  • Conversions

    • Event → Activity src/components/business/HistoryView/eventConversion.ts

      • The main function there is getEventActivity which uses different other functions to piece together the Activity putting together the non-type specific information (nature, customerId, entityId...), and the type+detail from getChangeEventSpecifics and other functions.

      • getChangeEventSpecifics is the biggest one, used for BO change events and BO changes being applied

      • The file is currently huge it would be nice to somehow split it further, simplify it at some point

    • Change → Activity src/components/business/ActivityView/changes.ts - a bit simpler as TS knows much more about the Change type and the naming often matches the naming in the activity details

    • Usually, when adding a new BO change we need to take care of converting the new Change, the BO change event and the events of that change being applied

  • ActivityView src/components/business/ActivityView/ActivityView.tsx

    • Used in details modal for Changes and AuditLogEvents

    • For each activity type it uses a more specific component to display details about the changes in that event - therefore you’ll need to add a new case for your new activity type and may also need to add a new *View component or alter an existing one

    • It has the option to show the changed attributes side by side with the current data (relevant for current pending BO Changes as “before” and “after”)

    • It will also automatically display the entity name and the activity description for activities with the isSimple flag so for such events, there is no need to add a new case

Activity list

  • For how the event is handled, see: app-bo/src/components/business/HistoryView/eventConversion.ts

    • Domain event [column 3] is an event from another domain (like when customer-manager emits an event about changing customer’s email)

    • Change event [column 4] is an event from backoffice-manager (like when it emits an event about customer email change being approved/rejected)

  • For how the change is handled [column 5], see: app-bo/src/components/business/ActivityView/changes.ts

TODO: Fill all empty cells

Actvity type (FE)

Activity

Handled domain event
(what is used in the decision)

ACTION or ENTITY_TYPE or props.found.in.detail

Handled BO change event
(ideally “same as domain”)

Handled BOFE change
(what is used in the decision)

user.communicated

Communication occurs

COMMUNICATED

N/A

N/A

user.searched

Search customers

SEARCHED

N/A

N/A

user.logged.in

User logs in

LOGGED_IN

TODO: IAM should emit this kind of events (for BO users and customer)

N/A

N/A

user.logged.out

User logs out

LOGGED_OUT

TODO: IAM should emit this kind of events (for BO users and customer)

N/A

N/A

Customer

customer.status.updated

Customer signed up/finished onboarding/activated, offboarded etc.

customer.status

customer.offboardingAction

change.customerOffboardingAction

customer.isBankEmployee.updated

Update “bank employee” flag

ATTRIBUTE_CHANGED + customer.isBankEmployee

same as domain

change.customerIsBankEmployee

customer.profile.updated

Update profile

ATTRIBUTE_CHANGED + customer.firstName

same as domain

change.customerUpdatedProfile

customer.preference.updated

Update preferences

ATTRIBUTE_CHANGED + customer.preference.*

N/A

N/A

customer.address.updated

Update address

ATTRIBUTE_CHANGED + customer.address.*

same as domain

change.customerUpdatedAddress
change.customerUpdatedAddressV2

customer.declaration.updated

Update declaration data

ATTRIBUTE_CHANGED + customer.notPepDeclaredAt / customer.notUsDeclaredAt

N/A

N/A

customer.survey.updated

Update survey answers

ATTRIBUTE_CHANGED + customer.additionalInfo.surveyId

customer.survey.id

Update to match domain

change.customerUpdatedSurvey

customer.contact.updated

Update phone or email

ATTRIBUTE_CHANGED + customer.phoneNumber / customer.email

customer.phone.number / customer.email

change.customerUpdatedContact

customer.attribute.unmasked

Unmask attribute

UNMASKED

N/A

N/A

Subscription

customer.subscription.status.updated

Freeze
Unfreeze
Activate

??
UNBLOCKED
ACTIVATED

Ask account squad if/how they log freeze (freezeCustomerSubscription).

customerSubscription.status

change.productUpdatedSubscription?.subscriptionStatus

customer.subscription.waivedFee

Waive fee

DEACTIVATED + customerSubscriptionWaive.id

customerSubscription.waivedFee

Update to match domain

change.productUpdatedSubscription?.waivedFee

customer.subscription.updated

Update plan
Ppdate autodebit date

ATTRIBUTE_CHANGED

customerSubscription.subscriptionPlanId

"customerSubscription.autodebitAt"

Ask account squad to send only relevant data in event, e.g. updateSubscriptionAutodebitDate logs the updated autodebit date, not subscription plan ID

customerSubscription.subscriptionPlanId / customerSubscription.autodebitDate

change.productUpdatedSubscription?.updatedSubscriptionPlanId
change.productUpdatedSubscription?.autodebitDate

[not handed by FE yet]

Reset usage
Renew usage

Not handled by FE, do we want it?

(see resetCustomerSubscriptionUsage, renewSubscriptionUsage)

Also there is no way to distinguish form other subscription events - the detail should only include relevant data (or use a dedicated action)

N/A

N/A

[not handed by FE yet]

Revert operation usage
Commit operation usage

ATTRIBUTE_CHANGED
CREATED

As above, see sendSubscriptionOperationUsageMessage

N/A

N/A

Free subscription

[not handed by FE yet]

Create

CREATED

Should BOFE display this? Where? No such events in the system yet.

N/A

N/A

[not handed by FE yet]

Use

ATTRIBUTE_CHANGED

[not handed by FE yet]

Block

BLOCKED

Subscription plan

[not handed by FE yet, not needed]

Create

CREATED

N/A

N/A

[not handed by FE yet, not needed]

Update

ATTRIBUTE_CHANGED

N/A

N/A

Bonus operation

[not handed by FE yet]

Create

CREATED

N/A

N/A

[not handed by FE yet]

Invalidate

DEACTIVATED

N/A

N/A

Document

[not handed by FE yet, not needed]

Search documents

[not handed by FE yet, not needed]

N/A

N/A

document.created

Create

CREATED + document.filename

document.filename + NOT documentId in meta

change.documentUploaded

document.invalidated

Delete

Ask customer squad if/how they log this.

document.deleted

change.documentDeleted

document.name.updated

Update name

ATTRIBUTE_CHANGED + document.filename

Ask customer squad if/how they log this. (adminRenameDocument)

document.filename + documentId in meta

change.documentUpdated

document.verification.updated

Verify/Reject

Ask customer squad if/how they log this.

Ensure they do not log the whole document, only what is relevant for the event - in this case the verification result.

document.verificationResult

change.documentVerified

ID card

customer.idCard.created

Create

CREATED + ID_CARD + idCard.frontSideDocumentId

idCard.frontImageBase64

change.idCardUploaded

customer.idCard.invalidated

Delete

Ask customer squad if/how they log this. (markIdCardAsDeleted)

idCard.deleted

change.idCardDeleted

customer.idCard.updated

Update name

ATTRIBUTE_CHANGED + idCard.cardType / idCard.idExpiryDate / idCard.idNumber

idCard.idCardType / idCard.expiryDate / idCard.idNumber

Update to match domain

change.idCardUpdated

customer.idCard.verification

Verify/Reject

Ask customer squad if/how they log this. (markIdCardAsDeleted)

idCard.verificationResult

change.idCardVerified

Main account

mainAccount.created

Create

CREATED + ACCOUNT + accountType

N/A

N/A

mainAccount.activated

Activate

ACTIVATED + ACCOUNT

N/A

N/A

mainAccount.deactivated

Deactivate

DEACTIVATED + ACCOUNT + accountType

N/A

N/A

mainAccount.attributes.updated

Update name

ATTRIBUTE_CHANGED + account.name

same as domain

change.accountUpdatedAttributes

mainAccount.status.updated

Block/unblock

by bank or customer

Ask accounts squad if/how they log this.

accountType + account.status

change.mainAccountUpdatedStatus

Saving account

savingAccount.created

Create (locked/unlocked)

CREATED + ACCOUNT + accountType

N/A

N/A

savingAccount.closed

Close

DELETED + ACCOUNT

N/A

N/A

savingAccount.deactivated

Deactivate

DEACTIVATED + ACCOUNT + accountType

savingAccount.status.updated

Lock/unlock

ATTRIBUTE_CHANGED + account.savingAccount.locked / account.locked

accountType + account.status

Update to match domain

change.savingAccountUpdatedStatus

savingAccount.lockDate.updated

Update “Date locked” attribute

ATTRIBUTE_CHANGED + account.savingAccount.lockDate

N/A

N/A

savingAccount.lockParameters.updated

Updated lock parameters

ATTRIBUTE_CHANGED + account.savingAccount.tenureMonts / account.savingAccount.autoRenewal

N/A

N/A

savingAccount.target.updated

Updated target date and/or amount

ATTRIBUTE_CHANGED + account.savingAccount.targetDate / account.savingAccount.targetAmount

N/A

N/A

Card

card.limits.updated

change.cardUpdatedLimit

card.status.updated

Freeze/Unfreeze/Block

BLOCKED/UNBLOCKED + card.status

The card.status value does not match the BO change event values - it is PERMANENT_BLOCKED | ACTIVE | LOCKED

card.status ((warning) values are 'BLOCK' | 'UNFREEZE' | 'FREEZE')

change.cardLocked

Transaction

transaction.created

change.transactionCreated

transaction.manuallyApproved

change.transactionManuallyApproved

Known limitations (blue star)

  • For changes (like an update of customer email) we do not store the original values in the audit log, so the log entry will only say “Customer email changes to X by user Y because of ticket Z at time T” but not what the email value was before.

  • The granularity of logs is based on the BE granularity. For example, when a customer’s firstName is changed on FE, the BE is updating the whole customer profile and not caring what attributes have actually changed. Therefore the BE is logging the full profile as changed and that’s what the FE history will then display, “Customer profile changed” + list of the values, there is no way to know which of them were the same as before.