-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
finalize user admission priorities for backend #987
Conversation
947dda8
to
7c90f0b
Compare
|
||
""" | ||
admissions_for_user = RecruitmentAdmission.objects.filter(recruitment=self.recruitment, user=self.user) | ||
# Use order for more simple an unified for direction |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Skjønner ikke
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hva er det du ikke skjønner?
Får tak i alle admissions for bruker og recruitment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mistenker at man kan gjøre dette enklere, men det avhenger av noen ting sikkert.
Er det validering på at man ikke kan ha samme priority, er vi sikret mot feil tilstand?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Er høy eller lav prio best? Er det som rekkefølge slik at 1 er øverst?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lav, er mer rangering
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gjerne svar på alle spørsmålene. Skal komme opp med et forslag, tror jeg har en god ide.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Den er sikret mot at gjennom bruk av denne, så kan ikke flere ha samme rangering, siden den vill bytte opp plassering og sortere.
Den PR er lagd for å organisere og omgjøre prioriteringer.
Den kan settes manuelt til samme, men den beskyttelsen vil være i en annen PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Så det er en db constraint på vei inn?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Det er ikke en DB constraint nei, det kan settes manuellt, og da sier ingenting at det ikke er mulig.
En DB constraint i dette tilfellet kan foresake en form for deadlock, hvor når den bytter om så vil det være et tilfelle 2 har samme verdi, og vil da fucke ting opp.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Denne tråden var vi ikke ferdig med.)
Det er litt av poenget med constraint, garantere at ingen av dem har samme prio.
Jeg tror dette kan gjøres mye enklere.
Bare bulk flytt på settet du finner.
qs.filter(...).update(prio=F('prio')+1)
qs.filter(...).update(prio=F('prio')-1)
frontend/src/Pages/ApplicantApplicationOverviewPage/ApplicantApplicationOverviewPage.tsx
Outdated
Show resolved
Hide resolved
frontend/src/Pages/ApplicantApplicationOverviewPage/ApplicantApplicationOverviewPage.tsx
Outdated
Show resolved
Hide resolved
af560da
to
57d477f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ser bra ut!
closes #984