[Search v2] Add displaying advanced filter values and type/status by Kicu · Pull Request #46022 · Expensify/App

Kicu · 2024-07-23T14:08:56Z

Details

This is another step in partial implementation of Advanced Search filters.

~~Waiting for merging of: #45756 and #45617~~

This PR does:

adds page + input for type filter (we support only 1 type for now)
adds page + input for status filter
adds displaying values for filters on the advanced filters page
adds ViewResults button that generates string query

What is not done:

the default state for form is always empty, and for now will stay
in a separate PR we will start to use the values from query for default values of form

Notes:

SearchFiltersStatusPage and SearchFiltersTypePage are extremely similar, but before extracting common code I want to see some more pages
I can't simply use ValuePicker because it renders an extra screen and requires extra click, whereas we need the list of options directly on Page

Fixed Issues

$ #45026
$ #46029
$ #46028
PROPOSAL:

Tests

visit route /search/filters
(currently view is not ready so there is no navigation for this; on web use URL on mobile use deeplink)
test that all 3 filters and navigation behave correctly
after clicking "View Results" verify that URL is updated with query encoded with all the filter values chosen by user

Offline tests

QA Steps

visit route /search/filters
(currently view is not ready so there is no navigation for this; on web use URL on mobile use deeplink)
test that all 3 filters and navigation behave correctly
after clicking "View Results" verify that URL is updated with query encoded with all the filter values chosen by user

PR Author Checklist

Screenshots/Videos

Android: Native

rec-andr-filtervals.mp4

Android: mWeb Chrome

// had problems running on android

iOS: Native

rec-ios-filtervals.mp4

iOS: mWeb Safari

MacOS: Chrome / Safari

rec-web-filtervals.mp4

MacOS: Desktop

Kicu · 2024-07-24T14:12:09Z

@luacmartins this is basically done, but I need code from date filter: #45756
so you could take a quick look if you want, as soon as the date filter is merged this will be ready.

I'm also moving the conversation about form/input flows here.
Re: your comment here: #45756 (comment)

[..] reason for the date filter (and some others) to have their own route/page is because they are a bit special

I've handled this for type and status by not using ValuePicker and just directly using Selection List. The main reason is that in AdvancedFilters component I want all the fields to look the same - that is - be MenuItems which navigate.

I don't think its good practice to have some of them be menu items which navigate, while some be FormInputs that navigate within their own flow.

We already do it like that for example here: ReportSettings has a button with redirects: https://github.com/Expensify/App/blob/main/src/pages/settings/Report/ReportSettingsPage.tsx#L63
redirects here to a page with List: https://github.com/Expensify/App/blob/main/src/pages/settings/Report/NotificationPreferencePage.tsx#L40-L52

melvin-bot · 2024-07-24T17:14:43Z

@rayane-djouah 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]

Kicu · 2024-07-24T17:20:18Z

Even though the whole filters are kinda dependent on #45617 this PR works as-is and can be reviewed
@rayane-djouah @luacmartins

luacmartins · 2024-07-24T18:50:11Z

src/CONST.ts

+        TYPE: {
+            EXPENSES: 'expenses',
+        },


Can we move this to DATA_TYPES and use singular expense please?

Ahh sorry unfortunately that won't work. DATA_TYPES are connected via typedefinition with the mechanism of rendering data in lists in SearchUtils:

https://github.com/Expensify/App/blob/main/src/libs/SearchUtils.ts#L218

If I add expense to this const, then I would have to implement all these functions for displaying an expense. So let's keep them as TYPE I think?

Btw this beautifully shows us that we have too many "types" that mean different things 😉

src/pages/Search/SearchFiltersStatusPage.tsx

src/pages/Search/AdvancedSearchFilters.tsx

Kicu · 2024-07-25T07:52:43Z

@luacmartins pushed some of your changes. How about we wait with the CONST changes for Adam's PR to be merged, I will make sure that whatever was done there will be the final version.

rayane-d · 2024-07-25T13:18:25Z

Reviewer Checklist

