Prevent duplicate employments to same organisation (estimate: 6) #2374
Comments
nadiagorchakova
changed the title
|
The |
|
Yep that's a UI/UX bug, good catch. But I think there was an original problem that was solved by removing the "duplicate" employment, meaning that the user was in two groups. So it could be we have a problem when a user is in multiple groups. I don't recall what the original issue was, do you @nadiagorchakova ? |
|
@zzgvh @punchagan, as far as I remember, the original problem was with the Up app, here: #2364. That's where the entire discussion about multiple employments started, I think |
|
And could this issue be relevant to the discussion? #2122. It was created way earlier but seems to address the same problem of multiple/duplicate employments |
|
@nadiagorchakova thank you! @zzgvh #2122 does seem like the bug that is triggering this, or atleast one issue. We could either have an |
|
I think we have to have a Unapproved group or similar, since we otherwise approve a user implicitly by assigning them to the Users group. |
|
@zzgvh Doesn't look like it. As far as I could see, |
When an Employment with no group is created, the group is set to 'Users' in the `post_save` method. But, if there is already a similar Employment for that user, the `post_save` fails because there's a uniqueness constraint on (user, organisation, group)
Employments are forced to have a non-null group, though the model does allow null values, by trying to set a default group in the post_save. But, this can fail if such an employment already exists, thus creating an employment with a null group. Multiple such employments with a null group can get created, too. This commit moves the setting of the group to the pre_save signal, thus preventing an invalid employment from getting created. Closes #2374, Closes #2122
When an Employment with no group is created, the group is set to 'Users' in the `post_save` method. But, if there is already a similar Employment for that user, the `post_save` fails because there's a uniqueness constraint on (user, organisation, group)
Employments are forced to have a non-null group, though the model does allow null values, by trying to set a default group in the post_save. But, this can fail if such an employment already exists, thus creating an employment with a null group. Multiple such employments with a null group can get created, too. This commit moves the setting of the group to the pre_save signal, thus preventing an invalid employment from getting created. Closes #2374, Closes #2122
Do this search: http://rsr.akvo.org/en/admin/rsr/employment/?o=2&q=WaterNet and sort on the User column. We see that Jean-Marie is employed twice. That should not be allowed.
The text was updated successfully, but these errors were encountered: