It's hard to interpret registrations as failed or real. I'm convinced that
adding a registration time to the table and
outsourcing a pending registration to redis (a failed registration, due to eg mail not working, shouldn't be in the postgres db)
would make the life of the registration validators just easier.
I know that it might be a bit late for this, however this site is planned to run for other events too.
Originally created by @Flexla54 on GitHub (Jun 16, 2022).
Original GitHub issue: https://github.com/detleph/server/issues/87
Originally assigned to: @Flexla54 on GitHub.
It's hard to interpret registrations as failed or real. I'm convinced that
- adding a registration time to the table and
- outsourcing a pending registration to redis (a failed registration, due to eg mail not working, shouldn't be in the postgres db)
would make the life of the registration validators just easier.
I know that it might be a bit late for this, however this site is planned to run for other events too.
I agree with the premise (and the first point), however I do not know if it makes sense to store pending registrations in redis (as this would cause development overhead because of the change in paradigms).
It might just be easier to just check weather the verified boolean is set to true on the team
<!-- gh-comment-id:1173998687 -->
@stephan418 commented on GitHub (Jul 4, 2022):
I agree with the premise (and the first point), however I do not know if it makes sense to store pending registrations in redis (as this would cause development overhead because of the change in paradigms).
It might just be easier to just check weather the `verified` boolean is set to true on the team
Won't the data corpses in the database be a problem?
I don't see a specific reason why they would be? There should of course be some logic that deletes them after some time, but other than that...
Do you see any other problems?
<!-- gh-comment-id:1174024396 -->
@stephan418 commented on GitHub (Jul 4, 2022):
> Won't the data corpses in the database be a problem?
I don't see a specific reason why they would be? There should of course be some logic that deletes them after some time, but other than that...
Do you see any other problems?
I thought that redis is already used for pending teamleader authentication, so I thought it would be efficient to combine them.
<!-- gh-comment-id:1174263868 -->
@Flexla54 commented on GitHub (Jul 4, 2022):
Ok thats fine by me!
I thought that redis is already used for pending teamleader authentication, so I thought it would be efficient to combine them.
Use the verified flag in a way that helps reviewers (Only show unverified people on request for example)
Add ability to purge stale data after event
Test the new feature/fix on basic functionality
<!-- gh-comment-id:1174653825 -->
@stephan418 commented on GitHub (Jul 5, 2022):
# Outgoing task definition:
- [x] Add registration time to the team model
- [x] Use the verified flag in a way that helps reviewers (Only show unverified people on request for example)
- [x] Add ability to purge stale data after event
- [x] Test the new feature/fix on basic functionality
However i want to note that the _deleteUnverifiedTeams function should be used when the sign in phase ends.
<!-- gh-comment-id:1366266169 -->
@Flexla54 commented on GitHub (Dec 27, 2022):
So i basically implemented it.
However i want to note that the `_deleteUnverifiedTeams` function should be used when the sign in phase ends.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @Flexla54 on GitHub (Jun 16, 2022).
Original GitHub issue: https://github.com/detleph/server/issues/87
Originally assigned to: @Flexla54 on GitHub.
It's hard to interpret registrations as failed or real. I'm convinced that
would make the life of the registration validators just easier.
I know that it might be a bit late for this, however this site is planned to run for other events too.
@stephan418 commented on GitHub (Jul 4, 2022):
I agree with the premise (and the first point), however I do not know if it makes sense to store pending registrations in redis (as this would cause development overhead because of the change in paradigms).
It might just be easier to just check weather the
verifiedboolean is set to true on the team@Flexla54 commented on GitHub (Jul 4, 2022):
Won't the data corpses in the database be a problem?
@stephan418 commented on GitHub (Jul 4, 2022):
I don't see a specific reason why they would be? There should of course be some logic that deletes them after some time, but other than that...
Do you see any other problems?
@Flexla54 commented on GitHub (Jul 4, 2022):
Ok thats fine by me!
I thought that redis is already used for pending teamleader authentication, so I thought it would be efficient to combine them.
@stephan418 commented on GitHub (Jul 5, 2022):
Outgoing task definition:
@Flexla54 commented on GitHub (Dec 27, 2022):
So i basically implemented it.
However i want to note that the
_deleteUnverifiedTeamsfunction should be used when the sign in phase ends.