I have verified the author checklist is complete (all boxes are checked off).
I verified the correct issue is linked in the ### Fixed Issues section above
I verified testing steps are clear and they cover the changes made in this PR
- I verified the steps for local testing are in the Tests section
- I verified the steps for Staging and/or Production testing are in the QA steps section
- I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
- I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
I checked that screenshots or videos are included for tests on all platforms
I included screenshots or videos for tests on all platforms
I verified tests pass on all platforms & I tested again on:
- Android: Native
- Android: mWeb Chrome
- iOS: Native
- iOS: mWeb Safari
- MacOS: Chrome / Safari
- MacOS: Desktop
If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
I verified proper code patterns were followed (see Reviewing the code)
- I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
- I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
- I verified that comments were added to code that is not self explanatory
- I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
- I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
- I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
- I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
- I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
- I verified the JSDocs style guidelines (in STYLE.md) were followed
If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
I verified that this PR follows the guidelines as stated in the Review Guidelines
I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
If a new component is created I verified that:
- A similar component doesn't exist in the codebase
- All props are defined accurately and each prop has a /** comment above it */
- The file is named correctly
- The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
- The only data being stored in the state is data necessary for rendering and nothing else
- For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
- Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
- All JSX used for rendering exists in the render method
- The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
If any new file was added I verified that:
- The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
If a new CSS style is added I verified that:
- A similar style doesn't already exist
- The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
- I verified that all the inputs inside a form are aligned with each other.
- I added Design label and/or tagged @Expensify/design so the design team can review the changes.
If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Screen.Recording.2024-07-29.at.4.34.17.PM.mov

Android: mWeb Chrome

Screen.Recording.2024-07-29.at.4.29.59.PM.mov

iOS: Native

Simulator.Screen.Recording.-.iPhone.15.Pro.Max.-.2024-07-29.at.16.32.41.mp4

iOS: mWeb Safari

Simulator.Screen.Recording.-.iPhone.15.Pro.Max.-.2024-07-29.at.16.28.45.mp4

MacOS: Chrome / Safari

Screen.Recording.2024-07-29.at.4.24.51.PM.mov

MacOS: Desktop

Screen.Recording.2024-07-29.at.4.28.07.PM.mov

rayane-d · 2024-07-25T13:10:58Z

src/pages/Search/AdvancedSearchFilters.tsx

-    // TODO once we have values from query, this value should be `filters[fieldName].value`
-    return fieldName;
+// the values of dateBefore+dateAfter map to just a single 'date' field on advanced filters
+type AvailableFilters = ValueOf<typeof INPUT_IDS> | 'date';


I think it's better if we define the available filter names as constants in the CONST file, like this:

in CONST.SEARCH add:

ADVANCED_SEARCH_FILTERS: { FIELDS_NAMES: { DATE: 'date', ... }, },

Then, use ValueOf<typeof CONST.ADVANCED_SEARCH_FILTERS.FIELDS_NAMES> and replace the hardcoded values with the constants.

So you suggest I have both the INPUT_IDS and also ADVANCED_SEARCH_FILTERS and use them here?

Btw this is most likely the only case where there are 2 inputs that map to 1 filter, because the actual filter will be date > xxxx and date < yyyy.
I think all the other filters will map 1-to-1 filter name to input.

Maybe we can define it as follows:

const FIELDS_NAMES = Object.entries(INPUT_IDS).reduce<Record<string, string>>((fields, [key, value]) => { if (key === INPUT_IDS.DATE_AFTER || key === INPUT_IDS.DATE_BEFORE) { fields.DATE = 'date'; } else { fields[key] = value; } return fields; }, {}); type AvailableFilters = ValueOf<typeof FIELDS_NAMES>;

My concern here is to avoid using hardcoded values when referencing getFilterDisplayTitle, we should be using FIELDS_NAMES const instead.

@rayane-djouah after we merged the other PR with new query/syntax - CONSTs were modified, and now I can use better more fitting consts specific to query here.
So I didn't do it your way, but there will be no hardcoded values used here anymore

luacmartins · 2024-07-25T18:30:32Z

Nice, now that the syntax PR is merged, let's update this one to work with that!

src/pages/Search/SearchFiltersTypePage.tsx

rayane-d · 2024-07-25T18:14:07Z

src/pages/Search/AdvancedSearchFilters.tsx

-    // TODO once we have values from query, this value should be `filters[fieldName].value`
-    return fieldName;
+// the values of dateBefore+dateAfter map to just a single 'date' field on advanced filters
+type AvailableFilters = ValueOf<typeof INPUT_IDS> | 'date';


Maybe we can define it as follows:

const FIELDS_NAMES = Object.entries(INPUT_IDS).reduce<Record<string, string>>((fields, [key, value]) => { if (key === INPUT_IDS.DATE_AFTER || key === INPUT_IDS.DATE_BEFORE) { fields.DATE = 'date'; } else { fields[key] = value; } return fields; }, {}); type AvailableFilters = ValueOf<typeof FIELDS_NAMES>;

