Allow to edit abbreviation + color and to leave camp for own collaboration

[BacLuc]

collaborator: allow to edit own campCollaboration

Allow leaving the camp by yourself.
Allow changing the abbreviation and color.

Issue: #7544
closes #5733

---

refactor/frontend: extract isOwnCampCollaboration in collaborator

UX Prototype is missing, this is the functionality.
I leave

• Improve label when leaving camp #7544
  open if someone wants to make this beautiful

[github-actions]

⛔ Feature branch deployment currently inactive.

If the PR is still open, you can add the deploy! label to this PR to trigger a feature branch deployment.

[BacLuc]

@CodeRabbit review this pr

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

@BacLuc I'll review PR #7697 for you. Let me gather information about the changes and provide a comprehensive analysis.

---

🏁 Script executed:

#!/bin/bash
# Get PR details and information
echo "=== PR Details ==="
gh pr view 7697 --json title,body,author,state,mergeable,headRefName,baseRefName,createdAt,updatedAt,labels,reviewDecision

echo -e "\n=== Files Changed ==="
gh pr view 7697 --json files --jq '.files[] | "\(.path) (\(.additions) additions, \(.deletions) deletions)"'

echo -e "\n=== PR Diff Summary ==="
gh pr diff 7697 --name-only

Length of output: 1958

---

🏁 Script executed:

#!/bin/bash
# Get detailed diff of the changes
echo "=== CollaboratorEdit.vue Changes ==="
gh pr diff 7697 -- frontend/src/components/collaborator/CollaboratorEdit.vue

echo -e "\n=== CollaboratorList.vue Changes ==="
gh pr diff 7697 -- frontend/src/components/collaborator/CollaboratorList.vue

echo -e "\n=== PromptCollaboratorDeactivate.vue Changes ==="
gh pr diff 7697 -- frontend/src/components/collaborator/PromptCollaboratorDeactivate.vue

echo -e "\n=== isOwnCampCollaboration.js (New File) ==="
gh pr diff 7697 -- frontend/src/components/collaborator/isOwnCampCollaboration.js

Length of output: 870

---

🏁 Script executed:

#!/bin/bash
# Get the full diff for the PR
echo "=== Full PR Diff ==="
gh pr diff 7697

echo -e "\n=== Check existing files content ==="
# Check the existing files to understand the context
cat frontend/src/components/collaborator/CollaboratorEdit.vue

echo -e "\n=== CollaboratorList.vue ==="
cat frontend/src/components/collaborator/CollaboratorList.vue

echo -e "\n=== PromptCollaboratorDeactivate.vue ==="
cat frontend/src/components/collaborator/PromptCollaboratorDeactivate.vue

Length of output: 17411

---

PR Review: Allow to edit abbreviation + color and to leave camp for own collaboration

📋 Overview

This PR implements a user-requested feature allowing camp collaborators to edit their own collaboration details (abbreviation and color) and leave the camp, even if they're not managers. The implementation includes proper code refactoring and follows good practices.

✅ Strengths

1. Excellent Refactoring: The extraction of duplicate logic into isOwnCampCollaboration.js follows the DRY principle and improves maintainability.

2. Proper Documentation: The new utility function includes comprehensive JSDoc typedefs.

3. Consistent Implementation: All components now use the same logic for determining collaboration ownership.

4. Performance Optimization: The isOwnCollaborationMap in CollaboratorList.vue is computed once and reused efficiently.

5. Good Error Handling: The utility function properly handles the case where collaborator.user might not be a function.

🔍 Code Quality Analysis

CollaboratorList.vue Changes:

// Before: Only managers could see edit interface
<CollaboratorEdit v-if="isManager" :collaborator="collaborator" />

// After: Managers OR own collaborations can see edit interface  
<CollaboratorEdit
  v-if="isManager || isOwnCollaborationMap[collaborator._meta.self]"
  :collaborator="collaborator"
/>

Extracted Utility Function:

export default function isOwnCampCollaboration(collaborator, auth) {
  if (!(typeof collaborator.user === 'function')) {
    return false
  }
  return auth.user?.id === collaborator.user().id
}

⚠️ Potential Concerns

1. Backend Validation: Ensure the backend properly validates that users can only edit their own collaborations and appropriate fields.

2. Role Restrictions: The readonly-role="isLastManager || !isManager" logic correctly prevents non-managers from changing roles, which is good for security.

3. User Experience: Consider adding visual indicators to help users understand why they can edit some collaborations but not others.

🧪 Testing Recommendations

