rubyforgood / human-essentials

Human Essentials is an inventory management system for diaper, incontinence, and period-supply banks. It supports them in distributing to partners, tracking inventory, and reporting stats and analytics.
https://humanessentials.app
MIT License
436 stars 449 forks source link

Investigate Custom Devise Mailer #4384

Open elasticspoon opened 1 month ago

elasticspoon commented 1 month ago

Summary

So we have a custom devise mailer that seems to be responsible for setting the subject line for Partner invitations.. Tests for reference

The code looks something like this:

if resource.has_role?(Role::PARTNER, :any) && resource.id == resource.partner.primary_user&.id
  # do something
elsif resource.has_role?(Role::PARTNER, :any) && resource.id != resource.partner.primary_user&.id
  # do something else

This code (I think at least) sends one message if the user being invited is the primary user for the Partner and another if they are not.

Criteria for Completion

Figure out if this code is correct:

Historical context:

The mailer was originally added here: https://github.com/rubyforgood/human-essentials/commit/ff961af7f5051ec6e05dd9cdd4d055b5e650431d. It simply changed the invite message for inviting Partners instead of Orgs.

    if resource.is_a?(PartnerUser)
      "You've been invited to be a partner with #{resource.partner.organization.name}"  

https://github.com/rubyforgood/human-essentials/pull/2232 allowed Partners to invite coworkers by checking that the inviter was the primary user for that Partner:

 if resource.is_a?(PartnerUser) && resource.id != resource.partner.primary_user&.id
      "You've been invited to #{resource.partner.name}'s partnerbase account"

https://github.com/rubyforgood/human-essentials/pull/3050 got rid of PartnerUsers and instead used partner_id

if resource.try(:partner_id) && resource.id == resource.partner.primary_user&.id
      "You've been invited to be a partner with #{resource.partner.organization.name}"

https://github.com/rubyforgood/human-essentials/pull/3117 finally when roles got added we started checking by role instead of partner_id

if resource.has_role?(Role::PARTNER, :any) && resource.id == resource.partner.primary_user&.id
      "You've been invited to be a partner with #{resource.partner.organization.name}"
cielf commented 4 weeks ago

Ok --- that actually makes sense -- if the resource is the invitee! On Sunday, we were talking about it as if the resource was the inviter.

So what's happening is that when we set up a partner, there is a primary user email. At some point (maybe not until we invite) we create a user for that person, and point to it as the primary user.

That user is going to get the "You've been invited to be a partner..." message.

But subsequent people who are added to that partner are going to get the message that says they've been invited to the partner's account.

And to return to the prompting question (can we change all to has_active_role?) -- Hmmmm... is there anyway that we could get to this code without them having an active role? I doubt it. I expect that when they are invited, their role gets added, and that if they already have a role on the partner, even a deactivated one, they can't be added -- but we should check that manually.

cielf commented 5 days ago

Oh, and to further answer some of the questions. Yes, partners can invite people to have the partner role on that partner.

cielf commented 5 days ago

@elasticspoon Is this all moot if we are going with the simpler architecture as discussed (i.e. can this be closed, in your opinion?)

elasticspoon commented 5 days ago

I totally forgot about this. I think it makes sense to close this if we open a related issue to change the mailer.

That is to say. I won't need to change this because of the role thing. But I do think that the logic is incorrect in the mailer. Feel free to correct me if you think otherwise.

I think we should be checking that a user has the partner role with a specific resource, not just a partner role in general to make that invite.

cielf commented 5 days ago

@elasticpoon If the resource is the invitee, rather than the inviter, the logic makes good sense.

We send a different message to the primary partner id -- because they're the first, than we do to subsequent users for the partner.

I can think of a weird edge case (someone that is a partner, then gets invited to a bank) that might go awry. But I'm not sure if this code even gets executed if they're already a user. So I'd have to test it out.

I admit, I'm not 100% exactly what "resource" is in this case -- so I may need to dig more.