My concern here is to avoid using hardcoded values when referencing getFilterDisplayTitle, we should be using FIELDS_NAMES const instead.

rayane-d · 2024-07-25T18:17:27Z

src/pages/Search/AdvancedSearchFilters.tsx

        () => [
            {
-                title: getFilterDisplayTitle({}, 'title'),
+                title: getFilterDisplayTitle(searchAdvancedFilters, 'type', translate),


For example, here we can use FIELDS_NAMES.TYPE instead of 'type'

src/pages/Search/SearchFiltersStatusPage.tsx

rayane-d · 2024-07-25T19:21:49Z

Bug 1: "Expense" option is focused initially and has a green check icon even if it's not selected

Screen.Recording.2024-07-25.at.8.10.00.PM.mov

Bug 2: All status options have a green check icon (I believe only the selected one should have this icon)

Screen.Recording.2024-07-25.at.8.10.34.PM.mov

Bug 3: Status is not updated in Onyx and in the advanced filters page

Screen.Recording.2024-07-25.at.8.10.43.PM.mov

rayane-d · 2024-07-25T19:27:31Z

There are conflicts

luacmartins · 2024-07-25T21:20:00Z

Bug 1: "Expense" option is focused initially and has a green check icon even if it's not selected

I think this one is expected. Expense is the default type and we should always have a selected type (even if not in the query itself)

rayane-d · 2024-07-25T21:29:17Z

Bug 1: "Expense" option is focused initially and has a green check icon even if it's not selected

I think this one is expected. Expense is the default type and we should always have a selected type (even if not in the query itself)

Hm, in this case it should be also selected by default in the menu item in the advanced filters page:

luacmartins · 2024-07-25T21:30:25Z

Yea, I agree with that. Same goes for status, if nothing is selected All is the default

Kicu · 2024-07-26T13:42:44Z

I fixed some of the comments but not all of them, will continue on Monday, please don't re-review yet.

Kicu · 2024-07-29T11:24:39Z

@rayane-djouah ready for re-review. However tested only on web now, since native builds take a lot of time. Will test on native later and update this comment.

I'm not able to reproduce any of the 3 bugs you mentioned - I hope they are all fixed.

What should and should NOT work:

View button should work and update the query after clicking
initially all filter values will be empty when entering the view. That is expected because filter values will come only from onyx form data
on a separate PR I will parse the query value and set onyx form fields - then we will have all the initial values set correctly

CC @luacmartins
Also this PR keeps growing so I would like to merge it in this state (of course unless there are bugs). There are 2 more people that could be doing more filters in parallel and this is a blocker since this PR displays the values of selected filters.

I will clean and fix whatever else in separate PRs :)

rayane-d · 2024-07-29T11:42:41Z

src/pages/Search/AdvancedSearchFilters.tsx

-    // TODO once we have values from query, this value should be `filters[fieldName].value`
-    return fieldName;
+function getFilterDisplayTitle(filters: Partial<SearchAdvancedFiltersForm>, fieldName: AdvancedFiltersKeys, translate: LocaleContextProps['translate']) {
+    if (fieldName === 'date') {


Suggested change

if (fieldName === 'date') {

if (fieldName === CONST.SEARCH.SYNTAX_FILTER_KEYS.DATE) {

rayane-d · 2024-07-29T12:15:59Z

src/libs/SearchUtils.ts

+    const dateBefore = filterValues[INPUT_IDS.DATE_BEFORE];
+    const dateAfter = filterValues[INPUT_IDS.DATE_AFTER];
+
+    let dateFilter = '';
+    if (dateBefore) {
+        dateFilter += `${CONST.SEARCH.SYNTAX_FILTER_KEYS.DATE}<${dateBefore}`;
+    }
+    if (dateBefore && dateAfter) {
+        dateFilter += ' ';
+    }
+    if (dateAfter) {
+        dateFilter += `${CONST.SEARCH.SYNTAX_FILTER_KEYS.DATE}>${dateAfter}`;
+    }


NAB: We can simplify buildQueryStringFromFilters function by extracting the date handling logic to a new buildDateFilterQuery function

rayane-d

Bug 4: Results are not correctly filtered by date

Screen.Recording.2024-07-29.at.1.29.59.PM.mov

rayane-d · 2024-07-29T12:49:03Z

@Kicu - Could you please update the test steps in the author checklist to make it clear for the QA team. I think this is not relevant anymore:

view results doesn't work yet

rayane-d · 2024-07-29T14:44:42Z

src/pages/Search/AdvancedSearchFilters.tsx

+                buttonText={translate('search.viewResults')}
+                containerStyles={[styles.m4]}
+                onSubmit={onFormSubmit}
+            />


I think that the "View results" button should not be disabled offline. based on OfflineUX_Patterns_Flowchart, No offline pattern is needed here.

Suggested change

/>

enabledWhenOffline

/>

I think we can keep it as is for now so that we don't block other issues, but I think we should disable it offline because the Search API command only works while the user is online.

Kicu · 2024-07-29T15:07:19Z

@rayane-djouah code comments fixed.

About Bug 4 the filtering does not happen because I don't yet send values for the filters in the backend call to Search. Actually I'm not sure if I should handle calling api using the new jsonQuery format inside this PR or not yet.
@luacmartins what do you think? could we perhaps move it to a separate PR?
Technically these filters are still under construction and don't yet work 100%

luacmartins · 2024-07-29T15:32:08Z

I think it's fine to handle that in a follow up.

rayane-d

looks good! last comment

rayane-d · 2024-07-29T15:19:18Z

src/pages/Search/AdvancedSearchFilters.tsx

+        [searchAdvancedFilters, translate],
    );

+    const onFormSubmit = () => {


NAB:

Suggested change

const onFormSubmit = () => {

const openResults = () => {

From the Reviewer Checklist:

I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).

rayane-d · 2024-07-29T15:46:54Z

cc @Expensify/design to review the new pages design

Screenshots/Videos

Android: Native

Screen.Recording.2024-07-29.at.4.34.17.PM.mov

Android: mWeb Chrome

Screen.Recording.2024-07-29.at.4.29.59.PM.mov

iOS: Native

Simulator.Screen.Recording.-.iPhone.15.Pro.Max.-.2024-07-29.at.16.32.41.mp4

iOS: mWeb Safari

Simulator.Screen.Recording.-.iPhone.15.Pro.Max.-.2024-07-29.at.16.28.45.mp4

MacOS: Chrome / Safari

Screen.Recording.2024-07-29.at.4.24.51.PM.mov

MacOS: Desktop

Screen.Recording.2024-07-29.at.4.28.07.PM.mov

luacmartins

LGTM and tests well. Let's address the pending comments in a follow up

luacmartins · 2024-07-29T15:34:10Z

src/CONST.ts

+        TYPE: {
+            EXPENSE: 'expense',
+        },


NAB we should eventually move this to CONST.SEARCH.DATA_TYPES.EXPENSE and get rid of transactions and reports. We'll do so as part of v2.2.

luacmartins · 2024-07-29T15:36:57Z

src/libs/SearchUtils.ts

+ * Given object with chosen search filters builds correct query string from them
+ */
+function buildQueryStringFromFilters(filterValues: Partial<SearchAdvancedFiltersForm>) {
+    // TODO add handling of multiple values picked


Suggested change

// TODO add handling of multiple values picked

rayane-d

LGTM and tests well

luacmartins

LGTM!

OSBotify · 2024-07-29T16:00:55Z

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

OSBotify · 2024-07-29T19:31:13Z

🚀 Cherry-picked to staging by https://github.com/roryabraham in version: 9.0.14-1 🚀

platform	result
🤖 android 🤖	success ✅
🖥 desktop 🖥	success ✅
🍎 iOS 🍎	success ✅
🕸 web 🕸	success ✅

@Expensify/applauseleads please QA this PR and check it off on the deploy checklist if it passes.

OSBotify · 2024-07-31T19:41:08Z

🚀 Deployed to production by https://github.com/roryabraham in version: 9.0.14-6 🚀

platform	result
🤖 android 🤖	success ✅
🖥 desktop 🖥	success ✅
🍎 iOS 🍎	success ✅
🕸 web 🕸	success ✅

luacmartins self-requested a review July 23, 2024 16:35

This was referenced Jul 24, 2024

[HOLD for payment 2024-08-07] [Search v2.1] [App] Create Type filter #46028

Closed

[HOLD for payment 2024-08-07] [$250] [Search v2.1] [App] Create Status filter #46029

Closed

Kicu force-pushed the kicu/45026-advanced-filter-values branch from 346b968 to b8c4643 Compare July 24, 2024 10:08

Kicu force-pushed the kicu/45026-advanced-filter-values branch from b8c4643 to 22481db Compare July 24, 2024 14:51

Kicu added 5 commits July 24, 2024 19:12

Add displaying chosen date advanced filters value

346a55c

Update search filters type page

22693d4

Finalize SearchFiltersTypePage with correct input UI

9927d4a

Add status advanced filter for Search

422d75c

Improve styling of advanced search filters

9aa2ffb

Kicu force-pushed the kicu/45026-advanced-filter-values branch from 22481db to 9aa2ffb Compare July 24, 2024 17:12

Kicu marked this pull request as ready for review July 24, 2024 17:14

Kicu requested a review from a team as a code owner July 24, 2024 17:14

melvin-bot bot removed the request for review from a team July 24, 2024 17:14

melvin-bot bot requested a review from rayane-d July 24, 2024 17:14

luacmartins changed the title ~~[Search] Add displaying advanced filter values and type/status~~ [Search v2] Add displaying advanced filter values and type/status Jul 24, 2024

luacmartins requested changes Jul 24, 2024

View reviewed changes

Add small fixes to Search after review

e373c47

Merge branch 'main' into kicu/45026-advanced-filter-values

c08eec0

rayane-d suggested changes Jul 25, 2024

View reviewed changes

Merge branch 'main' into kicu/45026-advanced-filter-values

173b619

Kicu mentioned this pull request Jul 26, 2024

advanced filters category #46197

Merged

50 tasks

Improve usage of CONSTs for Search Filters

b7387c0

Kicu added 2 commits July 29, 2024 12:10

add handling of search query from advanced filters

5efe081

Merge branch 'main' into kicu/45026-advanced-filter-values

1496f73

Merge branch 'main' into kicu/45026-advanced-filter-values

2c95ef2

rayane-d suggested changes Jul 29, 2024

View reviewed changes

rayane-d reviewed Jul 29, 2024

View reviewed changes

rayane-d suggested changes Jul 29, 2024

View reviewed changes

add small fixes to search filters after review

153102f

rayane-d suggested changes Jul 29, 2024

View reviewed changes

luacmartins approved these changes Jul 29, 2024

View reviewed changes

rayane-d approved these changes Jul 29, 2024

View reviewed changes

melvin-bot bot requested a review from luacmartins July 29, 2024 15:49

luacmartins merged commit b4c46f2 into Expensify:main Jul 29, 2024

luacmartins reviewed Jul 29, 2024

View reviewed changes

github-actions bot mentioned this pull request Jul 29, 2024

Deploy Checklist: New Expensify 2024-07-29 #46436

Closed

84 tasks

luacmartins mentioned this pull request Jul 29, 2024

Incorrect CP messages are showing up #46442

Closed

melvin-bot bot mentioned this pull request Jul 31, 2024

[HOLD for payment 2024-08-07] [Search v2.1] [App] Create advanced filters #45026

Closed

1 task

	if (fieldName === 'date') {
	if (fieldName === CONST.SEARCH.SYNTAX_FILTER_KEYS.DATE) {

Conversation

Kicu commented Jul 23, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Details

This PR does:

What is not done:

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

Uh oh!

Kicu commented Jul 24, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

melvin-bot bot commented Jul 24, 2024

Uh oh!

Kicu commented Jul 24, 2024 • 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!

Kicu Jul 25, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Kicu commented Jul 25, 2024

Uh oh!

rayane-d commented Jul 25, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Reviewer Checklist

Screenshots/Videos

Uh oh!

rayane-d Jul 25, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

Kicu Jul 29, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

luacmartins commented Jul 25, 2024

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

rayane-d commented Jul 25, 2024

Uh oh!

rayane-d commented Jul 25, 2024

Uh oh!

luacmartins commented Jul 25, 2024

Uh oh!

rayane-d commented Jul 25, 2024

Uh oh!

luacmartins commented Jul 25, 2024

Uh oh!

Kicu commented Jul 26, 2024

Uh oh!

Kicu commented Jul 29, 2024 • 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!

rayane-d left a comment

Choose a reason for hiding this comment

Uh oh!

rayane-d commented Jul 29, 2024

Kicu commented Jul 23, 2024 •

edited

Loading

Kicu commented Jul 24, 2024 •

edited

Loading

Kicu commented Jul 24, 2024 •

edited

Loading

Kicu Jul 25, 2024 •

edited

Loading

rayane-d commented Jul 25, 2024 •

edited

Loading

rayane-d Jul 25, 2024 •

edited

Loading

Kicu Jul 29, 2024 •

edited

Loading

Kicu commented Jul 29, 2024 •

edited

Loading

rayane-d Jul 29, 2024 •

edited

Loading

Kicu commented Jul 29, 2024 •

edited

Loading

rayane-d Jul 29, 2024 •

edited

Loading