Let users choose how many days in advance they want to receive issue due date reminders via email
|Assignee:||Jean-Baptiste Barth||% Done:|
|Target version:||Candidate for next major release|
Here at Planio Hosted Redmine, we've recently activated our version of the issue due date reminders that can be triggered via the
redmine:send_reminders rake task.
Our users told us that they'd like to set the number of days before such reminders themselves individually rather than obeying the default set by the admin. Here's a patch for this against Redmine 1.4.7 that should be easily portable to current trunk. It doesn't contain tests in itself, just fixes the fixtures to keep current tests running.
#2 Updated by Jean-Baptiste Barth about 3 years ago
- Assignee set to Jean-Baptiste Barth
I think that's not a good default value, as it may break existing behaviour for current users of this feature, and they will have a hard time figuring out what happens. Now the number of days is fixed by the admin as a parameter when he launches the rake task yeah ? I don't really know how to deal with that cleanly without an additional parameter..
#3 Updated by Jan from Planio www.plan.io about 3 years ago
Jean-Baptiste Barth wrote:
I think that's not a good default value, as it may break existing behaviour for current users of this feature, and they will have a hard time figuring out what happens.
I agree. I still like this patch as it gives the user more control over the amount of mail they receive (which I think is important). But it's a bit of a breaking change... Not ideal, I know.
Now the number of days is fixed by the admin as a parameter when he launches the rake task yeah ? I don't really know how to deal with that cleanly without an additional parameter..
The parameter is defined by the admin running the script, yes. It defaults to 7. So, an easy option would be to switch to 7 in this patch as well. Another alternative could be to forcefully set every user's value to the value specified in the rake task once the rake task runs UNLESS the user had set their own value before. Not sure if its a bit too magical for what we're trying to do. But at least it would not break any existing behavior.