Application priority bug #1694
Open
Application priority bug #1694
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ty is reorganized
1 task
Snorre98
commented
Feb 14, 2025
Snorre98
commented
Feb 14, 2025
backend/samfundet/signals.py
Outdated
Comment on lines
97
to
114
| @receiver(pre_save, sender=RecruitmentApplication) | ||
| def handle_reactivation(sender: RecruitmentApplication, instance: RecruitmentApplication, **kwargs) -> None: | ||
| # Only perform reactivation logic if this is an update (i.e. the object is not new) | ||
| # For new objects, instance._state.adding is True, so we skip this block. | ||
| if not instance._state.adding: | ||
| try: | ||
| # Attempt to fetch the existing record from the database using its primary key. | ||
| old_instance = RecruitmentApplication.objects.get(pk=instance.pk) | ||
| except RecruitmentApplication.DoesNotExist: | ||
| # If the record does not exist in the database, set old_instance to None. | ||
| # This might occur if the record was deleted or not yet committed. | ||
| old_instance = None | ||
| # If we have an existing record, and it was previously withdrawn, | ||
| # but now the updated instance is not withdrawn, then the application is being reactivated. | ||
| if old_instance and old_instance.withdrawn and not instance.withdrawn: | ||
| # Call a helper method to set the reactivated application's priority | ||
| # (e.g., by assigning it the lowest active priority plus one). | ||
| RecruitmentApplication._set_reactivated_priority(instance) |
There was a problem hiding this comment.
Im not sure I like this solution
Snorre98
changed the title
Snorre98
commented
Feb 14, 2025
Comment on lines
449
to
455
| if self.withdrawn: | ||
| # when an application is witdrawn the organize_priorities_on_withdrawal signal is called, this must happen post save | ||
| # this if-statement makes sure that the recruiter_status/priority is "resets" on withdrawal | ||
| # TODO: DO WE WANT TO SET IT TO NOT WANTED AND AUTOMATIC REJECTION? WOULD NOT_SET AND NOT_SET BE BETTER? | ||
| self.recruiter_priority = RecruitmentPriorityChoices.NOT_WANTED | ||
|
|
||
| self.recruiter_status = RecruitmentStatusChoices.AUTOMATIC_REJECTION |
There was a problem hiding this comment.
TODO: do we actually want to set NOT_WANTED and AUTOMATIC_REJECTION here?
Comment on lines
497
to
501
| def update_applicant_state(self) -> None: | ||
| # TODO: DO WE WANT TO CONSIDER WITHDRAWN APPLICATIONS HERE: | ||
| applications = RecruitmentApplication.objects.filter(user=self.user, recruitment=self.recruitment).order_by('applicant_priority') | ||
| # Get top priority | ||
| top_wanted = applications.filter(recruiter_priority=RecruitmentPriorityChoices.WANTED).order_by('applicant_priority').first() |
There was a problem hiding this comment.
TODO: should we add withdraw=False on the filters on line 488 and 490?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
💡 replaced this:#1594
There was a bug which made applicant priority of positions incorrect. This is because when priority is manipulated the total count of applications was including withdrawn applications.
This was the case both when a new application was created, but also when applications where withdrawn.
There also is a bug where the priority is set incorrectly in the scenario when the applicant applies for a position which they previously had withdrawn the application from (could also be described as "re-activating" the application). The application gets the priority it had when it was withdrawn, which seems like unwanted behavior. I think the behavior should be that the "re-activated" application should get the lowest priority, like when the applicant applies for a position for the first time.
I feel that the way we handle withdrawal (setting a flag to false) is prone to error, would it be better to just delete when an applicant withdraws?