-
Notifications
You must be signed in to change notification settings - Fork 49
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
🎁 adds batch email, depositor email, and user stat to Account Settings #2429
Conversation
Test Results 3 files ±0 3 suites ±0 17m 24s ⏱️ -19s Results for commit fe02a77. ± Comparison against base commit 9f98d14. This pull request removes 43 and adds 44 tests. Note that renamed tests count towards both.
♻️ This comment has been updated with latest results. |
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.
The concept here is fine, but the implementation needs rework. “ENABLED” is implied. The flag is either on or off and that word is just extra. Also, all settings in Hyku should use AccountSettings. The automatically handles the Boolean issue, makes them settable per tenant or globally and provides consistency.
I recommend BATCH_EMAIL_NOTIFICATION for the env var name |
Thanks for the reminder. That's definitely easier to manage. I'll make the updates as suggested. |
@@ -16,6 +16,7 @@ | |||
allow(Apartment::Tenant).to receive(:switch).with(account.tenant) do |&block| | |||
block.call | |||
end | |||
allow_any_instance_of(Account).to receive(:find_or_schedule_jobs) |
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.
Thoughts about this? This spec was failing because of the after_save addition. cc @orangewolf
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.
Yes, this seems fine
- Updated `find_or_schedule_jobs` to dynamically include jobs based on environment variables. - Introduced the following environment flags to control job scheduling: - `ENABLE_BATCH_EMAIL` for `BatchEmailNotificationJob` - `ENABLE_DEPOSITOR_EMAIL` for `DepositorEmailNotificationJob` - `ENABLE_USER_STAT` for `UserStatCollectionJob` - This allows buggy jobs to be disabled temporarily without modifying the codebase. - Default behavior ensures only non-buggy jobs are scheduled when flags are not set.
- Adds batch_email_notifications, depositor_email_notifications, and user_analystics to account settings - only displays batch email frequency if batch email notifications are enabled from account settings
When certain account settings (user_analytics, batch_email_notifications, or depositor_email_notifications) are updated, the system will now automatically schedule the corresponding background jobs. This eliminates the need for a server restart to activate these features. - Added after_save callback to detect settings changes - Added logic to compare relevant settings before and after save - Triggers find_or_schedule_jobs when settings change This ensures features like user analytics start working immediately after being enabled through the settings interface.
Simplifies the #schedule_jobs_if_settings_changed method to be more intuitive and easier to maintain: - Replace database column check with direct settings check - Add descriptive variable names and comments - Break complex logic into clear, distinct steps - Improve code organization with early returns The functionality remains the same, but the code is now more self-documenting and easier to understand.
- Add test contexts for enabled and disabled account settings - Verify that EmbargoAutoExpiryJob and LeaseAutoExpiryJob always run - Verify that BatchEmailNotificationJob, DepositorEmailNotificationJob, and UserStatCollectionJob only run when their respective settings are enabled
The account endpoints spec was failing because it attempted to schedule jobs before the tenant schema was created. By mocking find_or_schedule_jobs in this specific test, we avoid the schema error while preserving the actual job scheduling behavior in other tests.
e4695b4
to
fe02a77
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.
This is great Shana!
@@ -16,6 +16,7 @@ | |||
allow(Apartment::Tenant).to receive(:switch).with(account.tenant) do |&block| | |||
block.call | |||
end | |||
allow_any_instance_of(Account).to receive(:find_or_schedule_jobs) |
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.
Yes, this seems fine
Issue:
Feature flags are now visible in ADMIN DASHBOARD > SETTINGS > ACCOUNT. When enabled, they will trigger the relevant background jobs.
Additionally, if disabled a user will not see batch email frequency in their profiles. It also removed their ability to set it:
PROFILE SHOW PG
WHEN DISABLED
WHEN ENABLED
PROFILE EDIT PG
WHEN DISABLED
WHEN ENABLED
NOTES
🎁 add dynamic toggling for job scheduling using environment variables
abf36be
find_or_schedule_jobs
to dynamically include jobs based on environment variables.ENABLE_BATCH_EMAIL
forBatchEmailNotificationJob
ENABLE_DEPOSITOR_EMAIL
forDepositorEmailNotificationJob
ENABLE_USER_STAT
forUserStatCollectionJob
♻️ Refactor to remove ENV vars in favor of account settings pattern
52e90c5
🧹 Automatically schedule jobs when account settings change
06afd3e
When certain account settings (user_analytics, batch_email_notifications,
or depositor_email_notifications) are updated, the system will now
automatically schedule the corresponding background jobs. This eliminates
the need for a server restart to activate these features.
This ensures features like user analytics start working immediately
after being enabled through the settings interface.
♻️ Refactor account settings change detection for better readability
50040bc
Simplifies the #schedule_jobs_if_settings_changed method to be more
intuitive and easier to maintain:
The functionality remains the same, but the code is now more
self-documenting and easier to understand.
✅ update schedule_recurring_jobs specs
30e144c
and UserStatCollectionJob only run when their respective settings
are enabled
✅ update account settings specs
20b1c97
✅ Update create_account_spec.rb
b2794c5
✅ Mock find_or_schedule_jobs in account endpoints spec
fe02a77
The account endpoints spec was failing because it attempted to
schedule jobs before the tenant schema was created. By mocking
find_or_schedule_jobs in this specific test, we avoid the schema
error while preserving the actual job scheduling behavior in other
tests.