Fixed Bug #2455 #2991
Fixed Bug #2455 #2991
Conversation
WalkthroughThe pull request modifies the Changes
Possibly Related PRs
Suggested Reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
Our Pull Request Approval ProcessThanks for contributing! Testing Your CodeRemember, your PRs won't be reviewed until these criteria are met:
Our policies make our code better. ReviewersDo not assign reviewers. Our Queue Monitors will review your PR and assign them.
Reviewing Your CodeYour reviewer(s) will have the following roles:
CONTRIBUTING.mdRead our CONTRIBUTING.md file. Most importantly:
Other
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/screens/UserPortal/People/People.tsx (2)
31-31: Consider renaming or documenting__typename.Currently,
__typenamemight store a GraphQL type name rather than a human-readable role. If this property is genuinely intended for displaying the user’s role, you might rename it to something more explicit (e.g.,roleType) or add a comment clarifying its usage. This will avoid confusion for future maintainers.
Line range hint
1-1: Adopt PascalCase for React components.Your component is exported as a default function named
people, but React convention suggests using PascalCase (e.g.,People). Using a capital letter for the component name makes it more recognizable as a React component.-export default function people(): JSX.Element { +export default function People(): JSX.Element {
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/screens/UserPortal/People/People.tsx(2 hunks)
🔇 Additional comments (1)
src/screens/UserPortal/People/People.tsx (1)
246-246: Confirm that __typename accurately reflects the user’s role.
Assigning member.__typename to the role field fixes the bug where the role was not displayed, but ensure you verify that __typename always corresponds to the user’s actual role. If the GraphQL field __typename is used for other logic or is more generic, consider adding a dedicated role field.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop-postgres #2991 +/- ##
=====================================================
+ Coverage 33.14% 89.09% +55.95%
=====================================================
Files 299 322 +23
Lines 7429 8421 +992
Branches 1624 1839 +215
=====================================================
+ Hits 2462 7503 +5041
+ Misses 4762 676 -4086
- Partials 205 242 +37 ☔ View full report in Codecov by Sentry. |
|
@AryanSwaroop Please fix the first comment so that each issue listed automatically closes. |
|
sure ! on it |
|
Update your branch with latest upstream . |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/screens/UserPortal/People/People.spec.tsx (1)
171-177: Consider handling unexpected or null objects.
WhilecomparePropertiesfunctions as intended, a null or unexpected object could throw a runtime error withObject.keys(). You could add a short-circuit condition to handle such cases gracefully.function compareProperties( expectedProps: string[], actualObject: object, ): boolean { + if (!actualObject || typeof actualObject !== 'object') { + return false; + } const actualProps = Object.keys(actualObject); return expectedProps.every((prop) => actualProps.includes(prop)); }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/screens/UserPortal/People/People.spec.tsx(2 hunks)src/screens/UserPortal/People/People.tsx(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/screens/UserPortal/People/People.tsx
🔇 Additional comments (2)
src/screens/UserPortal/People/People.spec.tsx (2)
14-14: Import usage looks good.
Bringing in InterfaceMember from ./People properly centralizes type definitions. Ensure that any further additions or refactorings in ./People continue to keep these types consistent.
179-224: Tests effectively validate interface properties.
These tests ensure the integrity of the InterfaceMember structure. However, consider adding a test that checks for empty arrays or partially filled objects to further improve coverage.
palisadoes
merged commit 4713884
into
PalisadoesFoundation:develop-postgres
What kind of change does this PR introduce?
Fixed User role not displaying bug in people section. This PR changes the interface that was causing mismatch.
Issue Number:
#2455
Did you add tests for your changes?
yes
Snapshots/Videos:
If relevant, did you update the documentation?
No , not relevant
Summary
The people section without any role looks empty and error full so this PR solves it , when users like me use this software.
#2455
Does this PR introduce a breaking change?
Np
Have you read the contributing guide?
Yes
Summary by CodeRabbit
InterfaceMemberis maintained.