CiviCRM Community Forums (archive)

One 4.2 change coming out of the sprint is that we added transactions & rollback to the API. This means that if a chained API call fails on a sub call then the entire transaction will be rolled back & an error message will show at the top level.

Also, I trialled a syntax for doing post-failure checking on api calls that fail due to a unique constraint - at the moment it requires the constraint to be added to the _spec function. I don't think querying the indexes is realistic but this definition could be pushed down to the XML - this is in place on Option Group api

- I trialled a fix for handling is_primary for phone (hoping someone will QA it before I try to push it to other location types)

- fixes for getfields & custom - wasn't coping with case correctly ie. entity = Contribution worked but not contribution.

- fix for export csv via cli - no field was being returned when empty - causing the rows not to line up in csv (thanks to Joe for logging bug which led to this & Noah Miller for picking it out of the queue & working with us to get it fixed - Noah was also the first to suggest the right fix but we had to figure out why & what it would impact before we agreed with him :-))

Good stuff Eileen, have a coffee! And I will have a look at the phone is_primary fix if you like, where did you put it?

Am I missing something? The new phone handling is on the BAO, but you give me a link to Email.php? Too much milky coffee?

Existing error doesn't tell you what field it failed on (or even really the nature of the failure).

We found that the API based get functions were using an API based store-as-array function but the Query object based ones were using one on the query object - that second one was dropping empty fields so we talked it into returning them

At the moment it's inconsistent across API - some will return an empty field & others will return no field. If you want empty fields stripped for ajax maybe that makes sense at the REST wrapper level?

One symptom of stripping is that you export cli wasn't lining up the fields correctly in some cases.

Hmmm that definitely needs cleaning. Not sure I understand your solution, what do you want to do at the getfields level?

I would imagine a wrapper function to deal with pseudo constants in a consistent way, including validation?

OK - so this is what I was talking about

http://svn.civicrm.org/civicrm/trunk/api/v3/examples/ActivityGetFields.php

If you check the priority id it has interpreted the pseudoconstant & added the 'options' array (in the getfields function). The _civicrm_api3_validate_integer checks against the options array & does a swap out if relevant & throws an exception if it's a pseudoconstant, but not a valid key or string.

     
      'priority_id' => array(
          'name' => 'priority_id',
          'type' => 1,
          'pseudoconstant' => 'priority',
          'options' => array(
              '1' => 'Urgent',
              '2' => 'Normal',
              '3' => 'Low',
            ),
        ),

Actually - I think priority would just be an alias for priority_id - in that the way I've done it at the moment priority_id accepts '1' OR 'Urgent'. So, if priority was in the submission we'd just treat it as an alias of priority_id.

We probably wouldn't advertise priority but we'd support it because it's simpler to do so than not do so as we are committed to supporting 'membership_type' & a bunch of others.