Feature/retro participation

[pulsedemon]

No description provided.

[vanderhoop]

This looks great, but there's a weird bug in that, if a user had a session before the user persistence story got merged, this persistence breaks in the retros controller, because the user on session isn't backed up by a persisted record, and therefore no user is available to pluck the id off of. we could handle that via having a consistent dev user that we add in seeds? @pulsedemon @Zanadar thoughts?

example:

[pulsedemon]

@vanderhoop Regarding the issue you mentioned about an existing session without a record in the users table: What if we add a check somewhere to kill their session when a db record doesn't exist? This is an edge case, so we could remove the code later on.

[vanderhoop]

@pulsedemon that's a good thought; we really just need a bridge until all the sessions that could have been introduced expire. let me sleep on it; we might be overthinking the problem.

[vanderhoop]

yo @pulsedemon! yo @Zanadar to handle this edge case, the simplest thing we can do is to NOT persist a participation when there is no user returned by Repo.get_by(User, email: user["email"]) Then, in a couple weeks, we can remove this code, as it's only a bandaid.

Get that in, and we can merge this puppy.

[pulsedemon]

@vanderhoop if we do that, then once the email stuff is merged in, those users will be left out of the emails.

[vanderhoop]

That's fine for now.

…

On Wed, Apr 26, 2017 at 8:56 AM Michael Squashic ***@***.***> wrote: @vanderhoop <https://github.com/vanderhoop> if we do that, then once the email stuff is merged in, those users will be left out of the emails. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#115 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AELvVd4YOhTaUoCfuMkP1JUzp6lj9gtoks5rz1sKgaJpZM4NIAuE> .

[vanderhoop]

@pulsedemon the reason that's okay for now is that those users aren't getting emails right now anyway.

[coveralls]

Coverage decreased (-0.7%) to 94.444% when pulling 454776c on feature/retro-participation into 6f09aa3 on master.

[vanderhoop]

@pulsedemon @Zanadar Shit. Didn't realize this lacked tests for the AuthController code. we need a test that a Participation is persisted when there's a persisted user.

[coveralls]

Coverage decreased (-0.8%) to 94.382% when pulling e792186 on feature/retro-participation into 6f09aa3 on master.

[vanderhoop]

mergin'!

[coveralls]

Coverage decreased (-0.8%) to 94.382% when pulling 21ccbeb on feature/retro-participation into 6f09aa3 on master.