[#163] Update User and Food Request Models, Serializers, and Views

[delano]

Addresses #163

This update introduces significant changes across multiple files, focusing on enhancing the food request submission process, user management, and overall code structure. Key changes include:

1. Migration Updates:

   • Renamed fields in the DeliveryRegion model.
   • Simplified the Pet model by removing redundant fields and adding JSON fields for food_details and dog_details.
   • Updated the User model to include a details JSON field and made username optional.
   • Added details JSON field to the Profile model and removed the Role model.
   • Adjusted the Branch model to include more detailed address fields and updated default values for some fields.
   • Enhanced the FoodRequest model to include a pets ManyToManyField.

2. Serializer Enhancements:

   • Created new serializers for FoodRequest, Pet, and Profile.
   • Updated UserSerializer to handle user registration and profile creation.
   • Introduced RegisterSerializer for user registration with automatic password generation.

3. View and API Enhancements:

   • Refactored UserViewSet to CurrentUserAPIView and RegisterUserAPIView for better user management.
   • Added FoodRequestViewSet for handling food request operations.
   • Updated API routes to include new endpoints for user registration and current user retrieval.

4. Testing Enhancements:

   • Added new test cases for user registration, profile creation, and food request submission.
   • Refactored existing tests to align with the new model and serializer changes.
   • Introduced a custom test runner for running pytest via Django's test command.

5. Frontend Enhancements:

   • Updated client and volunteer signup pages to use new API endpoints.
   • Improved form validation and error handling in the frontend.
   • Added navigation and feedback mechanisms for better user experience.

6. Configuration and Documentation:

   • Updated .codiumai.toml and pyproject.toml for better test configuration and dependency management.
   • Enhanced logging and signal handling for user profile creation.
   • Updated Docker and GitHub Actions configurations for streamlined development and deployment workflows.

[qodo-merge-pro]

PR Review 🔍

⏱️ Estimated effort to review [1-5]	4, because the PR introduces a wide range of updates across models, serializers, views, and configurations, along with new test cases and modifications to the frontend. Reviewing this PR requires a comprehensive understanding of the Django REST Framework, Django models, and Vue.js components. Additionally, the introduction of new API endpoints and changes to existing ones necessitate careful consideration of security, performance, and compatibility with the frontend.
🧪 Relevant tests	Yes
⚡ Possible issues	Possible Bug: The UserViewSet class has been replaced with CurrentUserAPIView and RegisterUserAPIView, but the frontend and tests may still reference the old UserViewSet. This could lead to broken functionality where the frontend expects to interact with user-related endpoints.
	Security Concern: The PR introduces changes to authentication and user registration logic, including password handling and token generation. It's crucial to ensure that these changes do not introduce vulnerabilities, such as weak password policies or token mismanagement.
	Performance Concern: The new FoodRequestViewSet and changes to models might impact the performance of the application, especially if they increase the complexity of database queries or the size of the data being processed and returned by the API.
🔒 Security concerns	Sensitive information exposure: The PR includes changes to how user passwords are handled and introduces automatic token generation for users. It's important to verify that passwords are securely hashed and that tokens are securely generated and managed to prevent unauthorized access.

[qodo-merge-pro]

PR Code Suggestions ✨

Category	Suggestion	Score
Best practice	Avoid using null=True on string-based fields unless necessary Consider setting null=True for models.CharField fields only if it is really necessary. Having both blank=True and null=True can lead to inconsistency in how empty values are handled. If the field is a string-based field like CharField or TextField, Django recommends using blank=True alone. This way, Django stores empty values as empty strings rather than NULL in the database. This suggestion applies to fields such as address_line2, city, country, and ext_id in various models. apps/api/afbcore/migrations/0001_initial.py [36-316] -models.CharField(blank=True, max_length=255, null=True) +models.CharField(blank=True, max_length=255) Suggestion importance[1-10]: 7 Why:	7
	Define model field choices outside the field definition When defining model fields with choices, it's a good practice to define the choices as a list of tuples outside the model field definition. This makes it easier to reference the choices elsewhere in your code, for example, in forms or model methods. Apply this change to the pet_type, delivery_type, and status fields across various models. apps/api/afbcore/migrations/0001_initial.py [113-352] +PET_TYPE_CHOICES = [ + ("Cat", "Cat"), + ("Dog", "Dog"), + ("Other", "Other"), +] +... models.CharField( - choices=[ - ("Cat", "Cat"), - ("Dog", "Dog"), - ("Other", "Other"), - ], + choices=PET_TYPE_CHOICES, max_length=255, ) Suggestion importance[1-10]: 7 Why:	7
	Use default instead of null=True for boolean fields For boolean fields like is_removed, spay_neuter_requirement, flagged, etc., consider using models.BooleanField() without null=True. Boolean fields should not have null=True as it's better to use the default parameter to specify the default value. This avoids the confusion of having three possible values (True, False, or None) for what should be a binary choice. apps/api/afbcore/migrations/0001_initial.py [74-458] -models.BooleanField(null=True) +models.BooleanField(default=False) Suggestion importance[1-10]: 7 Why:	7
	Add related_name to pets ManyToManyField in FoodRequest model It's recommended to add related_name attributes to ForeignKey and ManyToManyField for better reverse query readability. For example, in the FoodRequest model, adding a related_name to the pets field would improve ORM queries from the Pet model back to FoodRequest. apps/api/afbcore/models/pet.py [43] -pets = models.ManyToManyField("Pet") +pets = models.ManyToManyField("Pet", related_name="food_requests") Suggestion importance[1-10]: 7 Why:	7
	Add conditional validation for optional fields To ensure the form's phone_number field is optional but validated when provided, consider adding a conditional validation that checks for the presence of a value before applying any phone number specific validation rules. apps/ui/pages/welcome/clients.vue [19] -const fields = ref<any>([]); +const fields = ref<any>([ + // Other fields remain unchanged + { + name: "phone_number", + type: "text", + label: "Phone", + placeholder: "Your phone number", + icon: "i-heroicons-phone", + help: "We use your phone number to coordinate deliveries. See our Privacy Notice for how we use your information (link below).", + required: false, + validate: (value) => { + return value ? /^\d{10}$/.test(value) : true; + }, + }, +]); Suggestion importance[1-10]: 7 Why:	7
Enhancement	Make UUID fields' uniqueness explicit For the UUIDField used for the id field in various models, consider explicitly setting unique=True to ensure database integrity and clarity of design, even though primary_key=True inherently enforces uniqueness. This change is minor but can improve the readability of the model definitions and make the uniqueness constraint more explicit. apps/api/afbcore/migrations/0001_initial.py [77-320] models.UUIDField( default=uuid.uuid4, editable=False, primary_key=True, + unique=True, ) Suggestion importance[1-10]: 7 Why:	7
	Use TextField for address fields to accommodate longer addresses It's recommended to use specific fields for addresses, such as models.TextField for address_verbatim and address, to accommodate the full length of addresses. However, since these fields are already defined as CharField with a max_length=255, ensure this length is sufficient to store the full address. If addresses might exceed this length, consider changing to TextField without a max_length constraint for better flexibility. apps/api/afbcore/models/users/profile.py [87] -address = models.CharField(max_length=255, blank=True, null=True) +address = models.TextField(blank=True, null=True) Suggestion importance[1-10]: 7 Why:	7
	Add a unique constraint to the username field that allows for null values Consider adding a unique constraint to the username field that allows for null values to ensure that null can be set for multiple records, but every non-null value is unique. This can be achieved by using models.CharField with null=True, blank=True, unique=True, but Django does not support this out of the box for traditional fields. A workaround is to use a custom manager or override the save method to enforce this logic. apps/api/afbcore/models/users/user.py [131-133] username = models.CharField( - _("username"), max_length=255, unique=True, null=True, blank=True + _("username"), max_length=255, null=True, blank=True ) +# Custom save method or manager to enforce unique non-null constraint Suggestion importance[1-10]: 7 Why:	7
	Add more test cases for the FoodRequestViewSet to improve coverage To improve test coverage and ensure the API behaves correctly under different scenarios, consider adding more test cases for the FoodRequestViewSet. These could include tests for unauthorized access, handling of invalid data, and updating or deleting food requests by different types of users. apps/api/afbcore/tests/views/test__requests__view.py [16-24] -class FoodRequestViewSetTestCase(TestCase): +# Additional test methods here +def test_food_request_access_unauthorized(self): + # Test accessing the food request without authentication +def test_create_food_request_invalid_data(self): + # Test creating a food request with invalid data +def test_update_food_request(self): + # Test updating a food request +def test_delete_food_request(self): + # Test deleting a food request Suggestion importance[1-10]: 7 Why:	7
	Add a method to handle the user's full name or display name For the User model, consider implementing a method to handle the full name or a display name that combines available name fields. This can be useful for displaying a user's name in various parts of the application where either the name or a combination of first_name and last_name (if name is not available) is needed. apps/api/afbcore/models/users/user.py [92] class User(UUIDModel, TimeStampedModel, HasDetails, AbstractUser): + def get_full_name(self): + if self.name: + return self.name + full_name = f"{self.first_name} {self.last_name}".strip() + return full_name if full_name else None Suggestion importance[1-10]: 7 Why:	7
	Change pet_dob field to use models.DateField Consider using models.DateField for pet_dob instead of models.CharField to ensure that the date of birth is stored in a format that allows for date operations and validations. apps/api/afbcore/models/pet.py [31] -pet_dob = models.CharField(max_length=10) # date of birth +pet_dob = models.DateField() # date of birth Suggestion importance[1-10]: 7 Why:	7
	Use v-model for reactive form inputs Consider using v-model for form inputs to simplify data binding and form submission. This approach can make the form more reactive and reduce the need for manual event handling or data assignment. apps/ui/pages/welcome/clients.vue [17-19] -const email = route.query.email as string; -const fields = ref<any>([]); +const form = ref({ + email: route.query.email as string, + name: '', + phone_number: '', +}); Suggestion importance[1-10]: 7 Why:	7
	Automatically trim whitespace in user inputs To improve user experience and accessibility, consider adding v-model.trim to automatically trim whitespace from user inputs. This is particularly useful for email and name fields where leading or trailing spaces can be unintentionally added by users. apps/ui/pages/welcome/clients.vue [17] -const email = route.query.email as string; +const form = ref({ + email: route.query.email as string.trim(), + name: ''.trim(), + phone_number: '', +}); Suggestion importance[1-10]: 7 Why:	7
Security	Implement rate limiting on the user registration API view To enhance security and usability, consider implementing rate limiting on the RegisterUserAPIView to prevent brute-force attacks or abuse of the user registration process. Django Rest Framework provides a simple way to add rate limiting using the DEFAULT_THROTTLE_CLASSES and DEFAULT_THROTTLE_RATES settings. apps/api/afbcore/views/users/init.py [49-52] +from rest_framework.throttling import AnonRateThrottle + class RegisterUserAPIView(CreateAPIView): queryset = User.objects.none() serializer_class = UserSerializer permission_classes = [permissions.AllowAny] + throttle_classes = [AnonRateThrottle] Suggestion importance[1-10]: 7 Why:	7
	Add permission checks to FoodRequestViewSet Implement permission checks in FoodRequestViewSet to ensure that only authorized users can create, update, or delete food requests. This is crucial for data security and integrity. apps/api/afbcore/views/requests/food_request.py [10-11] -# TODO: Add permissions and authentication to this viewset. +from rest_framework.permissions import IsAuthenticated +permission_classes = [IsAuthenticated] Suggestion importance[1-10]: 7 Why:	7
Performance	Optimize uniqueness check using Django's query methods It's recommended to use Django's built-in update_or_create method for the is_a_truly_unique functionality to simplify the logic and potentially improve performance by reducing the number of database queries. apps/api/afbcore/models/users/user.py [47-57] -try: - record = self.get(**{field_name: value}) - logger.info(f"UserManager.is_a_truly_unique - record: {record.pk}") -except User.DoesNotExist: - logger.info("UserManager.is_a_truly_unique - DoesNotExist") - is_unique = True +is_unique = not self.filter(**{field_name: value}).exists() +if is_unique: + logger.info("Value is unique.") +else: + logger.info("Value is not unique.") Suggestion importance[1-10]: 7 Why:	7
Maintainability	Document the rationale for PASSWORDLESS_REGISTER_NEW_USERS setting For the PASSWORDLESS_REGISTER_NEW_USERS setting, consider documenting the rationale behind setting it to False within your settings file or a relevant configuration guide. This helps maintainers understand the security and user registration implications. apps/api/afb/settings.py [267] +# Setting PASSWORDLESS_REGISTER_NEW_USERS to False requires explicit registration before login. "PASSWORDLESS_REGISTER_NEW_USERS": False, Suggestion importance[1-10]: 7 Why:	7
	Remove commented-out code from UserSerializer For the UserSerializer, consider removing the commented-out code related to the phone field if it's not intended to be used. Keeping commented-out code can lead to confusion and clutter in the codebase. apps/api/afbcore/serializers/user/user_serializer.py [22] -# phone = serializers.CharField(required=False, allow_blank=True) +(Remove the commented-out line) Suggestion importance[1-10]: 7 Why:	7
	Abstract form validation logic for maintainability To enhance code maintainability, consider abstracting the form validation logic into a separate composable or utility function. This can make the code cleaner and easier to test independently from the UI component. apps/ui/pages/welcome/clients.vue [21-22] -const validateEmail = (email: string) => { - return (/^\w+([\.-\\+]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/.test(email)) +// In a separate file, e.g., `useFormValidation.js` +export function useEmailValidation() { + return (email) => (/^\w+([\.-\\+]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/.test(email)); } +// In your component +const { validateEmail } = useEmailValidation(); Suggestion importance[1-10]: 7 Why:	7
User experience	Provide detailed error messages for better user feedback For better error handling and user feedback, consider adding a more detailed error message when the $fetch request fails due to reasons other than a duplicate email. This can help users understand what went wrong and how to proceed. apps/ui/pages/welcome/clients.vue [106-118] if (data && data.email) { snackbar.add({ type: "error", text: "Please choose another email address", }); } else { - throw createError({ - statusCode: 404, - statusMessage: 'Page Not Found', - fatal: true - }) + snackbar.add({ + type: "error", + text: "An unexpected error occurred. Please try again later.", + }); } Suggestion importance[1-10]: 7 Why:	7

---

💡 Tool usage guide:

---

Overview:
The code suggestions tool, named improve, scans the PR code changes, and automatically generates code suggestions for improving the PR.The tool can be triggered automatically every time a new PR is opened, or can be invoked manually by commenting on a PR.

• When commenting, to edit configurations related to the improve tool (pr_code_suggestions section), use the following template:

/improve --pr_code_suggestions.some_config1=... --pr_code_suggestions.some_config2=...

• With a configuration file, use the following template:

[pr_code_suggestions]
some_config1=...
some_config2=...

See the improve usage page for a comprehensive guide on using this tool.

[delano]

Thank you 😊