[AnthonyWeathers]

Feature: Added textbox for initial description for new tracker in tracker list modal, added info modal for tracker list, and adjust infomodal to accept optional initial description if provided, added conditional to prevent refetching of info collections unnecessarily, adjusted some styling for dark mode on the individual task container and the initial text box for "Who can view this Information".

Description

Adds an editable info modal to the Warning Tracker List, with the info modal's content being initially the tracker's description but is editable as needed.

Related PRS (if any):

This frontend PR is related to the #2369 backend PR.
To test this frontend PR you need to checkout the #2369 backend PR.
…

Main changes explained:

• Updated information.js by adding an action and conditional checking of the information reducer to prevent endpoint calls if info collections data had already been until a call involving sending value true to indicate refetching the data anew.
• Updated style.module.css from TeamMemberTasks with some styling to adjust for darkmode.
• Updated TeamMemberTasks.jsx to add classes meant to use the darkmode styling in darkmode
• Updated EditableInfoModal.jsx, allowing use of initial info to be displayed in the content of the info modal but would still use the generic 'Please input information!' if no initial information is provided. Additionally added sending true after update/add/delete calls, to refetch the info collections to retain original intent for EditableInfoModal.jsx. Also, added some validation/sanitization for the initialInfo and some styling adjustment or refactoring
• Updated EditableInfoModal.module.css by adding the styling classes I used in EditableInfoModal.jsx
• Updated WarningTrackerModal.jsx to have an additional section meant to set a description for a new tracker. Added the get, update, and delete info collections actions along with variables to ensure deleting or renaming a warning tracker would be reflected correctly within the info collections.
• Updated Warnings.jsx by adding the EditableInfoModal component to the list.
• Updated Warnings.module.css with classes to adjust them for dark mode
• Updated informationReducer.js with adding a loaded value to the informationReducer data
  …

How to test:

