Description

Allow users to view their history of reports. This read-only feature provides users with transparency into their reporting activity, enhancing their experience and accountability on our platform.

Issue Details

1. User Report History: Currently, our application lacks a dedicated feature for users to view their history of reports.

Expected Behavior

Users should have the ability to access and view their report history. This feature allows users to see a list of reports they've submitted in the past, promoting transparency and accountability.

Acceptance Criteria

• Implement a feature that allows users to view their history of reports.
• The report history page should be read-only, meaning users can view the reports they've submitted but cannot modify them.
• Users should be able to access their report history from their profile or account settings.

Implementation Guidelines

• Create a user-friendly interface for accessing the report history.
• Develop the logic to retrieve and display the user's report history.
• Ensure that the report history is presented in a clear and organized manner.

Is there a way to prevent the use of profane language on this website? Right now, users can use such language on offers/requests and user Display Name.

What the business team can do is come up with a list of profane terms/phrases which can be used to automatically prevent those posts/Display names.

Description

Allow users to search for posts that contain specific keywords on the posts page. This search functionality will enhance the user experience and enable users to find relevant content more efficiently.

Issue Details

1. Posts Page: Our application features a page that displays various posts from users.
2. There is no way to search any post at the moment using text.

Expected Behavior

Users should have the capability to search for posts containing specific keywords. This search feature will help users find content that matches their interests or needs.

Acceptance Criteria

• Users should be able to enter keywords in a search input field on the posts page.
• The search should return a list of posts that contain the entered keywords.
• The search results should be displayed in a user-friendly manner, and users should be able to click on a post to view its details.
• Efficiently searches mongodb documents and utilizes indexes effectively.
  • Test with seeder parameter of 1000 users (total of 1000 * 3), 500 posts (total of 500 * 3 * 2) - can take a while to seed.
• Search bar is reusable in any page for any type of posts table views.

Implementation Guidelines

• Integrate a search input field on the posts page.
• Implement the logic to perform searches based on the entered keywords.
• Ensure that the search results are displayed on the same table, but also ensure the user is able to "exit" the search mode.

The "About" page isn't loading on the mobile version of the website. I've sent you a video about this on Signal.

Below is the information that I think a user must input for registration. It'll be different for organization vs individual. I've created a preliminary design on Figma for registration https://www.figma.com/file/gfy3OdNXAnNhsJCijCZ4Iw/Donations-Trackers?type=design&node-id=0%3A1&t=mRLr2JJl7TqX6va4-1, but honestly this is just a suggestion. I'm assuming the design may depend on the authentication program we use; the design doesn't matter as long as we can collect the required user information.

