feat: update Search/Reports page immediately following report actions #56772

mkzie2 · 2025-02-12T17:05:11Z

Explanation of Change

feat: update Search/Reports page immediately following report actions

Fixed Issues

$ #55211
PROPOSAL: #55211 (comment)

Tests

Precondition: Create a workspace and enable workflow, approval, and delay submission (manually)

Submit Report

Create an expense
Go to Reports > Expense > Draft
Submit the report by using the submit button in search
Verify that the submitted report is removed with animation
Create another expense
Open the RHP report
Submit the report
Verify that the submitted report is removed with animation

Approve Report

Go to Reports > Expense > Outstanding
Approve a report by using the approve button in search
Verify that the approved report is removed with animation
Open another report in RHP
Approve the report
Verify that the approved report is removed with animation

Pay Report

Go to Reports > Expense > Approved
Pay a report by using the approve button in search
Verify that the approved report is removed with animation
Open another report in RHP
Pay the report
Verify that the approved report is removed with animation

Delete Report

Go to Reports > Expense > All
Create some expense
Select the created expense and delete
Verify that the report is removed with animation
Open the RHP report
Open Report detail > Delete expense
Verify that the report is removed with animation

Verify that no errors appear in the JS console
Unapprove Report

Go to Reports > Expense > Approved
Open any RHP Report
Open the report detail > Unapprove
Verify that the report is removed with animation

Cancel payment

Go to Reports > Expense > Paid
Open any RHP Report
Open the report detail > Cancel payment
Verify that the report is removed with animation

Submit/Approve/Pay in all status

Create an expense
Go to Reports > Expense > All
Submit/Approve/Pay the expense
Verify that the report is not removed.
Create another one
Open the report RHP
Submit/Approve/Pay the expense
Verify that the report is not removed.

Offline tests

None

QA Steps

Precondition: Create a workspace and enable workflow, approval, and delay submission (manually)

Submit Report

Create an expense
Go to Reports > Expense > Draft
Submit the report by using the submit button in search
Verify that the submitted report is removed with animation
Create another expense
Open the RHP report
Submit the report
Verify that the submitted report is removed with animation

Approve Report

Go to Reports > Expense > Outstanding
Approve a report by using the approve button in search
Verify that the approved report is removed with animation
Open another report in RHP
Approve the report
Verify that the approved report is removed with animation

Pay Report

Go to Reports > Expense > Approved
Pay a report by using the approve button in search
Verify that the approved report is removed with animation
Open another report in RHP
Pay the report
Verify that the approved report is removed with animation

Delete Report

Go to Reports > Expense > All
Create some expense
Select the created expense and delete
Verify that the report is removed with animation
Open the RHP report
Open Report detail > Delete expense
Verify that the report is removed with animation

Verify that no errors appear in the JS console
Unapprove Report

Go to Reports > Expense > Approved
Open any RHP Report
Open the report detail > Unapprove
Verify that the report is removed with animation

Cancel payment

Go to Reports > Expense > Paid
Open any RHP Report
Open the report detail > Cancel payment
Verify that the report is removed with animation

Submit/Approve/Pay in all status

Create an expense
Go to Reports > Expense > All
Submit/Approve/Pay the expense
Verify that the report is not removed.
Create another one
Open the report RHP
Submit/Approve/Pay the expense
Verify that the report is not removed.

Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videos

Android: Native

Screen.Recording.2025-02-12.at.23.48.09.mov

Android: mWeb Chrome

Screen.Recording.2025-02-12.at.23.43.53.mov

iOS: Native

Screen.Recording.2025-02-12.at.23.49.54.mov

iOS: mWeb Safari

Screen.Recording.2025-02-12.at.23.46.38.mov

MacOS: Chrome / Safari

Screen.Recording.2025-02-12.at.23.38.15.mov

Screen.Recording.2025-02-12.at.23.38.50.mov

Screen.Recording.2025-02-12.at.23.38.59.mov

Screen.Recording.2025-02-12.at.23.39.39.mov

Screen.Recording.2025-02-13.at.00.04.19.mov

Screen.Recording.2025-02-17.at.15.15.39.mov

