CiviCRM Community Forums (archive)

I don't think CiviCRM should be hard coding ANY special behaviors in the code based on status names as long as names and rules can be customized by admins.

For example,

I just had to hack my UpdateMembershipRecord.php file because for some crazy reason, a new status I added called "Suspended" wasn't properly updating.  I wanted this status to be after a grace period status and before the expired status, so it was going to be changing expired memberships to suspended.

In the code I found : (line 164)
           //update membership records where status is NOT - Pending OR Cancelled.
            //as well as membership is not override.
            //skipping Expired membership records -> reduced extra processing( kiran )
            if ( !$dao->is_override &&
                 !in_array( $dao->status_id, array( array_search( 'Pending', $allStatus ),
                                                    array_search( 'Cancelled', $allStatus ),
                                                    array_search( 'Expired', $allStatus ) ) ) ) {

My new status wasn't being used because "Expired" status membership weren't being processed.  This is bad logic in an attempt to save processing...

Looking around in the file there are behaviors based on status names "Deceased", "Pending", "Cancelled", and "Expired"

I'm not sure it makes sense to both allow for custom status names/rules AND hard code behavior based on default names.

It might add some functionality for the bulk of CiviCRM installs...but if an admin starts to customize the status names, they'll start experiencing non-typical behaviors.   And like in my case...cause much frustration.