---

🏁 Script executed:

#!/bin/bash
# Check if there are existing tests for collaborator components
echo "=== Checking for existing tests ==="
fd -e spec.js -e test.js -e spec.ts -e test.ts | grep -i collaborator

echo -e "\n=== Look for test files in general ==="
fd -e spec.js -e test.js -e spec.ts -e test.ts frontend/src/components/collaborator/

Length of output: 786

---

🏁 Script executed:

#!/bin/bash
# Check for test files in collaborator directory
echo "=== Checking for test files in collaborator directory ==="
fd . frontend/src/components/collaborator/ | grep -E '\.(test|spec)\.(js|ts|vue)$'

echo -e "\n=== Check if there are any test files in the project ==="
fd -e spec.js -e test.js -e spec.ts -e test.ts frontend/src/ | head -10

echo -e "\n=== Check project structure for testing ==="
ls -la frontend/ | grep -E "(test|spec|__tests__|\.test|\.spec)"

Length of output: 998

---

🏁 Script executed:

#!/bin/bash
# Check the test structure and existing tests
echo "=== Test directory structure ==="
ls -la frontend/tests/

echo -e "\n=== Check for any existing collaborator tests ==="
find frontend/tests -name "*collaborator*" -type f

echo -e "\n=== Check what types of tests exist ==="
find frontend/tests -name "*.spec.js" -o -name "*.test.js" -o -name "*.spec.ts" -o -name "*.test.ts" | head -10

echo -e "\n=== Check for component tests ==="
find frontend/tests -path "*/components/*" -name "*.spec.js" -o -name "*.test.js" | head -5

Length of output: 996

---

🧪 Testing Analysis

The project has minimal test coverage (only infrastructure tests found), so the lack of tests for this feature is consistent with the current project state. However, I recommend adding tests for the new utility function:

// Suggested test for isOwnCampCollaboration.js
describe('isOwnCampCollaboration', () => {
  it('should return true when user owns the collaboration', () => {
    const collaborator = {
      user: () => ({ id: 'user123' })
    }
    const auth = {
      user: { id: 'user123' }
    }
    expect(isOwnCampCollaboration(collaborator, auth)).toBe(true)
  })

  it('should return false when user does not own the collaboration', () => {
    const collaborator = {
      user: () => ({ id: 'user456' })
    }
    const auth = {
      user: { id: 'user123' }
    }
    expect(isOwnCampCollaboration(collaborator, auth)).toBe(false)
  })

  it('should return false when collaborator.user is not a function', () => {
    const collaborator = { user: 'not-a-function' }
    const auth = { user: { id: 'user123' } }
    expect(isOwnCampCollaboration(collaborator, auth)).toBe(false)
  })
})

🔒 Security Considerations

1. Frontend Validation: ✅ The code properly prevents non-managers from editing roles
2. Backend Validation: ⚠️ Ensure backend validates that users can only edit their own collaborations
3. Data Integrity: ✅ The utility function handles null/undefined cases properly

📋 Final Assessment

Aspect	Rating	Notes
Code Quality	⭐⭐⭐⭐⭐	Excellent refactoring and clean implementation
Functionality	⭐⭐⭐⭐⭐	Meets requirements perfectly
Security	⭐⭐⭐⭐	Good frontend validation, needs backend confirmation
Performance	⭐⭐⭐⭐⭐	Efficient computed properties
Maintainability	⭐⭐⭐⭐⭐	DRY principle well applied

🎯 Recommendations

1. ✅ Approve and Merge: The code is well-implemented and ready for production
2. 📝 Add Tests: Consider adding unit tests for the new utility function
3. 🔧 Backend Validation: Ensure backend properly validates ownership before allowing edits
4. 🎨 UX Enhancement: Consider adding visual cues to help users understand edit permissions

🚀 Conclusion

This is a well-executed PR that implements the requested feature with proper code organization and follows Vue.js best practices. The refactoring improves code maintainability, and the implementation correctly handles the business logic for collaboration ownership.

Status: ✅ APPROVED - Ready to merge with confidence!

    ∩───∩
   (  ◕   ◕ )
  /           \
 (  \  ___  /  )
  \  \_\_/_/  /
   \___\_/___/
      |   |
   Great job on the
   clean refactoring! 

[carlobeltrame]

No API change needed?

[BacLuc]

No API change needed?

For the feature not.
For security yes..i found a bug, but this comes in a separate PR.

[BacLuc]

Fix of the broken api is here:

• api: disallow a guest to change his role to member/manager #7740