# Group Status UI Visibility Fix

> 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.

- Skill: `tools-only/group-status-ui-visibility-fix` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add tools-only/group-status-ui-visibility-fix`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tools-only/group-status-ui-visibility-fix/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tools-only (https://skillmd.com/u/tools-only)
- Updated: 2026-09-29
- Page: https://skillmd.com/skills/tools-only/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
```javascript
// 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:**
```javascript
// In loadActiveGroupData():
updateRoleDisplay();  // Called AGAIN - overwrites status-based hiding!
```

### Problem 2: updateRoleDisplay() Logic
```javascript
// 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

```javascript
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:

```javascript
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

| User Role | Group Status | Upload Visible? | Create Buttons? |
|-----------|--------------|-----------------|-----------------|
| Owner | active | ✅ Yes | ✅ Yes |
| Owner | locked | ❌ No | ❌ No |
| Owner | upload_disabled | ❌ No | ❌ No |
| Owner | inactive | ❌ No | ❌ No |
| Admin | active | ✅ Yes | ✅ Yes |
| Admin | locked | ❌ No | ❌ No |
| DocumentManager | active | ✅ Yes | ✅ Yes |
| DocumentManager | locked | ❌ No | ❌ No |
| Member | active | ❌ No | ❌ No |
| Member | locked | ❌ No | ❌ No |

**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.