CiviCRM Community Forums (archive)

Running through the tests I found a small number of api version conflicts that were in core rather than the test suite

Group BAO
There are 4 places in the group BAO that use the deprecated v2 function

        return civicrm_contact_search( $params );

Which loads api/v2/Contact.php which results in

Fatal error: Cannot redeclare civicrm_contact_create() (previously declared in C
:\utils\eclipseworkspace\api-civicrm\api\v3\Contact.php:61) in C:\utils\eclipsew
orkspace\api-civicrm\api\v2\Contact.php on line 70

Presumably it could be calling
CRM_Contact_BAO_Query::apiQuery
rather more directly

However, I don't know if it's worth looking at the apiquery function first while it's still very lightly used. (about 5 functions call it in all) It looks like it was designed to be called from all the GET apis but only 1 actually does - several others replicate the apiquery function. So, the Contribution_get query for example is basically a copy of apiquery. In particular I note:

-  $skipPermission = false is hardcoded when ideally it would be a $param (although blocked via REST)
- All this cruft below could sit in the apiquery rather than in every GET query - or in an API utils function

    $sort            = null;
    $offset          = 0;
    $rowCount        = 25;
    $smartGroupCache = false;
    foreach ( $params as $n => $v ) {
        if ( substr( $n, 0, 6 ) == 'return' ) {
            $returnProperties[ substr( $n, 7 ) ] = $v;
        } elseif ( in_array( $n, $otherVars ) ) {
            $$n = $v;
        } else {
            $inputParams[$n] = $v;
        }
    }

    if ( empty( $returnProperties ) ) {
        $returnProperties = null;
    }

    require_once 'CRM/Contact/BAO/Query.php';
    $newParams =& CRM_Contact_BAO_Query::convertFormValues( $inputParams );

Don't suppose anyone feels able to jump in & take a look & decide the best replacement - e.g in

    static function isContactInGroup( $contactID, $groupID ) {
        require_once 'CRM/Utils/Rule.php';
        if ( ! CRM_Utils_Rule::positiveInteger( $contactID ) ||
             ! CRM_Utils_Rule::positiveInteger( $groupID ) ) {
            return false;
        }

        $params = array( 'group'      => array( $groupID => 1 ),
                         'contact_id' => $contactID,
                         'return.contact_id' => 1 );
        require_once 'api/v2/Contact.php';
        $contacts = civicrm_contact_search( $params );

        if ( ! empty( $contacts ) ) {
            return true;
        }
        return false;
    }

Ok, I reviewed these places and agree that they need to be switched to CRM_Contact_BAO_Query::apiQuery() (and then – or along the way as needed – it should be made more useful by encapsulating all the things replicated outside it).

I’ll tackle this one-by-one this week; logging is my priority, but I should find time every day to move this forward, so this should be fixed by the end of the week.

Looks like another big source of conflicts is in
class CRM_Activity_BAO_Activity extends CRM_Activity_DAO_Activity
blah blah blah

    static function addActivity( &$activity, $activityType = 'Membership Signup', $targetContactID = null )
   
blah blah blah
      require_once 'api/v2/Activity.php';
        if ( is_a( civicrm_activity_create( $activityParams ), 'CRM_Core_Error' ) ) {
            CRM_Core_Error::fatal("Failed creating Activity for $component of id {$activity->id}");
            return false;
        }

Hmm - but the one I was pointing to is in the BAO - I think the BAO shouldn't call the api as a rule

OK, I just thought there was some inherent threat of conflict there with the api calling the BAO calling the api

But the main problem is that we have a v2 api & a v3 api calling the same BAO function (and also it being called outside the api ) and it needs to work in all cases.

In this case the function is called by another BAO function and I think there might be another in the tree so we'd need to pass 'version' right through from the participant_create that creates the participant to the activity_create that creates the relevant activity

Hi,

This one here is the other one that is causing a problem

CRM/Activity/BAO/Activity.php:1596

But it needs to not call an api or there will be more version issues since both v2 & v3 api call this. Apart from those called by the api I'd wait - at least until Erik & Xavier catch up to write code over a warm beer on Friday!

e.g

   30.2834   33325912  12. api_v3_ContributionTest->testGetContribution() C:\uti
ls\eclipseworkspace\api-civicrm\tests\phpunit\api\v3\ContributionTest.php:0
   30.2835   33327168  13. civicrm_contribution_create() C:\utils\eclipseworkspa
ce\api-civicrm\tests\phpunit\api\v3\ContributionTest.php:94
   30.2884   33334096  14. CRM_Contribute_BAO_Contribution::create() C:\utils\ec
lipseworkspace\api-civicrm\api\v3\Contribution.php:80
   30.3009   33387568  15. CRM_Activity_BAO_Activity::addActivity() C:\utils\ecl
ipseworkspace\api-civicrm\CRM\Contribute\BAO\Contribution.php:280
   30.3550   33629896  16. require_once('C:\utils\eclipseworkspace\api-civicrm\a
pi\v2\Activity.php') C:\utils\eclipseworkspace\api-civicrm\CRM\Activity\BAO\Acti
vity.php:1596

This one here is the other one that is causing a problem

CRM/Activity/BAO/Activity.php:1596

(Bluntly) fixed in r32170.

Another conflict - but in this case we were already undecided as to whether to bring the mailer api into 3 or leave it for now - unless someone who understands it steps up & tells us how it would best fit


space\api-civicrm\tests\phpunit\api\v3\MailerTest.php:483
  157.5291   43040392  14. CRM_Mailing_Event_BAO_Subscribe::subscribe() C:\utils
\eclipseworkspace\api-civicrm\api\v3\Mailer.php:199
  157.5291   43040392  14. CRM_Mailing_Event_BAO_Subscribe::subscribe() C:\utils
\eclipseworkspace\api-civicrm\api\v3\Mailer.php:199