*indicates that admin approval is required if the user wants to change that info (#21 )

Individual Users

*Personal information: First Name, Last Name (I'm still debating on whether we should ask for birthday. On one hand we should check for age, but on the other hand there is no practical way for us to check if that's correct).
Email
Password (+ verify password as well)

Organizations

*Organization name
*Organization address (Ask for street address, not just postal code)
Email
Password (+ verify password as well)

Description

Add a "Help" or "?" button to clarify the purpose of the "Select a Date" filter. This enhancement aims to improve user understanding and usability when they are filtering posts.

Issue Details

1. Filter Functionality: The "Select a Date" filter is currently available in the application, but its purpose may not be immediately clear to all users.

Expected Behavior

Introduce a "Help" or "?" button (disabled) next to the "Select a Date" filter, which, when clicked or hovered, displays a tooltip or pop-up with an explanation of the filter's purpose and how to use it effectively.

Additional Context

Enhancing user guidance by providing tooltips or information about filter functionality can improve user experience and help users make the most of the available features.

Acceptance Criteria

• A "Help" or "?" button is added next to the "Select a Date" filter.
• Clicking the "Help" or "?" button displays a tooltip or pop-up with a clear explanation of the filter's purpose and usage.

Implementation Guidelines

• Modify the user interface to include the "Help" or "?" button.
• Implement the logic to show the tooltip or pop-up when the button is clicked/hovered.
• Ensure the tooltip content is informative and user-friendly.

Could there be a feature on the "My Account" page (see issue "Pages") where users can update their information? Also, could we design it so that when an update is done, the admin would have to approve the updated information (similar to when the user registers the first time)?

Currently, the project uses user front platform for user management. Consider using passport instead.

Description

Post descriptions are not displaying on the post details page.

Issue Details

1. Post Details Page: When users navigate to the post details page, the post descriptions are not being displayed as expected.

Expected Behaviour

On the post details page, the description of a post should be prominently displayed, providing users with important information about the post's content and purpose.

Additional Context

The absence of post descriptions on the post details page hampers users' ability to understand the content and context of each post. It is crucial for providing a meaningful user experience.

Acceptance Criteria

• Post descriptions should be displayed on the post details page.
• The description should be rendered correctly and legibly.

Implementation Guidelines

• Review the code responsible for rendering post details.
• Ensure that the description data is properly retrieved and displayed.
• Test the fix in different scenarios to confirm that it works as expected.

When an account is trying to make a post using the "other" category, the user's post will be sent to a post inbox only accessible by admins.
The post will then have a list of restrictions put upon it until approved by admins (done to ensure that the item being offered/requested is appropriate). The restrictions acted on the "other" category post will include the following:

• Post is hidden from the public posts page
• Post will be inaccessible
• The public/other users will not be able to interact with the pre-approved "other" post (excluding admins)
• Post will not show up on the map located on the "home" page

The user will also be notified that their post is awaiting approval through e-mail (to ensure that there is no confusion as to where their post went). The e-mail will include the following:

• Description of where their post has gone/why it is not public
• Explanation of why this precaution was taken for posts made with the "other" category

If/when the post gets approved by the admins the following will occur:

• The previously mentioned restrictions will be removed
• The user that made the post will be notified by e-mail that their post has been approved and has been made open to the public

If the "other" category post is disapproved, the following will occur:

• The post will be flagged and removed (thus permanently inaccessible/hidden from the public)
• The user that made the original "other" category post will be contacted through e-mail and told that their post has been disapproved and removed by the admins
• A short explanation as to why the user's post was disapproved will be attached to the e-mail

Description

Create a reusable toast notification component that can be utilized on any page. This component will enhance user communication and user experience by providing a consistent way to display notifications across the application.

Issue Details

1 Toast Notification Component: We need to develop a versatile toast notification component that can be easily integrated into any page within our application.

Expected Behavior

The toast notification component should allow developers to display notifications with various types (success, error, info, etc.) and duration. It should be designed for reusability and customization. This should also utilize hooks or context. The toast notifications should be stackable.

Additional Context

A reusable toast notification component simplifies the process of notifying users about events or actions within our application, ensuring a consistent and user-friendly experience.

Acceptance Criteria

• The toast notification component should be created, providing a standardized way to display notifications.
• Developers should be able to customize the content, type, and duration of notifications using the component.
• Documentation should be provided in the component code file on how to use the component.

Implementation Guidelines

• Develop the toast notification component with appropriate props for customization.
• Ensure that the component is easily integratble into any page.
• Provide documentation and examples on how to use the component.

Description

Add a pricing filter component to the posts table, similar to Amazon's pricing filter. This feature will enable users to filter and find posts based on their specified price range, improving their experience and content discoverability.

Issue Details

1. Posts Table: Our application includes a table that displays various posts from users.
2. Posts tables are used in many different pages including users' dashboard, but there is no easy way to filter items by price.

Expected Behavior

Users should have the ability to filter posts based on their desired price range. The pricing filter component will allow users to refine their search results and find posts within their budget.

Acceptance Criteria

• Implement a pricing filter component on the posts table, similar to Amazon's pricing filter.
• Users should be able to set a minimum and maximum price to filter posts.
• The filter should provide real-time results that match the specified price range.
• All the existing backend APIs for paginated posts are extended to filter by price.

Implementation Guidelines

• Integrate a pricing filter component into the posts table.
• Develop the logic to filter posts based on the specified price range.
• Ensure that the filter component provides a user-friendly interface and responsive filtering.
• Ensure that existing paginated APIs are compatible.

Description

There is a bug where the "x Reports Outstanding" token in the "Manage Reported Posts" table is not updating as expected. To resolve this issue, it's necessary to invalidate the RTK Query cache, triggering an update of this token.

Issue Details

1. Manage Reported Posts Table: The "Manage Reported Posts" table displays the number of reports outstanding, indicating how many reports need attention.

Expected Behavior

The "x Reports Outstanding" token should update in real-time as reports are processed. This ensures that administrators have an accurate and up-to-date view of pending reports.

Additional Context

An outdated token can lead to confusion and a lack of clarity for administrators regarding the number of reports that require attention. Invalidating the RTK Query cache is a necessary step to ensure real-time updates.

Acceptance Criteria

• The "x Reports Outstanding" token should be updated in real-time as reports are processed in the "Manage Reported Posts" table.

Implementation Guidelines:

• Review the code responsible for fetching and displaying the "x Reports Outstanding" token.
• Implement logic to invalidate the RTK Query cache when reports are processed, ensuring that the token updates accordingly.

Description

Allow organization users to use their organization name as their display name. This change will eliminate the requirement for a separate "display name" for organization users upon registration.

Issue Details

1. Display Name Requirement: Currently, organization users are required to provide a display name distinct from their organization name.

Expected Behavior

For organization users, the organization name should serve as their default display name, removing the need for an additional input for display name.

Additional Context

Allowing organization users to use their organization name as their display name simplifies the registration and user management process, aligning it with typical organizational practices.

Acceptance Criteria

• Organization users should not be required to provide a separate display name.
• The organization name should be automatically used as the default display name for organization users.
• Organization users should not be able to modify the display name in any account settings page.

Implementation Guidelines

• Review the registration and user management code to accommodate this change.
• Implement logic that sets the organization name as the default display name for organization users.
• Update the user interface to reflect this change.

Right now, users are allowed to input the postal code as A#A #A# or A#A#A# (i.e. with and without space). I'm not sure if this is something that can be managed at the back-end, but do we want to restrict users to a single format? I don't mind which option we go with (space, no space, or both).

From our previous discussion, we decided that individual users would only be allowed to offer products/donations.
However, right now individual users can make requests.

• "Make a request" is available.
• "My posts" has "Requests" tab.

We can either eliminate these options altogether for individual users. Or, when the individual user clicks on those features, we can have a pop-up saying this is only allowed for organization users. I don't mind which option we go with.

Description

Restrict individual users from making "requests" and allow them to only "offer" within the application. This change is aimed at fostering a culture of contributions rather than making requests as an individual.

Individual user here means Individual user type instead of organization user.

Expected Behavior

1. Individual users should be prevented from creating "request" posts.
2. Individuals users should only be able to create "offer" posts.

Acceptance Criteria

• individual users are unable to create "request" posts
• individual users are able to create "offer" posts
• individual users do not see "My requests" in their dashboard
• individual users do not see "Make a request" on user profile dropdown

The current designs look great as they are! There are only a few things to add and address.

1. Could we change the "New Offer" to "Make Offer" to align with "Make Request"? (just for consistency)
2. For "New/Make Offer", could we add a section to add a photo(s) of the product? This will allow users to check for product condition, etc. We can limit the file size/type.
3. For both "Make Offer" and "Make Request", could we add an "Additional Information" section where users can note down any important info/concerns about the product? The difference between this section and "Description" is that "Description" would be more about specific product information (e.g. KN-95 masks), and "Additional Information" would be broader (e.g. the masks are slightly damaged; the canned corn expires on MM/DD/YY).
4. We need to add options to sell or purchase the products on the website. We can discuss this more in detail during the next meeting, but I've created the preliminary design on the Figma https://www.figma.com/file/gfy3OdNXAnNhsJCijCZ4Iw/Donations-Trackers?type=design&node-id=0%3A1&t=Sergmv4JRwW8N8Cm-1
5. I've created a preliminary list of possible "Product Category" for both "Make Offer" and "Make Request". It can be found at the top of this doc: https://docs.google.com/document/d/1UlUDEbx-g9UHaqR7sNxM0B4MNgHuqRkqegQ5Q412qYE/edit?usp=sharing. Would it be possible to make it so that, if the user chooses the "Other" category, the offer/request would be screened by the admin?
6. I have more questions regarding the addresses, but we can discuss this during the next meeting.

Background/Description:
We need to implement a generic email service layer within our application that supports sending emails for various user activities. This service should utilize a fixed email template that aligns with the UAEM theme. The primary use cases for this service include sending email verification to users upon signup and when they recover their password.

User Story:
As a developer, I want to create a generic email service layer so that we can send email notifications for specific user actions (signup verification and forgot password).

Acceptance Criteria:

1. Upon a new user signup, an email verification message is sent to the user's provided email address.
2. When a user tries to recover their password, an email verification message is send to the user's email address.

Additional Elements:

• Scenario/Task:
  • Implement the email service layer with extensibility in mind for future types of notifications.
  • Test email deliverability and template responsiveness across different email clients.
• Constraints and Considerations:
  • The email service must be implemented with rate limiting to avoid spamming.

The map is not loading for the individual Offer and Request posts. I've tried this with a random postal code (may not exist) and a valid postal code in Montréal (H3A 2B4 and H3A2B4, i.e. with and without space).

Description

Allow users to close their own request or offer posts. This feature will empower users to manage their posts more effectively and enhance their experience on our platform.

Issue Details

1. Request and Offer Posts: Users can create request or offer posts on our platform.
2. When users want to close their own post, they should be able to do so on edit post page.

Expected Behavior

Users should have the ability to close their own request or offer posts when they no longer wish to receive responses or when the post's purpose has been fulfilled. This feature provides users with more control and flexibility in managing their posts.

Additional Context

Empowering users to close their own posts not only enhances their experience but also reduces unnecessary notifications and responses to posts that are no longer relevant.

Acceptance Criteria

• Users should have the option to close their own request or offer posts.
• The closure of a post should be clearly communicated to other users, indicating that the post is no longer active.

Implementation Guidelines

• Review the code for post management and interactions.
• Implement logic to allow users to close their own posts.
• Ensure that the closure of a post is reflected in the user interface and notifications (not yet built).

Description

As per the request from the business team, we need to update the FAQ page with new content provided by them.

Expected Actions

1. Review the new content provided by the business team.
2. Update the existing FAQ page with the new questions and answers.
3. Format the content to maintain consistency with the overall design of the FAQ page.
4. Ensure that the navigation and layout of the FAQ page are user-friendly and intuitive.
5. Test the updated FAQ page to verify that the new content displays correctly and is accessible (keyboard navigation) to users.

For Request and Offer posts, the contact information of the author isn't being displayed on the mobile version of the website.

Docker compose process fails to spin up containers on initial run

there are several issues on running lint.

Description

When a user selects to create either a "donation offer" or a "donation request," the price input fields should be automatically disabled and set to 0.

Expected Behavior

1. Users should be able to select a checkbox whether the post is a donation or not.

When a user chooses to create a "donation offer" or a "donation request":

1. The price input fields should be disabled.
2. The price should be automatically set to 0.

Acceptance Criteria

• A new checkbox whether a post is donation or not is displayed on create/edit post pages.
• Price is automatically set to 0 for donation type posts.
• Proper validation and handling of the price field are maintained on both frontend and backend.

Description

Ensure the uniformity and consistency of postal code handling throughout the application. This request covers input fields, views, and database storage.

Issue Details

1. Input Fields: The current implementation lacks consistency in postal code formatting and validation across various parts of the application. Users may encounter varying rules and formats when entering postal codes.
2. Views: Postal codes displayed in different views may not adhere to a uniform format, which can lead to a fragmented user experience.
3. Database: The database storage of postal codes may lack standardization, making it difficult to retrieve and manage data consistently.

Expected Behavior

Standard format: "A1A1A1" - without any space or symbols, and all capital case

1. Postal code input fields should consistently enforce the same formatting and validation rules across the application.
2. Postal codes displayed in views should follow a standardized format.
3. Postal codes should be stored in the database in a uniform manner.

Acceptance Criteria

• All postal code input fields enforce a standardized format and validation.
• Postal codes displayed in views consistently follow a uniform format.
• Postal codes are stored in the database uniformly.

Implementation Guidelines

• Standardize code for postal code input fields.
• Update view templates to ensure consistent formatting.
• Review and potentially migrate existing data to ensure uniform storage in the database.

I've started a Figma document with the desired pages/design of the website. I'll also describe some in words below.
Figma: https://www.figma.com/file/gfy3OdNXAnNhsJCijCZ4Iw/Donations-Trackers?type=design&node-id=0%3A1&t=Sergmv4JRwW8N8Cm-1
I can also directly share with you the document if that's easier.

Here are the pages that we would like listed on top of the website:
Home

• This page will show the virtual map (i.e. can remain as is).

Login or My Account

• Before the user logs in, the page would be the Login page (which can remain as is).
• After the user logs in, I think it would only make sense that the page changes to a My Account page. This page would contain the Dashboard, Account Information, and buttons linking to the Make Offer and Make Request pages (please see the Figma page, as I think it provides a more clear description of what I mean visually).

Offers

• This page will contain a list of offers (donations or selling). I think we can make this page visible to registered and non-registered users. Showing this page to non-registered users (i.e. didn't log in) could act as an incentive for them to sign up.
• I'm working on the design of the page on Figma at the moment, but I'm imagining it'll just be a database of offers users can filter/search within.

About

• This page will contain information about the Donations Trackers website, UAEM (including McGill UAEM), and the web developers (i.e. contributor's list).
• This page will be visible whether the user logged in or not.
• The working draft for the page is here (also linked on Figma): https://docs.google.com/document/d/1T-DGY9uXOf196XrLhmHNVJSudU2AgEKgMiXFi1SEKRA/edit?usp=sharing

FAQ

• This page is the FAQ page.
• This page will be visible whether the user logged in or not.
• This working draft for the page is here (also linked on Figma): https://docs.google.com/document/d/1AukdPBtELDP5Ehyyulmrf98ZtIK93BbhV-L1qjxuuFQ/edit?usp=sharing

I can't register as an organization, because the website won't allow me to input an address at all. I can input a postal code, but not an address, so I can't test the website as an organization.

Also, same question here regarding the postal code format issue - do we want to restrict the postal code input format?
#71

Description

After submitting a report on the post details page, the "Report" textarea retains the previous content. I suggest resetting this textarea to improve the user experience and avoid potential confusion.

Issue Details

1. Post Details Page: When a user submits a report for a post, the "Report" textarea retains the text previously entered, which can lead to user confusion or unintended actions.

Expected Behavior

After successfully submitting a report, the "Report" textarea should be cleared or reset to an empty state, ready for the user to provide a new report if necessary.

Additional Context

Resetting the "Report" textarea simplifies the process for users and avoids the accidental resubmission of the same report due to the retained content.

Acceptance Criteria

• After submitting a report, the "Report" textarea is cleared or reset.
• The user is presented with a clean textarea to provide new feedback if needed.

Implementation Guidelines

• Review and update the code responsible for handling report submissions.
• Ensure that the textarea is cleared or reset after a successful submission.
• Test the fix thoroughly to confirm that it functions as expected (ensure the report record is saved in db).

Description

Create an admin user management page where administrators can view all users who have any number of reports associated with their accounts. This page will provide a centralized location for administrators to review and manage users with reports efficiently.

Issue Details

1. Admin User Management: Administrators in our application need a dedicated page to manage users, specifically those who have received reports or complaints.

Expected Behavior

The admin user management page should list all users who have any number of reports, allowing administrators to view their details, reports, and take appropriate actions (actions out of scope for this issue) as necessary.

Acceptance Criteria

• A dedicated admin user management page should be created.
• Users with any number of reports should be listed on this page.
• Administrators should have access to user details and a summary of the reports associated with each user.

Implementation Guidelines

• Design and create the admin user management page.
• Implement logic to retrieve and display users with reports.
• Ensure that administrators can access user details and reports for each user.
• Implement actions and notifications for administrators to take appropriate measures.

After some discussion, the business team realized that some changes should be made to the web-design so that users can navigate through the website more easily. Basically, we think that the links/buttons that appear under the circle icon on the top right should be moved elsewhere ("Make an Offer", "Make a Request", "Your account").

1. Move the "Make an Offer" and "Make a Request" to the top of the "Posts" page (instead of appearing once the user clicks on the circle icon on the top right).
2. Move the "Your Account" page to be under "Home" in the menu bar on the left. Rename the page to "Account"

Description

Update admin pages with clear and comprehensive usage instructions. These instructions should guide administrators on how to effectively use the various features and functions available on these pages.

Task Details

1. Admin Pages: We have several admin pages in our open source web application, each with its unique set of features and controls.

Expected Actions

• Review each admin page to understand its functionality and features thoroughly.
• Create clear and user-friendly instructions for each admin page, covering the following:
• Overview of the page's purpose and features.
• Step-by-step instructions on how to perform common tasks or actions.
• Explanation of any advanced settings or options.
• Guidance on best practices and recommended workflows.
• Integrate the instructions directly within each admin page, ensuring that they are easily accessible to administrators.

Could we add units (CAD) to the "Make an Offer" and "Make a Request" pages?
I know it'll be self-explanatory but just to be clear to the users.
So instead of "Price", it'll be "Price (CAD)"

Description

Add a "Help" or "?" button with a tooltip placed beside the "Price" input field on the post creation page. This feature will provide clear instructions to users on how to input data correctly, improving the user experience.

Issue Details

1. Post Creation Page: Users may require additional guidance on how to correctly enter data in the "Price" input field, particularly when creating a post.

Expected Behavior

Introduce a "Help" or "?" button located next to the "Price" input field on the post creation page. When users click on this button, a tooltip should appear, explaining how to input data in the "Price" field accurately.

Additional Context

Enhancing the user experience by providing tooltips or information on data input can reduce errors and ensure users understand how to use the "Price" input field effectively when creating a post.

Acceptance Criteria

• A "Help" or "?" button is added next to the "Price" input field on the post creation page.
• Clicking the "Help" or "?" button displays a tooltip with clear instructions on how to input data in the "Price" field.

Implementation Guidelines

• Modify the user interface on the post creation page to include the "Help" button.
• Implement the logic to show the tooltip when the button is clicked.
• Ensure the tooltip content provides comprehensive and user-friendly guidance.

The button to approve posts listed in "Other" category is missing on the admin side.

For an Offer or Request post, I click on “Edit” --> make changes to the post --> hit “Submit." However, the changes are not updated in the post, and I remain on the “Edit” page.

When an account is deactivated, the user should be notified by their account’s e-mail address immediately (as soon as the account is deemed deactivated by the admins)
The e-mail should include the following:

• Reason for deactivation (Numerous reports, inappropriate language, fake/scams)
• List of restrictions put on their account due to it being deactivated
• Steps showing how to possibly reactivate their account
• Admin/account support contact info (e-mail)

Restrictions placed on an account that has been deactivated should include:

• User will be unable to login to their account (login screen will prompt "This account has been deactivated, see why?” link on attempt to login)
• User will not be able to make offers and requests
• User's offers/requests that were posted before the account deactivation will be removed/hidden from the public
  Note We also want to limit the contact that the deactivated account has with other users (possibly by sending an e-mail to the users that were/are in contact with the newly deactivated account)

Process of Reactivation

• Deactivated user will have the opportunity to contact the admins/account support e-mail to explain why their account should be re-activated or why reason for deactivation is misinterpreted/unreasonable
• Admins will then reconsider/review why the deactivated account was deactivated and decide whether it will be reactivated
• If/when the account is reactivated, user will regain all previously disabled actions

Whenever I make a request with a valid Montréal postal code, my requests aren't being shown on the "Home" page map.

Are you waiting to implement that feature because we may have to re-design the "Home" page? Or is this because I made the requests as an individual user (I can only test the website as an individual user #73)?

I believe we decided that both organizations and individual users can make offers; while the organizations must be based in the Greater Montreal area, the individual users don't have to be. However, the New Offer page's address section is right now locked to QC, Canada. I'm not sure if this is currently being fixed in the back-end, and what I'm seeing is just a front-end problem, but I wanted to bring it up just in case.

I don't think the "Make Request" and "New Offer" pages are updating whenever I switch between them. What I mean by that is, whenever I add an item on the "Make Request" page, the item doesn't get removed when I switch to the "New Offer" page, and vice versa. The same goes for postal code (which is less of a problem).

There are multiple API backend services. Simplify this to a single one.

After an account has been deactivated, the deactivated account is still able to make new posts. In addition, already existing posts that were made by the deactivated account remain public and other users are still able to interact with these posts.

Description

During organization registration, the "address" field is marked as required, but it is currently disabled, preventing users from inputting their address and hindering the registration process.

Issue Details

1. Address Field: The "address" field is essential for organization registration and is marked as required.

Expected Behavior

The "address" field should be enabled to allow users to input their organization's address, as it is a required field during registration. This change is essential to enable successful registration.

Acceptance Criteria

• The "address" field during organization registration should be enabled, allowing users to input their organization's address.

Implementation Guidelines

• Review the code and settings related to the "address" field.
• Ensure that the field is correctly configured to be enabled for input during registration.
• Test the registration process to confirm that the issue is resolved.

site metadata are not showing up correctly.

frontend docker image is being bloated with extra files that don't need to be included for distribution.
trim down on node packages.