Group Status UI Visibility Fix

Group Status UI Visibility Fix

Version: 0.234.005
Fixed in: 0.234.005
Related Feature: Group Status Management
Severity: Medium (UI not reflecting backend permissions)

Issue Description

When selecting a locked, upload_disabled, or inactive group in the Group Workspace view, UI elements that should be hidden (upload area, create buttons) remained visible. This created user confusion as users could see controls but received errors when attempting to use them.

Observed Behavior

• Selected a locked group in Group Workspace
• ❌ Upload area still visible (should be hidden)
• ❌ "New Prompt" button still visible (should be hidden)
• ❌ "New Agent" button still visible (should be hidden)
• ❌ "New Action" button still visible (should be hidden)
• ✅ Status alert correctly displayed (working as expected)

Expected Behavior

When a group has restricted status:

• ✅ Upload area should be hidden for locked/upload_disabled/inactive
• ✅ All create buttons should be hidden for non-active groups
• ✅ Status alert should explain restrictions
• ✅ Only viewing/chat operations available (depending on status)

Root Cause Analysis

The issue was caused by the order of function execution and conflicting logic:

Problem 1: Function Execution Order

// In fetchUserGroups() after finding active group:
updateRoleDisplay();              // Called FIRST - shows upload based on role
updateGroupStatusAlert();         // Called SECOND - shows alert
updateGroupUIBasedOnStatus();     // Called THIRD - hides elements

But then:

// In loadActiveGroupData():
updateRoleDisplay();  // Called AGAIN - overwrites status-based hiding!

Problem 2: updateRoleDisplay() Logic

// OLD CODE (incorrect)
function updateRoleDisplay() {
  const canManageDocs = ["Owner", "Admin", "DocumentManager"].includes(userRoleInActiveGroup);
  const showUpload = canManageDocs;  // ❌ Only checks role, ignores status
  
  if (uploadSection) uploadSection.style.display = showUpload ? "block" : "none";
}

This logic only checked the user's role, not the group's status. So even if status functions hid the upload area, updateRoleDisplay() would show it again if the user had document management permissions.

Problem 3: Redundant Element Targeting

The updateGroupUIBasedOnStatus() function was trying to control upload-area (inner div), while updateRoleDisplay() controlled upload-section (parent container). Since the parent's display was being set to "block", the child's "none" was ignored.

Solution Implemented

Fix 1: Updated updateRoleDisplay() to Consider Status

function updateRoleDisplay() {
  const canManageDocs = ["Owner", "Admin", "DocumentManager"].includes(
    userRoleInActiveGroup
  );
  
  // ✅ NEW: Check BOTH role AND group status
  const activeGroup = userGroups.find(g => g.id === activeGroupId);
  const groupStatus = activeGroup ? (activeGroup.status || 'active') : 'active';
  const groupAllowsUpload = (groupStatus === 'active');
  const showUpload = canManageDocs && groupAllowsUpload;  // ✅ Both conditions required
  
  if (uploadSection) uploadSection.style.display = showUpload ? "block" : "none";
  if (uploadHr) uploadHr.style.display = showUpload ? "block" : "none";
}

Key Changes:

• Now checks both user role and group status
• Upload only shown if user has permissions AND group is active
• Uses AND logic: canManageDocs && groupAllowsUpload

Fix 2: Simplified updateGroupUIBasedOnStatus()

Removed redundant upload-area control since updateRoleDisplay() now handles it correctly:

function updateGroupUIBasedOnStatus() {
  const activeGroup = userGroups.find(g => g.id === activeGroupId);
  const status = activeGroup.status || 'active';
  
  // Only control create buttons (upload handled by updateRoleDisplay)
  const canCreateItems = (status === 'active');
  
  if (createPromptBtn) createPromptBtn.style.display = canCreateItems ? '' : 'none';
  if (createAgentBtn) createAgentBtn.style.display = canCreateItems ? '' : 'none';
  if (createPluginBtn) createPluginBtn.style.display = canCreateItems ? '' : 'none';
}

