Expand possible dates for reminder emails

[cielf]

Summary

Allow reminder emails to be sent out on different bases -- e.g. quarterly or on the 3rd Friday of the month

Details

This will impact the reminder email dates both on the organization and the partner group levels -- and will impact the view and edit of the organization and the partner group, as well as the sending out of the reminder emails (services/partners/fetch_partners_to_remind_now)

Expand how the banks can specify the reminder date -- so they can, for instance, send out reminders the third Thursday of every month, or every n months on the 5th,

Hints: Look at the icecube gem. We think that's what we need.

Criteria for completion

• expanded ability to specify reminder months
• tests to support

[jlandiseigsti]

I'm interested on taking this issue on – is it spoken for yet?

[cielf]

@jlandiseigsti It's yours!

[jlandiseigsti]

I wanted to list out the new possibilities we are including, so that I can ensure that they are all covered.

The reminder emails can be sent out:

Every n months
On the xth (the 11th)
OR
On the first/second/third/fourth/last day of the week (eg Monday, Tuesday)
OR
On the first/second/third/fourth/last weekday/weekend day

Question: Are multiple reminders per month allowed?

[jlandiseigsti]

Some brainstorming on backward compatibility:

Currently, reminder_day, in both the Organization and PartnerGroup models, is just an integer that represents the day of the month. My thought was to add a new attribute, something like reminder_schedule, that would be theIceCube::Schedule converted to either an iCal string or a hash.

We could change the logic in the FetchPartnersToRemindNowService so that it returns a partner to notify if either the reminder_schedule or reminder_day matches the current day, and have a comment that the reminder_schedule is preferred. The new and edit pages could always create reminder_schedules so future organizations would use that, but reminder_day is still in place for older orgs.

Or we could figure out what it takes to remove reminder_day. It would involve some creating reminder_schedules for all the existing models that currently use day and updating the db. This feels a little scary to me since it's A) running a lot of SQL on a lot of info and B) timing-sensitive, as this would be a breaking change and the release would have to match it.

I'm inclined towards option A over B, but wanted to hear from those who know this app better than I do. Perhaps there is a C that I am overlooking!

[cielf]

Instead of backward compatibility, I would lean to migrating the current data to the new way of doing things (in my experience, that is the rails way of doing things)

[cielf]

As for multiple reminders per month, I don't think we'd be reminding the same partners more than once a month at this point.

[cielf]

Also "
On the first/second/third/fourth/last weekday/weekend day" I'm not sure we need this, but if we get it "for free" I'm not going to say to suppress it. (Though I am curious what it does about holidays)

[jlandiseigsti]

Thanks for the quick responses! One other question: the gem recurring_select has built a slick front end element for this: however, the last update was six months ago. If anyone knows of a similar front end gem that is updated a little more regularly, let me know; I'm a little hesitant to use something that may not be well-maintained.

[cielf]

Pointing @dorner at the above comment

[dorner]

Ideally we'd use a straight JavaScript module rather than a gem... but I spent some time googling and couldn't find any that weren't part of a huge framework. 😦

I agree that recurring_select might not be the best choice - this issue concerns me, for example. But to the best of my ability I couldn't find anything else. ice_cube seems to be pretty well maintained, so if it's not a ton of work to build a frontend on top of that, I'd probably like that better. But if it seems daunting, I'm OK with using recurring_select. Worse comes to worst, we can fork the gem ourselves.

[github-actions]

This issue is marked as stale due to no activity within 30 days. If no further activity is detected within 7 days, it will be unassigned.

[github-actions]

Automatically unassigned after 7 days of inactivity.

[github-actions]

This issue is marked as stale due to no activity within 30 days. If no further activity is detected within 7 days, it will be unassigned.

[github-actions]

This issue is marked as stale due to no activity within 30 days. If no further activity is detected within 7 days, it will be unassigned.

[github-actions]

Automatically unassigned after 7 days of inactivity.

[cielf]

If you're interested in picking this up, please continue on with @jlandiseigsti's PR, #4606. It needs some functional tweaking, but is pretty close!