Screen.Recording.2025-02-17.at.15.15.52.mov

MacOS: Desktop

Screen.Recording.2025-02-12.at.23.52.32.mov

melvin-bot · 2025-02-12T17:14:06Z

@sobitneupane Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

luacmartins

@mkzie2 we have conflicts

mkzie2 · 2025-02-14T04:36:31Z

@luacmartins I updated.

luacmartins · 2025-02-14T17:14:36Z

@sobitneupane let's review this one once you're online!

sobitneupane

When I pay using the Pay button in the row, the row gets removed and then reappears due to a payment error when reopening the Approved filtered reports. However, when I open the report in RHP and pay there, the row remains visible, and the error is displayed. Can we replicate this behavior when paying directly through the row?

Screen.Recording.2025-02-17.at.12.53.51.mov

Screen.Recording.2025-02-17.at.12.54.08.mov

src/components/OpacityView.tsx

sobitneupane · 2025-02-17T07:24:44Z

@luacmartins While updating the status through RHP, should we close the report in RHP? For example, when I submit a report in Draft, it gets removed from the Draft. Should we close the RHP in this case? IMO, we should keep it open so the user can take multiple steps at once.

Screen.Recording.2025-02-17.at.13.05.48.mov

sobitneupane · 2025-02-17T07:31:12Z

@shawnborton Could you please check the animation?

animation.mov

Screen.Recording.2025-02-17.at.13.12.00.mov

sobitneupane · 2025-02-17T07:37:05Z

@mkzie2 It seems that the required changes for Unapprove and Cancel payment were missed.

sobitneupane

Screenshots/Videos

MacOS: Chrome / Safari

Screen.Recording.2025-02-17.at.12.29.01.mov

Screen.Recording.2025-02-17.at.12.32.38.mov

Screen.Recording.2025-02-17.at.12.35.18.mov

Screen.Recording.2025-02-17.at.12.37.25.mov

Screen.Recording.2025-02-17.at.12.39.34.mov

Screen.Recording.2025-02-17.at.12.42.37.mov

Screen.Recording.2025-02-17.at.12.53.51.mov

Screen.Recording.2025-02-17.at.12.54.08.mov

Screen.Recording.2025-02-17.at.13.05.48.mov

mkzie2 · 2025-02-17T07:51:07Z

When I pay using the Pay button in the row, the row gets removed and then reappears due to a payment error

@sobitneupane How can we get an error while paying?

sobitneupane · 2025-02-17T08:05:28Z

I am getting the following error, so my best guess is that it's because the workspace is linked to the same bank account as my personal account.

luacmartins · 2025-02-25T15:00:25Z

I've asked @Kicu to take a look at this PR since he has a lot of context on Search and can help with the animations too.

Kicu · 2025-02-27T07:28:36Z

I will look at this today before eod Europe timezone :)

Kicu

hey I spend some time trying to understand what is happening here and left some general comments.
There are a few surprising patterns here that I think need further discussions.

My main questions to @mkzie2 is:

can we not spread isAllStatus and hash all over the app? these are search-specific things (Reports in bottom menu) and should stay separate
can you take another look at how to use exiting animation without changing Opacity View

to @luacmartins and @sobitneupane

can we somehow simplify the hash usage? I remember Backend needs hash when running actions from search?
do we have any other patterns where we don't simply accept Onyx data returned from backend but instead build our own data? if no - then this PR should not be the place to introduce this I think (specifically refer to actions/Search lines 299-301)

Kicu · 2025-02-27T12:48:48Z

src/components/MoneyReportHeader.tsx

