CiviCRM Community Forums (archive)

Here's code I'm using to change this. It makes activity follow up dates relative to the activity date, not the current date when the activity was created - UNLESS the activity's date is in the past, in which case it uses today's date.

(Why the two possibilities: I'm assuming that if someone creates a follow-up for an activity in the future, they want it to be after the activity in the future, and they're thinking relative to the activity in the future. e.g. "Must remember to call her after the interview - two days later seems best", or "We allow 2 weeks after each mailing before we start making follow up calls". However, if they're editing an event from the past and adding a follow-up, they've probably just done a task or received information that is relevant to that activity, and so they're more likely to be thinking relative to now - the date the activity was originally scheduled for is now a historical detail not a focus of attention)

If you want it to behave like this, here's the code (written for 3.2.3 Drupal).

In .../CRM/Activity/BAO/Activity.php around line 1730, change from:

       $currentDate  = implode( ' ', CRM_Utils_Date::setDateDefaults( ) );
        $followupDate = CRM_Utils_Date::intervalAdd( $params['interval_unit'], $params['interval'], $currentDate );

to:

       $currentDate  = implode( ' ', CRM_Utils_Date::setDateDefaults( ) );
        if ( strtotime($currentDate) > strtotime($params['activity_date_time']) ) {
          $useDate = $currentDate;
        } else {
          $useDate = $params['activity_date_time'];
        }
        $followupDate = CRM_Utils_Date::intervalAdd( $params['interval_unit'], $params['interval'], $useDate );

This works and puts same-format valid MySQL dates in the database. If it doesn't work for you, consider trying formatting $params['activity_date_time'] to match $currentDate (see http://php.net/manual/en/function.date.php - inserting print_r($currentDate); anywhere below where it's defined will show you how it's formatted)

If you want it always relative to activity date, you don't need $currentDate at all:

       $followupDate = CRM_Utils_Date::intervalAdd( $params['interval_unit'], $params['interval'], $params['activity_date_time'] );


The original use-case came from CiviCase, where you are completing an activity (now) and scheduling a followup.

I don't see an issue with changing it to be relative to activity-date.

But for past activities there's some question about whether having it automatically behave differently is in general a good UI design. I would argue for just being relative to activity-date regardless, especially since it would be rare to go back and edit a previous activity solely for the purpose of scheduling a followup - why not just create a new scheduled followup? And if, as you indicate "they've probably just done a task or received information", then, at least in CiviCase context, you would be creating a new activity to record that new task/information anyway, not editing a previous activity.

No problem, thanks in return for having a responsive community! Sadly I don't have time to put together a patch file right now (not least because in the 7 or 8 times in the past I've looked for good 'How to make a patch file' reference resources I've never yet found a practical one that made sense - any handy URLs would be gratefully received!) but it's a really simple change, dropping one line of code and mildly changing another.

On second thoughts I'd also agree that the consistent approach does make more sense - the main kind of scenarios I had in mind were where a task has been completed late and the user adds the follow-up task at the same time as changing the status of the original task to 'done' and adding any notes. If they're doing all this, they really should also be changing the date to the real date the activity happened, and as you say if it's not actually relative to the date it actually happened, it doesn't need to be a follow up event.