1. check into current branch
2. do yarn install and ... to run this PR locally
3. Clear site data/cache
4. log as Owner/admin user
5. go to dashboard→ Scroll down to a user→ Click 'Tracking' to display list→ Click i icon to view info modal (most trackers will have a general description: 'No description provided yet' unless changed)
6. Click +/- to open Trackers modal→ Scroll down and create a new tracker, and add a personal description→ Scroll down to the tracker and click the i icon for it→ Confirm if the description you set, is shown in the content of that tracker's info modal
7. (Probably Owners only) Using one of the info modals, click the content to change it to the editing state→ Modify the content then save→ confirm that the changes retain even after page refresh or otherwise (if possible, verify that a new document is created in the database with that tracker's details. It'll be under the informations folder but you'll have to locate it yourself from there)
8. Check how the sections look in dark mode, specifically the task area of an individual, how the "Who can view this Information"'s selected text looks in dark mode
9. Verify that if you rename a tracker using the modal you view in step 6, after saving the rename, you navigate back to its info modal, open it and see if the description is retained, and the title reflects the updated name.

Heavier Testing

10. Test if XSS injections are allowed/work on the description as some people pointed in the reviews (Added sanitation on front and backend but hadn't tested myself yet)
11. Send 2 or more concurrent/simultaneous requests of creating a new warning tracker (Verify if their order values are not the same within using MongoDB Compass or another progress to view the database directly, or alternative, you console log the responses of the trackers and check there)

Screenshots or videos of changes:

Note:

"Who can view this Information", when you click its selection to open the dropdown menu, the options or some are still of a bright background, I've tried locating where it's styling was being affected from but could not force the dropdown menu to stay open for me to inspect it's elements and check. If anyone knows where the class affecting it are, or a selector setup to hit them, let me know.

[netlify]

✅ Deploy Preview for highestgoodnetwork-dev ready!

Name	Link
🔨 Latest commit	63160e8
🔍 Latest deploy log	https://app.netlify.com/projects/highestgoodnetwork-dev/deploys/6aeb2242b00c47a5fb3a6cc6
😎 Deploy Preview	https://deploy-preview-5588--highestgoodnetwork-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[iAbhi001]

Hello @AnthonyWeathers, thank you for working on this feature!

While testing this locally, I noticed a readability issue with the UI elements when using dark mode (as shown in the screenshot below). The text contrast and background blending make some of the labels and icons difficult to distinguish.

• Issue: Low contrast/visibility for text and UI elements under dark mode.

• Recommendation: Please review the dark mode styling for the updated components (such as the tracker list and info modal elements) to ensure proper color contrast and accessibility.

Could you please address this styling adjustment? Let me know if you need any clarification.

[AnthonyWeathers]

Hello @AnthonyWeathers, thank you for working on this feature!

While testing this locally, I noticed a readability issue with the UI elements when using dark mode (as shown in the screenshot below). The text contrast and background blending make some of the labels and icons difficult to distinguish.

• Issue: Low contrast/visibility for text and UI elements under dark mode.
• Recommendation: Please review the dark mode styling for the updated components (such as the tracker list and info modal elements) to ensure proper color contrast and accessibility.

Could you please address this styling adjustment? Let me know if you need any clarification.

Thanks for pointing this out, I realized as I finished and pushed, that I did not check the dark mode compatibility at all. I'm taking next week off, so I'd be returning on October 4th, but currently asking Jae of the priority of the task, so I might fix it next week, or after I return.

But again, thanks for the quick review though.

[AaditTrivedi]

Reviewed by Aadit Trivedi.

Tested locally on branch Anthony/Feature-Add-InfoModal-For-Tracker-List against the staging backend, as Admin, on the Dashboard tracker list and the Warning Tracker modal, and reviewed the code alongside backend PR #2369.

Verified working

• Each tracker in the list shows an i icon that opens its info modal.
• The Warning Tracker modal has the new "Warning Tracker Description" field, and a new tracker can be created with it.
• The create request sends newWarningDescription, and the list passes each tracker's description to EditableInfoModal as initialInfo.
• On staging (without #2369), the new tracker's info modal shows "Please input information!", which is expected because the staging backend does not yet save or return the description.
• Editing the info content could not be verified: it is limited to Owner accounts (CanEdit = role === 'Owner') and I tested as Admin.

Issues found

1. Dark mode, confirming @iAbhi001's review with more detail: in dark mode, hovering over the tracker list section turns the whole section white, making it unreadable. Screenshot below.
2. The description input is not cleared after creating a tracker. setNewWarning('') resets the title, but newWarningDescription is never reset, so the next tracker opens with the previous description pre-filled.
3. The description field has required, but the submit handler only checks the title (if (newWarning === '') return;), so an empty description is sent as ''. The backend default ("No description provided yet") only applies when the field is missing, so these trackers show "Please input information!" while existing ones show "No description provided yet." Either validate the description or omit it when empty.

Pointers, not blocking

• Info content is keyed by title (${warning.title}Info), so renaming a tracker loses its info, and deleting a tracker leaves the info document behind (as your note mentions).
• Test step 2 says yarn install; this repo uses npm install.

Evidence
Dark mode hover turning the section white:

New tracker modal with the description field:

Required action
Please fix the dark mode styling, reset the description after creating a tracker, and handle empty descriptions consistently. Happy to re-review once updated.

[vidiyala99]

Tested locally with backend #2369 as Admin and Volunteer, light and dark mode (screenshots below). As expected, Volunteers don't see the Tracking list at all. The core feature works: each tracker gets an "i" icon, and a new tracker's description shows in its info modal. I also confirmed @AaditTrivedi's finding that the description field isn't cleared, and it happens on Cancel too: Cancel only calls setNewWarning(null), so reopening the form shows the old description (screenshot). Resetting newWarningDescription in both the Cancel handler and the success path of handleAddNewWarning would cover it. One new issue, which is a blocker:

Stored XSS through the tracker description. EditableInfoModal renders infoContent with dangerouslySetInnerHTML (line 299), and sanitizedContent at line 261 is just infoContent, so nothing is sanitized in the render path. Before this PR that was safe, because infoContent always came from sanitizeHTML(...) or the constant fallback. The new contentToDisplay() returns initialInfo (the tracker's description from the API) without passing it through sanitizeHTML. I created a tracker with this description:

<img src=x onerror="this.parentNode.style.background='red';this.insertAdjacentText('afterend',' XSS SCRIPT RAN ')">

Opening its "i" modal ran the script (red bar and injected text in the screenshot). The tracker list is visible to Administrators, Owners, and users with viewTrackingOverview, so anyone with addWarningTracker can run script in an Owner's browser session, where the auth token sits in localStorage.

Fix: return initialInfo ? this.sanitizeText(initialInfo) : 'Please input information!'; (the description is plain text, so sanitizeText is stricter than sanitizeHTML). Ideally line 261 should also sanitize, so the name matches what it does.

Not tested: the Owner edit flow for the info modal content, because I don't have an Owner account.

Minor:

• The modal title shows " Tracker Tracker" for trackers whose name already ends in "Tracker" (areaTitle={\${warning?.title} Tracker`}`).
• The new wrapper uses an inline style={{ display: 'flex', gap: '5px' ... }}. A class in Warnings.module.css would match the rest of the file.

[adit24dhaya]

Hi Anthony, I saw the current review comments, so I focused on a different edge case. I found one additional issue and left the details inline: rendering the tracker list causes one full information-collection request per tracker row. In my isolated browser test, 8 rows produced 8 identical GET /api/informations requests during a single expansion.

The three existing Warning tests and my request-count check passed (4 tests total), changed-file ESLint passed with no warnings, and the frontend build passed. The browser fixture used the actual PR components with intercepted API responses, so no database records were created. I did not repeat the XSS, dark-mode, or stale-field findings already documented by other reviewers.

Requesting changes for the request fan-out. Fetching the shared collection once in the parent/Redux layer, or loading it lazily when an info button opens, would avoid the linear request growth.

[adit24dhaya]

Each EditableInfoModal calls getInfoCollections() when it mounts, so placing it inside this map fetches the entire shared collection once per tracker. My fixture produced 8 identical requests for 8 rows. Could we fetch once above the map, guard the Redux fetch when data is already loaded, or mount/fetch the modal only when its info button is opened?

[Niket07pathak]

Reviewed by Niket Pathak

How I verified

Checked out frontend PR #5588 with the related backend PR #2369 and tested the Warning Tracker Info Modal functionality locally. Verified tracker creation, custom descriptions, information editing, data persistence after refresh, existing tracker functionality, and UI behavior in light and dark modes. Also reviewed the code changes for potential performance issues.

Verified working

• Info Modal opens correctly when clicking the information icon beside a tracker.
• Existing trackers display their descriptions correctly in light mode.
• New trackers can be created with custom descriptions.
• Newly created tracker descriptions appear correctly in their respective Info Modals.
• Trackers without custom descriptions display the default information.
• Info Modal content can be edited and saved successfully.
• Updated descriptions persist after refreshing the page.
• Changes to one tracker's information do not affect other trackers.
• Existing tracker management functionality continues to work as expected.

Issues found

1. Warning Tracker Content Not Visible in Dark Mode

When opening the Tracking section on the Dashboard in dark mode, the tracker panel displays a very light background while the tracker names, descriptions, and other text remain light-colored, making the content extremely difficult to read.

Expected behavior: Tracker names, descriptions, and controls should remain clearly visible with appropriate background and text contrast in dark mode.

Actual behavior: The light-colored text blends into the light background, making much of the tracker content nearly invisible.

2. Default Visibility Dropdown Not Visible in Dark Mode

When editing a tracker's information through the Info Modal in dark mode, the "Who can view this information?" field does not display its dropdown options correctly, making it difficult to view or select visibility settings.

Expected behavior: The visibility dropdown and its available options should be clearly visible and readable in both light and dark modes.

Actual behavior: The visibility field appears blank, and the dropdown options are not visibly displayed in dark mode.

3. Redundant API Calls When Rendering Multiple Warning Trackers

In Warnings.jsx, the EditableInfoModal component is rendered inside the usersWarnings.map() loop. Since each modal calls getInfoCollections() when mounted, this can trigger multiple identical API requests for the same shared information.

An existing reviewer reported observing 8 identical requests for 8 tracker rows, indicating unnecessary network requests that could negatively affect performance as the tracker list grows.

Expected behavior: Shared information should be fetched once or loaded only when the corresponding Info Modal is opened, avoiding redundant requests.

Actual behavior: Each mounted EditableInfoModal independently triggers the same data-fetching operation, resulting in repeated requests.

Evidence

Attached screenshots demonstrating:

Required action

Please:

1. Fix the Warning Tracker panel's dark-mode styling to ensure proper text and background contrast.
2. Fix the Info Modal visibility dropdown so its options remain visible and readable in dark mode.
3. Optimize the EditableInfoModal data-fetching behavior to prevent redundant getInfoCollections() API calls. Consider fetching the shared collection once at the parent level or loading the modal only when opened.
4. Verify that these changes work correctly without affecting existing tracker functionality.

Request Changes

Happy to re-review once updated.

[RichaSapre]

I reviewed the frontend tracker info modal and description functionality. The core flow works, but I found these blocking issues:

• I found a stored XSS risk because backend descriptions are rendered through dangerouslySetInnerHTML without sanitization.
• The description field is not cleared after cancelling or successfully creating a tracker.
• Empty descriptions can still be submitted despite the field being marked required.
• Each tracker triggers a separate information request, creating unnecessary API calls.
• Dark-mode contrast issues remain in the tracker panel and visibility dropdown.

[sai-velagala-swe]

PR #5588 – Add InfoModal for Tracker List

Reviewed by Sai Manojna Velagala

How I Tested

Checked out frontend PR #5588 with the related backend PR #2369 and tested the Tracker List InfoModal functionality locally using the Dashboard. Focused on existing tracker information, custom descriptions, and UI behavior in light and dark modes.

Verified Functionality

• Existing InfoModals: Clicking the information icon beside a tracker successfully opens its InfoModal.
• Tracker Descriptions: Existing tracker information is displayed correctly in light mode.
• Custom Descriptions: New trackers can be created with personalized descriptions.
• Description Display: Newly created trackers display their respective descriptions correctly in the InfoModal.
• Light Mode: The tracker list and information content remain visible and readable.

Issues Found

1. Dark Mode – Tracker List and InfoModal Readability

During local testing, I noticed that certain areas of the Tracker List and InfoModal become difficult to read in dark mode. The lighter backgrounds do not contrast sufficiently with the text, making some descriptions and labels less visible.

Expected Behavior: Tracker information, labels, and descriptions should remain clearly readable regardless of the selected theme.

Suggested Improvement: Adjust the theme-specific background and text styling to maintain consistent readability across the Tracker List and InfoModal.

Additional Observations

• Repeated API Requests: Previous code-review findings indicate that displaying multiple trackers may initiate repeated requests for the same information. Fetching shared data once or retrieving it when an individual modal is opened could reduce unnecessary network activity.
• Description Field Reset: Earlier reviews noted that the description field may retain previously entered text after creating or canceling a tracker. Clearing the field when the form is reset would help prevent accidental reuse of descriptions.

These additional observations are based on existing review feedback.

Screenshots

Screenshot 1 – Light Mode

Screenshot 2 – Dark Mode

Conclusion

The core InfoModal functionality worked as expected during my testing, including viewing existing tracker information and displaying custom descriptions. However, the dark-mode readability issue remains noticeable and impacts usability.

Request Changes: Please address the dark-mode visibility issue and consider the previously identified improvements to API request efficiency and description-field handling.

[PrajwalpGM256]

Reviewed by Prajwal.

How I verified
Checked frontend head 5c114e9 together with its backend dependency HGNRest#2369 (12446e6) using git: mergeability against development and against HGNRest#2346, plus the description path end to end. The earlier reviews on this head (@vidiyala99, @adit24dhaya, @Niket07pathak, @RichaSapre, @sai-velagala-swe) still apply. I agree the unsanitized dangerouslySetInnerHTML (stored XSS) is the main blocker.

New: backend coordination

1. HGNRest#2369 conflicts with HGNRest#2346. Each merges cleanly into development on its own, but git merge-tree between them reports CONFLICT (content): Merge conflict in src/controllers/warningsController.js. #2346 moves filterWarnings into warningsHelper.js, and #2369 adds description to that same function. Whichever merges second has to carry description into the moved function, or this modal silently loses every tracker's description. Please confirm the merge order with @DeMoliT1on.
2. Trackers created without a description store an empty string, not the default. The frontend always sends newWarningDescription, which starts as '' (WarningTrackerModal.jsx:44, :259). The backend saves it directly (description: newWarningDescription, currentWarningsController.js). Mongoose only applies the model default 'No description provided yet' (currentWarnings.js) when the value is undefined, so new trackers get '' while existing ones get the placeholder. That's the root cause of the blank descriptions @AaditTrivedi saw. Either omit the field when it's empty on the frontend, or fall back to the default on the backend (newWarningDescription?.trim() || undefined).

Pointer, not blocking (backend)

• checkWarningDescriptions (warningsController.js:26-37 in #2369) runs currentWarnings.updateMany(...) to backfill missing descriptions on every refresh of the warnings cache. That's a one-off data migration inside a read path. A migration script, or relying on the schema default plus a read-time fallback, would avoid the write.

Evidence

$ git merge-tree --write-tree --name-only origin/dhruv/fix-blue-square-email-issues pr-2369   # HGNRest
src/controllers/warningsController.js
CONFLICT (content): Merge conflict in src/controllers/warningsController.js
$ git grep -n "newWarningDescription" pr-5588 -- src/components/Warnings/modals/WarningTrackerModal.jsx
...WarningTrackerModal.jsx:44:  const [newWarningDescription, setNewWarningDescription] = useState('');
...WarningTrackerModal.jsx:259:        newWarningDescription,

Required action
In addition to the XSS fix and the open items from earlier reviews, please coordinate the HGNRest#2346 conflict and make empty descriptions fall back to the default. Happy to re-review once pushed.

[aaryashah22]

Tested locally on 5c114e9d with OneCommunityGlobal/HGNRest#2369 (12446e60) as the backend (Chrome, 10 Oct, after clearing site data): Administrator and Owner in light and dark mode, plus Volunteer, using my own test tracker (deleted afterwards; its info entry Aarya Test 5588Info stays, as your note says).

Works

• Tracking: every tracker has a blue "i" (picture 1). A standard one shows "No description provided yet", and Administrator cannot edit it.
• The new "Warning Tracker Description" box in +/-: my tracker was added at the bottom and its "i" showed exactly my description.
• Owner: clicking the text opens the editor. After Save and a refresh the edited text stayed (picture 2), and GET /api/informations listed Aarya Test 5588Info with it.

Changes requested (dark mode; not compared with development, so these may be older than this PR)

1. Hovering over the tracker list turns the row almost white, so the white names are hard to read (picture 3, left; as AaditTrivedi reported).
2. In the +/- window the rows are light grey with white names (picture 3, right).
3. Owner editor: the "Who can view this information?" box is white with no visible value, and in its list only "All (default)" is readable (picture 4; as Niket07pathak reported).

Question (not from this PR): as Volunteer there is no Tracking or +/- button, but the older "Show Trackers" button still opened the full tracker list on my own row (picture 5), "i" icons included. Should Volunteers see the tracker list this way?

Not tested: HTML in the description, empty or spaces-only descriptions, the description box after Add/Cancel, Volunteer in dark mode, Manager, local tests.

GitHub: 1 commit, checks passed (8 successful, 2 neutral). Requesting changes for 1-3.

[AaditTrivedi]

Re-reviewed by Aadit Trivedi.

Follow-up to my earlier review, after the commits from Oct 5 and Oct 16:

1. Dark mode hover: rows now get dark mode classes with a tr.darkMode:hover rule, which addresses the section turning white on hover. I verified this in the code rather than on screen.
2. The description input is now reset after creating a tracker (setNewWarningDescription('')).
3. Info content is fetched only when it hasn't already been retrieved, avoiding repeat requests.

Pointer, not blocking

• An empty description is still sent as '', so it's saved as an empty string instead of the backend's default ("No description provided yet"), and those trackers show "Please input information!" in the info modal. Omitting the field when it's empty would keep them consistent.

Approving.

[PrajwalpGM256]

Re-reviewed by Prajwal.

How I verified
Checked out frontend head 1ffc4cb (commits e325aa7 and ca925a7 since my last review) locally against backend development, logged in as Owner, and reviewed backend HGNRest#2369 head 6b2c587 and the SonarCloud report for this PR. Items 1 and 2 are reproduced in the UI (screenshots below); items 3 and 4 are from the code and SonarCloud.

Addressed from my previous review — thank you

• Stored XSS: initialInfo is now passed through sanitizeText.
• HGNRest#2346 conflict: #2369 merged development, description is carried into filterWarnings in warningsHelper.js, and it now merges cleanly.
• Empty descriptions: the backend only sets description when it's non-empty (...(cleanedDescription && { description: cleanedDescription })), so the schema default applies.
• Also confirmed: description reset on create/cancel, the getInfoCollections request guard, and the inline style moved to .trackerInfoIcons.

New issues (blocking)

1. Info modal formatting is stripped everywhere. render() now uses const sanitizedContent = this.sanitizeText(infoContent);. sanitizeText allows no tags, so every Owner-formatted info modal loses its paragraphs, lists and bold. EditableInfoModal is used in 19 components (Leaderboard, Projects, Reports, Permissions, User Profile, …). Example — the Blue Squares info on the user profile now renders as one run-on paragraph:

Before :

After :

Fix: const sanitizedContent = this.sanitizeHTML(infoContent); — keep sanitizeText only for initialInfo.

2. WarningTrackerModal crashes when editing a tracker title. Dashboard → Tracking → +/- → typing one character in a tracker title crashes the dashboard:

TypeError: infoCollections.find is not a function
    at WarningTrackerModal (WarningTrackerModal.jsx)

infoCollections is initialised as useState({}) and only set inside fetchWarningDescriptions when retrieveInfoCollections is true, which only happens after a delete/rename. Until then it's an object, so .find(...) throws in the [editedWarning] effect (L107–117). handleTriggerDeleteWarningDescription (L199) has the same problem when clicking delete.
Fix: read the list from Redux (useSelector(state => state.infoCollections.infos)) or initialise with [] and fetch on mount; also guard originalWarning being undefined.

3. A failed fetch locks info collections. getInfoCollections dispatches FETCH_INFOS_BEGIN (sets loading: true), but the catch only shows a toast and never dispatches FETCH_INFOS_ERROR. loading stays true, and the new guard (if (!retrieveInfos && (loading || loaded)) return;) makes every later call return early, so info modals stay empty until a full reload.
Fix: dispatch fetchInfosError(error) in the catch (the reducer case already exists).

4. SonarCloud Quality Gate failing (C Reliability on new code). Two unhandled promises in WarningTrackerModal.jsx, flagged at L234 and L274 (the dispatch(...).then(...) calls in the delete and rename paths). Add a .catch(...) or mark them void.
SonarCloud issues for this PR

Minor, not blocking

• Modal title still reads " Tracker Tracker" for trackers whose name already ends in "Tracker" (Warnings.jsx L189, areaTitle={\${warning?.title} Tracker`}`).
• Sonar suggests .some(...) instead of .find(...) for the existence check at L112.

Required action
Please fix items 1–4. Happy to re-review once pushed.

[iAbhi001]

Tested locally on branch Anthony/Feature-Add-InfoModal-For-Tracker-List at commit 1ffc4cb with backend on development. While the dark mode hover styling, description field reset, and request-caching guards are working better, I am requesting changes due to a few critical regressions. First, running sanitizeText on infoContent in EditableInfoModal.jsx strips all HTML formatting (lists, paragraphs, bold text) across all info modals across the entire application; sanitizeHTML should be kept for infoContent, with sanitizeText reserved only for raw initialInfo. Second, WarningTrackerModal crashes with a TypeError (infoCollections.find is not a function) when typing in a tracker title or deleting because infoCollections initializes as an object instead of an array. Third, getInfoCollections fails to dispatch FETCH_INFOS_ERROR on error, leaving the loading state locked and preventing any subsequent fetches. Lastly, the SonarCloud Quality Gate is failing due to unhandled promise rejections in WarningTrackerModal. Please resolve these issues so we can re-review.

[AnthonyWeathers]

Thanks for the re-reviews you two. I see the issues you discovered, I thought I had fixed the one with info collections.find when you type in warning Title or delete, but perhaps had undone it before pushing.

I was working on an older PR of mine to try addressing reviews there, and that took all of my time this week. I'll get to working on this again next week.

Again, thanks for your hard work reviewing my work, much appreciated!

[adit24dhaya]

Hi Anthony, I rechecked the updates with backend #2369. The request fan-out from my earlier review is fixed: eight simultaneous calls now produce one information request. Thanks for addressing that.

I also reproduced the issues Prajwal and Abhi already reported: saved lists/bold text lose their formatting, and one failed information request leaves loading stuck, blocking the next fetch. I'm keeping Request Changes until those are resolved; no duplicate inline comments added.

Validation: all 3 existing Warning tests and 3 isolated follow-up checks passed (the latter confirm the current behavior, including those failures). Frontend build passed; changed-file JS lint had no errors or warnings. Axios was mocked; no shared database writes.

Commit audit: several subjects exceed 72 characters and use past tense, with no explanatory body or issue reference. Please use shorter imperative subjects for future commits.

[Sripriya03-hub]

Tested this with backend PR 2369 locally.

• The info icon shows next to each tracker and opens the description
• Trackers with no description show No description provided yet
• The info icons don't line up when a tracker name wraps to two lines
• The modal title repeats the word Tracker for Description Tracker
• infoCollections starts as an object instead of an array, so editing a tracker name will throw an error, and deleting a tracker will leave its description behind in the database
• getInfoCollections returns nothing if the data is already loaded, which can leave the role info empty on the Weekly Summaries Report

Requesting changes.

[rahulrubugunday]

I have reviewed your PR locally (1ffc4cb, backend on #2369), logged in as a volunteer.

1. Dashboard > Show Trackers: each tracker has an info icon, and it opens the tracker's info modal ("No description provided yet" for trackers without one).
2. The task area and the info modal look fine in both light and dark mode.

Needs fixing:

1. When a tracker name wraps to two lines (e.g. "Blu Sq Rmvd - Hrs Close Enough", "Blu Sq Rmvd - For No Summary", "Intangible Time Without Reason"), its info icon sits further right than the icons on one-line names. Please keep the icon right after the name for every tracker.

[AnthonyWeathers]

Needs fixing:

1. When a tracker name wraps to two lines (e.g. "Blu Sq Rmvd - Hrs Close Enough", "Blu Sq Rmvd - For No Summary", "Intangible Time Without Reason"), its info icon sits further right than the icons on one-line names. Please keep the icon right after the name for every tracker.

I tried looking into potential fixes before pushing new changes, but the best I managed was this:

The i icons would be consistent in placement, but they wouldn't be only slightly right of the individual warning title. Otherwise, I haven't managed to find a way to move it right of the titles that are long enough to the point of wrapping to a new line.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud