Reapplication after previous refused application
Closes #767 (closed)
What does this MR do?
Instead of setting a rejected applicants status for a workinggroup/Bezirk to "denied", the entry is just deleted from the database. Thus another application is possible. At the moment you can not apply again after you've been refused once.
How confident are you it won't break things if deployed?
pretty sure. The behavior changes and it would be possible to apply over and over again, but that should not be a problem, I guess. However the db must be cleaned up after deploying, since there are foodsavers with status denied or tentative (active = 20 or 10) in the db, which should be deleted (see more below)
Cleanup of Database
fs_foodsaver_has_bezirk needs some clean up, by deleting all entries with denied status (active = 20) and tentative status (active = 10). To look up all the different active states in the database use:
SELECT COUNT(foodsaver_id), active FROM fs_foodsaver_has_bezirk GROUP BY active ORDER BY COUNT(foodsaver_id)
To delete all entries having a denied status (i.e. active = 20):
DELETE FROM fs_foodsaver_has_bezirk WHERE active = 20
Links to related issues
Issue: #767 (closed)
How to test
Steps a reviewer can take to verify that this MR does what it says it does e.g.
- Refuse a inquiry from a foodsaver for a working group
- The foodsaver should retry a inquiry to the working group and it should be possible to apply again
Checklist
-
added a test, or explain why one is not needed/possible... -
no unrelated changes -
asked someone for a code review -
joined #foodsharing-beta channel at https://slackin.yunity.org -
added an entry to CHANGELOG.md (description, merge request link, username(s)) -
Once your MR has been merged, you are responsible to update the #foodsharing-beta Slack channel about what has been changed here. They will test your work in different browsers, roles or other settings