@@ -163,6 +164,8 @@ function MoneyReportHeader({policy, report: moneyRequestReport, transactionThrea
    const isPayAtEndExpense = isPayAtEndExpenseTransactionUtils(transaction);
    const isArchivedReport = isArchivedReportWithID(moneyRequestReport?.reportID);
    const [archiveReason] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${moneyRequestReport?.reportID}`, {selector: getArchiveReason});
+    const {currentSearchHash, isAllStatus} = useSearchContext();
+    const hash = isAllStatus ? undefined : currentSearchHash;


question to @luacmartins In general why do we have to push search hash to these functions which didn't use them before?
In what contexts does the backend need to use hash?

If I'm correct, the backend is not using the hash, this is purely used by the frontend to build optimistic data

Kicu · 2025-02-27T13:33:21Z

src/components/OpacityView.tsx

            needsOffscreenAlphaCompositing={shouldRenderOffscreen ? needsOffscreenAlphaCompositing : undefined}
+            exiting={shouldAnimateOnRemove ? Exiting : undefined}
+            onLayout={(e) => {


This component (OpacityView) is being used by PressableWithFeedback which is used all over the app in crucial places.
We cannot add an onLayout on this animated component, since it might substantially slow down the app. This will result in multiple setState being run for every pressable component, multiple times.

Is there any other way to add this animation, without affecting OpacityView?

Kicu · 2025-02-27T13:58:28Z

src/pages/ReportDetailsPage.tsx

-        unapproveExpenseReport(moneyRequestReport);
-    }, [isMoneyRequestExported, moneyRequestReport, isDelegateAccessRestricted]);
+        unapproveExpenseReport(moneyRequestReport, isAllStatus ? undefined : currentSearchHash);
+    }, [isDelegateAccessRestricted, isMoneyRequestExported, moneyRequestReport, isAllStatus, currentSearchHash]);


We should really try to not connect Reports that deeply to Search - these features are separate.
It is unfortunate that we need to pass down isAllStatus and currentSearchHash to be able to run animations.

We should try to come up with another way of updating.

Kicu · 2025-02-27T13:59:18Z

src/libs/actions/Search.ts

@@ -343,14 +374,29 @@ function payMoneyRequestOnSearch(hash: number, paymentData: PaymentData[], trans
    ];

    const optimisticData: OnyxUpdate[] = createOnyxData({isActionLoading: true});
-    const failureData: OnyxUpdate[] = createOnyxData({errors: getMicroSecondOnyxErrorWithTranslationKey('common.genericErrorMessage')});
-    const finallyData: OnyxUpdate[] = createOnyxData({isActionLoading: false});
+    const successData: OnyxUpdate[] = isAllStatus


Search context is a bit crowded already, and I wonder if we actually need isAllStatus used in so many places in the app.
Can you write why we need isAllStatus? How does the search status change affect handling onyx data?

Kicu · 2025-02-27T14:03:38Z

src/libs/actions/IOU.ts

@@ -8250,7 +8319,7 @@ function getNextApproverAccountID(report: OnyxEntry<OnyxTypes.Report>, isUnappro
    return getAccountIDsByLogins([nextApproverEmail]).at(0);
 }

-function approveMoneyRequest(expenseReport: OnyxEntry<OnyxTypes.Report>, full?: boolean) {
+function approveMoneyRequest(expenseReport: OnyxEntry<OnyxTypes.Report>, full?: boolean, hash?: number) {


I think it's a mistake to add optional hash to all these actions that are report centric.

These functions should not know about the existence of Search. Up until now everything worked nicely with these functions being separate, and now because of adding an animation when something is removed we are combining them together.
I would consider a different approach.

luacmartins · 2025-02-27T17:13:17Z

can we somehow simplify the hash usage? I remember Backend needs hash when running actions from search?

As far as API requests go, the hash usage should be restricted to the *OnSearch commands, since they actually use the hash to send http data back to the client.

do we have any other patterns where we don't simply accept Onyx data returned from backend but instead build our own data? if no - then this PR should not be the place to introduce this I think (specifically refer to actions/Search lines 299-301)

I think for Search, this is the first place where we build data that is NOT isActionLoading. I've been resistant to this since Search commands only work online and it's transient data so there's no point in optimistically build this data.

luacmartins · 2025-02-25T12:55:20Z

src/components/MoneyReportHeader.tsx

@@ -80,6 +80,7 @@ import MoneyRequestHeaderStatusBar from './MoneyRequestHeaderStatusBar';
 import type {ActionHandledType} from './ProcessMoneyReportHoldMenu';
 import ProcessMoneyReportHoldMenu from './ProcessMoneyReportHoldMenu';
 import ExportWithDropdownMenu from './ReportActionItem/ExportWithDropdownMenu';
+import {useSearchContext} from './Search/SearchContext';


BTW I don't think we should connect this component to Search context since this component is used in the Inbox flow, not Search. I think we need to keep changes contained to the Search components since this is a Search feature

@luacmartins When the user opens the RHP from Search and performs actions like approving or paying a money request, we will need to use the hash to update the search results.

luacmartins · 2025-02-27T17:14:13Z

src/components/MoneyReportHeader.tsx

@@ -163,6 +164,8 @@ function MoneyReportHeader({policy, report: moneyRequestReport, transactionThrea
    const isPayAtEndExpense = isPayAtEndExpenseTransactionUtils(transaction);
    const isArchivedReport = isArchivedReportWithID(moneyRequestReport?.reportID);
    const [archiveReason] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${moneyRequestReport?.reportID}`, {selector: getArchiveReason});
+    const {currentSearchHash, isAllStatus} = useSearchContext();
+    const hash = isAllStatus ? undefined : currentSearchHash;


If I'm correct, the backend is not using the hash, this is purely used by the frontend to build optimistic data

mkzie2 · 2025-02-28T08:52:04Z

@Kicu

My idea in this issue is, we will remove the data from snapshot when we do the action like submit/approve/pay expense in successData, and then we can use exiting from animated view to execute the animation
About isAllStatus, if we do an action in all statuses, we should not remove the data from snapshot that why I need to add this variable.
If we do the action in RHP report, we need to get the current hash and do the same pattern at the point 1 to remove the data from snapshot.

Please let me know if you have a better suggestion. Thanks.

mkzie2 · 2025-03-05T10:13:19Z

@Kicu Any thought in my comment above.

luacmartins · 2025-03-05T13:21:07Z

@Kicu is focused on a different project and unfortunately has no availability to help on this one.

@Kicu Any thought in my comment above.

I'm not sure that I follow the strategy here. Why are we removing data from snapshot when we just update the state/status of the report?

@sobitneupane would you be able to help @mkzie2?

mkzie2 · 2025-03-06T13:41:11Z

I'm not sure that I follow the strategy here. Why are we removing data from snapshot when we just update the state/status of the report?

@luacmartins For example, if we're in the draft and submit a report in search or RHP, this report should be removed from the draft if we submit it successfully. So I removed it in the success data to remove this immediately. If not, it's only removed if we refresh the page.

sobitneupane · 2025-03-06T14:33:51Z

I'll review this PR and explore possible solutions. I'll provide an update as soon as possible.

sobitneupane

From my understanding so far:

Different search results are returned from the backend based on the status.
We need to use searchHash to update the search result stored in local storage.
hash is required on components like MoneyReportHeader and ReportDetailsPage because users can open expense on RHP and perform different actions. To reflect those changes on search results, search results stored in onyx should be updated.
I believe we can avoid the change made in actions/IOU if we use search-specific functions as suggested below.

@luacmartins With the approach suggested by @mkzie2, most of the changes made in the PR seem necessary.

sobitneupane · 2025-03-12T14:52:59Z

src/components/MoneyReportHeader.tsx

@@ -80,6 +80,7 @@ import MoneyRequestHeaderStatusBar from './MoneyRequestHeaderStatusBar';
 import type {ActionHandledType} from './ProcessMoneyReportHoldMenu';
 import ProcessMoneyReportHoldMenu from './ProcessMoneyReportHoldMenu';
 import ExportWithDropdownMenu from './ReportActionItem/ExportWithDropdownMenu';
+import {useSearchContext} from './Search/SearchContext';


@luacmartins When the user opens the RHP from Search and performs actions like approving or paying a money request, we will need to use the hash to update the search results.

sobitneupane · 2025-03-12T14:55:46Z

src/components/MoneyReportHeader.tsx

@@ -236,10 +239,10 @@ function MoneyReportHeader({policy, report: moneyRequestReport, transactionThrea
            } else if (isInvoiceReport(moneyRequestReport)) {
                payInvoice(type, chatReport, moneyRequestReport, payAsBusiness);
            } else {
-                payMoneyRequest(type, chatReport, moneyRequestReport, true);
+                payMoneyRequest(type, chatReport, moneyRequestReport, true, hash);


@mkzie2 an we determine if the Expense Report is being opened from Search? If so, would it be possible to use payMoneyRequestOnSearch instead?

luacmartins · 2025-03-12T17:23:48Z

@luacmartins When the user opens the RHP from Search and performs actions like approving or paying a money request, we will need to use the hash to update the search results.

I'm not sure this is needed. We have live Onyx updates, so any changes made to Onyx data should be reflected in any equivalent snapshot_ data, e.g. if report_1 is modified, any snapshot_<hash>.data.report_1 will be modified as well.

sobitneupane · 2025-03-13T12:30:15Z

I'm not sure this is needed. We have live Onyx updates, so any changes made to Onyx data should be reflected in any equivalent snapshot_ data, e.g. if report_1 is modified, any snapshot_<hash>.data.report_1 will be modified as well.

@luacmartins, that's correct, changes are reflected in the snapshots. However, in our case, we need to remove the report from the snapshot.

We maintain different snapshots based on status. Changes made to the report are reflected in the snapshot, but when we approve an expense report, we need to remove it from the snapshot of outstanding expenses. These snapshots are returned from the backend, and I don’t think any filtering is done on the frontend to determine whether the report belongs to a particular status or not. @mkzie2, could you please verify this?

luacmartins · 2025-03-13T16:10:02Z

Yea, that's correct. Maybe in that case we should just re-trigger the search so update the view then. WDYT?

sobitneupane · 2025-03-14T13:41:54Z

@luacmartins Yup, I believe we can do that.

Should we re-trigger the search after the user closes the RHP? One drawback is that the search will be re-triggered even if the user doesn't perform any action.

@mkzie2 Can we re-trigger the search after the user performs certain actions (like paying, approving, etc.), without requiring the search hash?

mkzie2 · 2025-03-14T14:02:49Z

@mkzie2 Can we re-trigger the search after the user performs certain actions (like paying, approving, etc.), without requiring the search hash?

Let me investigate if we can do that.

mkzie2 · 2025-03-14T14:04:47Z

Now we have two problems that need to be resolved:

Solution to remove the snapshot data when doing the action on search (Have a new idea here)
The exiting animation (Does not have the solution now).

mkzie2 · 2025-03-18T09:44:10Z

@mkzie2 Can we re-trigger the search after the user performs certain actions (like paying, approving, etc.), without requiring the search hash?

@sobitneupane I tested this but it has a problem: If the user select a transaction at index 1, another one at index 51, another one at index 101. Re-trigger the Search API will not remove all of them because the size data of one query is only 50.

cc @luacmartins

mkzie2 · 2025-03-24T18:28:18Z

@sobitneupane Any thought on my comment above.

sobitneupane · 2025-03-25T11:28:27Z

Oops, Sorry. I missed it earlier.

I tested this but it has a problem: If the user select a transaction at index 1, another one at index 51, another one at index 101. Re-trigger the Search API will not remove all of them because the size data of one query is only 50.

I’m not sure I fully understand the case you mentioned. Could you please clarify? We want to re-trigger the search when the user performs an action by opening the report in the RHP.

mkzie2 · 2025-03-26T10:47:01Z

I’m not sure I fully understand the case you mentioned. Could you please clarify? We want to re-trigger the search when the user performs an action by opening the report in the RHP.

@sobitneupane I think it's the same; for example if we select an item with index 2 and the current offset is 100 I think the Search API with this offset will not remove the data we do action.

luacmartins · 2025-03-26T18:23:05Z

Gonna make this a draft while we work on the updated solution

sobitneupane · 2025-03-27T11:57:20Z

I think it's the same; for example if we select an item with index 2 and the current offset is 100 I think the Search API with this offset will not remove the data we do action.

Re-triggering the search would update the entire view. However, a downside is that the user would be sent back to the top of the list, causing the whole list to re-render, which doesn’t seem ideal.

sobitneupane · 2025-03-27T11:59:17Z

@luacmartins This issue is becoming increasingly complicated.

The PR and idea proposed by @mkzie2 are mainly based on spreading search-specific elements like isAllStatus and hash across IOU functions. If we’re against this approach (as suggested by kicu in this comment), we should consider dropping the PR and opening the issue for new proposals.

luacmartins · 2025-03-27T18:32:04Z

I agree. Let's do that. Sorry @mkzie2, but let's start fresh with a new proposal for this since the current one is not acceptable.

mkzie2 added 8 commits January 17, 2025 16:21

add animation when removing an item

9403e10

Merge branch 'main' into mkzie2-issue/55211

93a5bb6

Merge branch 'main' into mkzie2-issue/55211

e5b6e88

update action in RHP

b93259e

Merge branch 'main' into mkzie2-issue/55211

8c74944

implement update snapshot for submit, approve, pay

969c67e

add dependency

88a7cb7

fix lint error

f368c6a

mkzie2 marked this pull request as ready for review February 12, 2025 17:14

mkzie2 requested a review from a team as a code owner February 12, 2025 17:14

melvin-bot bot requested review from sobitneupane and removed request for a team February 12, 2025 17:14

mkzie2 mentioned this pull request Feb 12, 2025

[$1,000] Update Search/Reports page immediately following report actions #55211

Open

luacmartins self-requested a review February 12, 2025 17:49

luacmartins reviewed Feb 13, 2025

View reviewed changes

merge main

89d9e3c

luacmartins self-requested a review February 14, 2025 17:13

sobitneupane reviewed Feb 17, 2025

View reviewed changes

src/components/OpacityView.tsx Outdated Show resolved Hide resolved

mkzie2 added 2 commits February 17, 2025 14:33

rename prop

e8fb90a

merge main

8331371

sobitneupane reviewed Feb 17, 2025

View reviewed changes

add snapshot onyx data for unapprove and cancel payment

5267b72

mkzie2 added 3 commits February 25, 2025 12:20

Merge branch 'main' into mkzie2-issue/55211

34b7df9

remove layout prop

c02965b

fix lint

43f935b

Kicu suggested changes Feb 27, 2025

View reviewed changes

luacmartins reviewed Feb 27, 2025

View reviewed changes

sobitneupane reviewed Mar 12, 2025

View reviewed changes

luacmartins marked this pull request as draft March 26, 2025 18:23

luacmartins closed this Mar 27, 2025

feat: update Search/Reports page immediately following report actions #56772

feat: update Search/Reports page immediately following report actions #56772

Uh oh!

Conversation

mkzie2 commented Feb 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Explanation of Change

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

Uh oh!

melvin-bot bot commented Feb 12, 2025

Uh oh!

luacmartins left a comment

Choose a reason for hiding this comment

Uh oh!

mkzie2 commented Feb 14, 2025

Uh oh!

luacmartins commented Feb 14, 2025

Uh oh!

sobitneupane left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

sobitneupane commented Feb 17, 2025

Uh oh!

sobitneupane commented Feb 17, 2025

Uh oh!

sobitneupane commented Feb 17, 2025

Uh oh!

sobitneupane left a comment

Choose a reason for hiding this comment

Screenshots/Videos

Uh oh!

mkzie2 commented Feb 17, 2025

Uh oh!

sobitneupane commented Feb 17, 2025

Uh oh!

luacmartins commented Feb 25, 2025

Uh oh!

Kicu commented Feb 27, 2025

Uh oh!

Kicu left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

luacmartins commented Feb 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mkzie2 commented Feb 28, 2025

Uh oh!

mkzie2 commented Mar 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

luacmartins commented Mar 5, 2025

Uh oh!

mkzie2 commented Mar 6, 2025

Uh oh!

sobitneupane commented Mar 6, 2025

Uh oh!

mkzie2 commented Feb 12, 2025 •

edited

Loading

luacmartins commented Feb 27, 2025 •

edited

Loading

mkzie2 commented Mar 5, 2025 •

edited

Loading

sobitneupane left a comment •

edited

Loading

luacmartins commented Mar 13, 2025 •

edited

Loading