Files Modified

1. group_workspaces.html

Lines modified: ~2113-2141 (updateRoleDisplay function)

Changes:

• Added group status lookup: const activeGroup = userGroups.find(...)
• Added status check: const groupAllowsUpload = (groupStatus === 'active')
• Updated showUpload logic: const showUpload = canManageDocs && groupAllowsUpload

Lines modified: ~1795-1820 (updateGroupUIBasedOnStatus function)

Changes:

• Removed upload-area control (redundant)
• Kept create button controls
• Updated comment to clarify responsibility

2. config.py

Line modified: 91

Change: VERSION = "0.234.004" → VERSION = "0.234.005"

3. test_group_status_ui_visibility.py

Updated test version references

Testing

Test Coverage

File: functional_tests/test_group_status_ui_visibility.py

All tests passed:

📊 Test Summary: 3/3 tests passed
✅ All tests passed! UI hiding functionality is correctly implemented.

Manual Testing Steps

1. Test Locked Group:

   • Navigate to Group Workspace
   • Select a group with status "locked"
   • ✅ Verify upload area is hidden
   • ✅ Verify all create buttons are hidden
   • ✅ Verify status alert displays "Group Locked" message
   • ✅ Verify documents are viewable

2. Test Upload Disabled Group:

   • Select a group with status "upload_disabled"
   • ✅ Verify upload area is hidden
   • ✅ Verify all create buttons are hidden
   • ✅ Verify status alert displays "Uploads Disabled" message
   • ✅ Verify chat still works

3. Test Inactive Group:

   • Select a group with status "inactive"
   • ✅ Verify upload area is hidden
   • ✅ Verify all create buttons are hidden
   • ✅ Verify status alert displays "Group Inactive" message
   • ✅ Verify all operations blocked

4. Test Active Group:

   • Select a group with status "active"
   • ✅ Verify upload area is visible (if user has permission)
   • ✅ Verify all create buttons are visible
   • ✅ Verify no status alert shown
   • ✅ Verify all operations work

Impact Analysis

Before Fix

• 🔴 Confusing user experience - visible controls that don't work
• 🔴 Backend rejections without clear frontend prevention
• 🔴 Increased support tickets ("Why can't I upload?")
• 🟡 No security risk (backend still enforces permissions)

After Fix

• 🟢 Clear UI - only available actions visible
• 🟢 Status alerts explain restrictions
• 🟢 Prevents user frustration from attempting blocked operations
• 🟢 Consistent with backend permissions

Technical Notes

Execution Flow After Fix

1. User selects group
2. onChangeActiveGroup() triggered
3. setActiveGroup(newGroupId) API call
4. fetchUserGroups() refreshes data
   ├─> updateGroupStatusAlert() - shows alert if needed
   └─> updateGroupUIBasedOnStatus() - hides create buttons if needed
5. loadActiveGroupData() loads content
   └─> updateRoleDisplay() - checks BOTH role AND status for upload

Permission Logic Matrix

Key Insight: Status restrictions apply regardless of role. Even group owners cannot upload to locked groups.

Lessons Learned

1. Order Matters: Function call order is critical when multiple functions modify the same DOM elements
2. Single Responsibility: Each function should control distinct elements or consider all factors
3. Coordination: When multiple functions affect visibility, they must coordinate their logic
4. Testing UI State: Manual testing with different combinations is essential

Related Issues

• Original feature: Group Status Management (v0.233.319)
• Related fix: Backend status reading bug (v0.233.320)
• Related fix: Frontend status saving bug (v0.233.319)

Future Improvements

Potential enhancements to prevent similar issues:

1. Create a central UI state manager for group-related visibility
2. Add unit tests for JavaScript functions
3. Implement feature flags for gradual rollout
4. Add debug mode to log visibility decisions

Summary

This fix ensures that the Group Workspace UI correctly reflects group status restrictions by updating updateRoleDisplay() to check both user permissions AND group status. The upload section is now only visible when the user has document management permissions AND the group is in active status, providing a consistent and intuitive user experience.