bug: Replace non-existent 'SuperAdmin' localStorage key with 'role' in EventManagement and Requests

[coderabbitai]

Problem Description

Multiple components are checking for a 'SuperAdmin' key in localStorage that does not exist in production and has never been set during the authentication flow. This bug causes incorrect permission checks and feature access issues.

Discovery

This issue was discovered during investigation in PR #7169 by @adityai0 while fixing Organization Settings bugs.

Root Cause Analysis

The Non-Existent Key

The 'SuperAdmin' localStorage key is never set during login:

// LoginPage.tsx - handleLoginSuccess (lines 123-129)
// ❌ 'SuperAdmin' is NEVER set here
setItem('IsLoggedIn', 'TRUE');
setItem('name', user.name);
setItem('email', user.emailAddress);
setItem('role', user.role);  // ← Only 'role' is set, not 'SuperAdmin'
setItem('UserImage', sanitizeAvatarURL(user.avatarURL));
// ... NO setItem('SuperAdmin', ...) call!

Where It's Used Incorrectly

The 'SuperAdmin' key only exists in test mocks (.spec.tsx files), but production code incorrectly tries to read it:

// ❌ WRONG - This key doesn't exist!
const superAdmin = getItem('SuperAdmin');

This means:

• Permission checks always fail
• Features meant for admins are broken
• getItem('SuperAdmin') always returns null in production

Files Affected

1. src/screens/AdminPortal/EventManagement/EventManagement.tsx

Current buggy code:

const superAdmin = getItem('SuperAdmin');
const userRole = superAdmin ? 'SUPERADMIN' : getItem('role');

Issue: Since superAdmin is always null, this logic never grants SUPERADMIN status.

---

2. src/screens/AdminPortal/Requests/Requests.tsx

Current buggy code:

const rawSuperAdmin = getItem('SuperAdmin');
const isSuperAdmin = 
  rawSuperAdmin === true || 
  rawSuperAdmin === 'true' || 
  rawSuperAdmin === 'TRUE';

Issue: rawSuperAdmin is always null, so isSuperAdmin is always false.

Note: This file later correctly checks getItem('role') at line 112, showing the correct pattern is already known in the codebase:

// ✅ CORRECT pattern (already used later in the same file!)
const userRole = getItem('role') as string;
const isAdmin = userRole?.toLowerCase() === 'administrator';

Correct Implementation Pattern

Option 1: Check role in localStorage (already set during login)

// ✅ CORRECT - Works in production
const userRole = getItem('role') as string;
const isSuperAdmin = userRole === 'administrator' || userRole === 'superuser';

Option 2: Defensive with array check

// ✅ CORRECT - Case-insensitive and safe
const userRole = getItem('role') as string;
const isSuperAdmin = Boolean(userRole && ['administrator', 'superuser'].includes(userRole.toLowerCase()));

Option 3: Query GraphQL if real-time data needed

// ✅ CORRECT - Use if fresh data from backend is required
const { data } = useQuery(CURRENT_USER);
const isSuperAdmin = data?.currentUser?.appUserProfile?.isSuperAdmin;

Acceptance Criteria

• Replace getItem('SuperAdmin') with getItem('role') in EventManagement.tsx
• Replace getItem('SuperAdmin') with getItem('role') in Requests.tsx
• Use role values: 'administrator' or 'superuser' for admin checks
• Update associated test files to remove SuperAdmin mocks and use 'role' instead
• Verify admin features work correctly after changes
• Add defensive null checks for userRole
• Ensure consistency: use the same pattern across both files

Test Cases to Verify

1. Login as Administrator

   • Verify getItem('role') returns 'administrator'
   • Verify admin-only features are accessible

2. Login as Regular User

   • Verify getItem('role') returns 'user' or other non-admin role
   • Verify admin features are correctly hidden/disabled

3. Unit Tests

   • Update mocks to set role: 'administrator' instead of SuperAdmin: true
   • Verify all test assertions still pass

Additional Context

Related PR

• PR fix(org-settings): resolve multiple failures in Organization Settings screen (invalid GraphQL query, language dropdown error)  #7169 (current PR) is fixing the same issue in DeleteOrg.tsx
• This issue tracks the remaining files with the same bug

Evidence from Codebase

• The 'SuperAdmin' key appears only in test mocks (.spec.tsx files)
• No production code ever calls setItem('SuperAdmin', ...)
• The 'role' field is reliably set during login and is the source of truth for user permissions

Files to Update

Production Files

1. src/screens/AdminPortal/EventManagement/EventManagement.tsx
2. src/screens/AdminPortal/Requests/Requests.tsx

Test Files (update mocks)

1. src/screens/AdminPortal/EventManagement/EventManagement.spec.tsx
2. src/screens/AdminPortal/Requests/Requests.spec.tsx

Effort Estimate

⏱️ Small - Straightforward find-and-replace with test updates

---

Discovered by: @adityai0 in PR #7169
References:

• PR fix(org-settings): resolve multiple failures in Organization Settings screen (invalid GraphQL query, language dropdown error)  #7169 - Organization Settings bug fixes
• PR Merge latest AdminUI Redesign into develop #972 - Original AdminUI Redesign that may have introduced similar issues

---

Note: @adityai0 - Please self-assign this issue to track the work!

[adityai0]

@palisadoes please assign this to me

[adityai0]

@coderabbitai or alternatively we can set SuperAdmin during login? That might be better?

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Fetch issue `#7202` details to understand the context
gh issue view 7202 --repo PalisadoesFoundation/talawa-admin --json title,body,comments --jq '{title: .title, body: .body, comments: [.comments[] | {author: .author.login, body: .body}]}'

Length of output: 5617

---

@adityai0, I'd recommend sticking with the original approach of using getItem('role') rather than setting SuperAdmin during login. Here's why:

Why Using role is Better

1. Single Source of Truth

The role field is already set during login and contains all the permission information needed:

setItem('role', user.role);  // Already contains 'administrator', 'superuser', etc.

2. Avoids Data Redundancy

Setting SuperAdmin would mean storing the same permission information in two places:

• role: 'administrator'
• SuperAdmin: true ← Derived from role, adds no new information

3. Prevents Data Inconsistency

With redundant data, there's risk of them getting out of sync (e.g., role gets updated but SuperAdmin doesn't), leading to hard-to-debug permission bugs.

4. Less Code to Maintain

Your current approach only requires:

const userRole = getItem('role') as string;
const isSuperAdmin = userRole?.toLowerCase() === 'administrator';

Setting SuperAdmin would require:

• Modifying login flow to derive and set it
• Maintaining the derivation logic
• Updating it whenever role changes

5. Already Used Correctly Elsewhere

As the issue notes, Requests.tsx already uses the correct pattern later in the same file (line 112):

const userRole = getItem('role') as string;
const isAdmin = userRole?.toLowerCase() === 'administrator';

Recommendation

Keep your original approach from the issue - it's cleaner, more maintainable, and follows best practices for data normalization. Just replace the SuperAdmin checks with role checks in the affected files.

🐰✨

---

🧠 Learnings used

Learnt from: palisadoes
Repo: PalisadoesFoundation/talawa-admin PR: 0
File: :0-0
Timestamp: 2025-12-21T21:11:58.123Z
Learning: In PalisadoesFoundation/talawa-admin, when automating bulk issue creation, the fallback assignee to use if palisadoes-bot isn’t assignable is palisadoes.

[adityai0]

@palisadoes
can we address this too?

[adityai0]

@coderabbitai superadmin role no more exists? can we completely remove it?

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Search for all references to SuperAdmin (case-sensitive) to understand usage
echo "=== SuperAdmin references (exact case) ==="
rg -n 'SuperAdmin' -C 2

echo -e "\n=== superadmin references (lowercase) ==="
rg -n 'superadmin' -i -C 2

echo -e "\n=== Looking for role definitions or enums ==="
rg -n "role.*=.*['\"]" --type ts --type tsx -C 2 | head -50

echo -e "\n=== Checking what roles are actually used in the codebase ==="
rg -n "administrator|superuser|admin.*role" --type ts --type tsx -C 1 | head -50

Length of output: 168076

---

🏁 Script executed:

#!/bin/bash
# Check what user types are actually used and returned from the backend
echo "=== Checking CHECK_AUTH query and currentUser types ==="
rg -n "currentUser" -A 10 src/GraphQl/Queries/Queries.ts | head -80

echo -e "\n=== Checking what gets set during login ==="
rg -n "setItem.*role" -B 3 -A 3 src/screens/LoginPage/

echo -e "\n=== Looking at user type definitions ==="
rg -n "userType.*:" --type ts -C 3 src/utils/interfaces.ts | head -50

echo -e "\n=== Check what role values are actually used in role-based logic ==="
rg -n "role.*administrator|role.*superadmin|role.*admin" -i --type ts src/screens/ | head -40

Length of output: 4778

---

@adityai0, great question! Let me clarify the two different "superadmin" concepts here:

1. SuperAdmin localStorage key ❌ Should be removed

This is what issue #7202 is addressing:

// ❌ OLD (being removed)
const isSuperAdmin = getItem('SuperAdmin');

// ✅ NEW (using role field)
const userRole = getItem('role') as string;
const isSuperAdmin = userRole?.toLowerCase() === 'administrator';

2. Backend SUPERADMIN userType ✅ Still exists

The backend has three user types that are separate from roles:

• USER - regular member
• ADMIN - organization admin
• SUPERADMIN - platform super admin

Evidence from the code:

// In App.tsx
const isSuperAdmin = data?.currentUser?.userType === 'SUPERADMIN';

// GraphQL still returns
appUserProfile {
  isSuperAdmin: boolean
}

Key Distinction

• role field: Contains organization-level roles like 'administrator' (org admin)
• userType field: Contains platform-level types like 'SUPERADMIN' (platform admin)

What to Remove

For your PR addressing #7202, you should:

1. ✅ Remove all getItem('SuperAdmin') localStorage references
2. ✅ Replace with getItem('role') checks
3. ❌ Don't remove userType === 'SUPERADMIN' checks (backend concept)
4. ❌ Don't remove isSuperAdmin field from GraphQL queries (still used by backend)

The backend SUPERADMIN concept is still valid and used for platform-level permissions, but the localStorage boolean key is redundant and should be replaced with role-based checks.

Does this clarify the distinction? 🐰✨