feat: allow user to unsubscribe from a brain

[mamadoudicko]

• update translations
• add
• update tests
• redirect to /brains-management on invalid brain id
• refactor: move delete_brain_user to delete_brain_users
• add /POST '/brains/{brain_id}/subscribe'
• handle public brain unsubscription

#1212

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 25, 2023 0:20am
quivr-strapi	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 25, 2023 0:20am
quivrapp	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 25, 2023 0:20am

[github-actions]

Risk Level 2 - /home/runner/work/quivr/quivr/backend/models/databases/supabase/brains.py

The code changes are generally safe, but there are a few areas that could be improved for better readability and maintainability.

1. In the delete_brain_user_by_id method, the results variable is not used after being assigned. If the result of the delete operation is not needed, you can remove this assignment.

2. The delete_brain_vector and delete_brain_users methods have inconsistent return types. The former does not return anything, while the latter returns the result of the delete operation. It would be better to make these consistent, either by returning the result in both methods or in neither.

Here are the suggested changes:

# Suggested change for delete_brain_user_by_id
self.db.table(\"brains_users\")
.delete()
.match({\"brain_id\": str(brain_id), \"user_id\": str(user_id)})
.execute()

# Suggested change for delete_brain_vector
return self.db.table(\"brains_vectors\")
.delete()
.match({\"brain_id\": brain_id})
.execute()

---

Risk Level 2 - /home/runner/work/quivr/quivr/backend/models/brains.py

The code seems to be well written and follows the SOLID principles. However, there are a few areas that could be improved for better readability and maintainability:

1. The delete_brain method has a high cyclomatic complexity due to the nested if-else condition. Consider simplifying this method to improve readability and maintainability.

2. The openai_api_key attribute in the Brain class is a potential security risk if it is not properly managed. Ensure that this attribute is securely stored and not exposed in any logs or error messages.

3. The get_brain_users and delete_user_from_brain methods have a # TODO comment to move them to a new BrainService. Consider doing this to adhere to the Single Responsibility Principle.

4. The get_unique_brain_files and get_all_knowledge_in_brain methods seem to have duplicate code. Consider refactoring these methods to remove the duplication.

Example:

    def get_unique_brain_files(self):
        self.files = self._get_files()
        return self.files

    def get_all_knowledge_in_brain(self):
        self.files = self._get_files()
        return self.files

    def _get_files(self):
        vector_ids = self.supabase_db.get_brain_vector_ids(self.id)  # type: ignore
        return get_unique_files_from_vector_ids(vector_ids)

---

Risk Level 2 - /home/runner/work/quivr/quivr/frontend/app/brains-management/[brainId]/components/BrainManagementTabs/hooks/useBrainManagementTabs.ts

The code is generally well written, but there are a few areas where improvements could be made for readability and maintainability. For example, the handleUnsubscribeOrDeleteBrain function is quite large and complex, which could make it difficult to understand and maintain. Consider breaking this down into smaller, more manageable functions.

---

📚🔐🔄

---

Powered by Code Review GPT

[gozineb]

Ca fait bizarre "cette action ne peut pas etre annulée" vu que tu peux juste repartir t'abonner au cerveau

[mamadoudicko]

🚮