CiviCRM Community Forums (archive)

*

News:

Have a question about CiviCRM?
Get it answered quickly at the new
CiviCRM Stack Exchange Q+A site
This forum was archived on 25 November 2017. Learn more.
How to get involved.
What to do if you think you've found a bug.



  • CiviCRM Community Forums (archive) »
  • Old sections (read-only, deprecated) »
  • Developer Discussion »
  • APIs and Hooks (Moderator: Donald Lobo) »
  • Improvments request for fields/exportableFields methods
Pages: [1]

Author Topic: Improvments request for fields/exportableFields methods  (Read 658 times)

xavier

  • Forum Godess / God
  • I’m (like) Lobo ;)
  • *****
  • Posts: 4453
  • Karma: 161
    • Tech To The People
  • CiviCRM version: yes probably
  • CMS version: drupal
Improvments request for fields/exportableFields methods
February 04, 2011, 04:30:06 am
Hi,

To make easier to use the api, we are introducing a new action getfields for all the entities. Its goal is to list all the possible fields, eg: http://api.crm/civicrm/ajax/rest?json=1&debug=1&version=3&entity=contact&action=getfields

(on the api.trunk only so far)
Code: [Select]
function civicrm_contact_getfields( &$params ) {
    require_once 'CRM/Contact/BAO/Contact.php';
    $contact = new CRM_Contact_BAO_Contact();
    return ($contact->exportableFields('All'));
    //return ($contact->fields());
}

It returns all the fields, but that's not always the fields as they are used by the BAO and exposed on the api. For instance, it is contact_id instead of id that is needed.

As per Piotr's suggestions, I looked into xml/schema, but it doesn't seem to be defined there either.

How to retrieve that the api is expecting contact_id in that list ? I would have hoped/expected to have that as the unique name,  but ain't that.

lobo and al, patches welcome ;)

Code: [Select]
{
"id":{
"name":"id",
"type":1,
"title":"Internal Contact ID",
"required":true,
"import":true,
"where":"civicrm_contact.id",
"headerPattern":"\/internal|contact?|id$\/i",
"dataPattern":"",
"export":true
},
"contact_type":{
"name":"contact_type",
"type":2,
"title":"Contact Type",
"maxlength":64,
"size":30,
"export":true,
"where":"civicrm_contact.contact_type",
"headerPattern":"",
"dataPattern":""
},
"contact_sub_type":{
"name":"contact_sub_type",
"type":2,
"title":"Contact Subtype",
"maxlength":64,
"size":30,
"import":true,
"where":"civicrm_contact.contact_sub_type",
"headerPattern":"\/C(ontact )?(subtype|sub-type|sub type)\/i",
"dataPattern":"",
"export":true
},
"do_not_email":{
"name":"do_not_email",
"type":16,
"title":"Do Not Email",
"import":true,
"where":"civicrm_contact.do_not_email",
"headerPattern":"\/d(o )?(not )?(email)\/i",
"dataPattern":"\/^\\d{
1,
}$\/",
"export":true
},

-Hackathon and data journalism about the European parliament 24-26 jan. Watch out the result

Donald Lobo

  • Administrator
  • I’m (like) Lobo ;)
  • *****
  • Posts: 15963
  • Karma: 470
    • CiviCRM site
  • CiviCRM version: 4.2+
  • CMS version: Drupal 7, Joomla 2.5+
  • MySQL version: 5.5.x
  • PHP version: 5.4.x
Re: Improvments request for fields/exportableFields methods
February 04, 2011, 08:44:49 am

all civi tables have an id column

as such id by itself is never unique IF you are referring to multiple tables.

in most cases, where there is only one instance of an ID being referred to, we use the table name (w/o the civicrm_), so

contact_id, event_id, address_id etc

however in some cases where there are multiple contacts involved (relationship, activity etc), we use different names based on context

contact_id_a, contact_id_b

OR

source_contact_id, target_contact_id (which is an array), assignee_contact_id, created_id etc

so in general, IMO, the convention of "TABLENAME"_id should work in most cases

We need to remember that names/labels by their very definition are ambiguous, so trying to put too much order into them might be an exercise worth avoiding

lobo
A new CiviCRM Q&A resource needs YOUR help to get started. Visit our StackExchange proposed site, sign up and vote on 5 questions

xavier

  • Forum Godess / God
  • I’m (like) Lobo ;)
  • *****
  • Posts: 4453
  • Karma: 161
    • Tech To The People
  • CiviCRM version: yes probably
  • CMS version: drupal
Re: Improvments request for fields/exportableFields methods
February 04, 2011, 12:32:40 pm
Hi,

Would it be possible to use the unique in the xml/schema to store that it so we get directly the 100% sure working name ?

Would it have a side effect or can I have a go at it ?

X+
-Hackathon and data journalism about the European parliament 24-26 jan. Watch out the result

Donald Lobo

  • Administrator
  • I’m (like) Lobo ;)
  • *****
  • Posts: 15963
  • Karma: 470
    • CiviCRM site
  • CiviCRM version: 4.2+
  • CMS version: Drupal 7, Joomla 2.5+
  • MySQL version: 5.5.x
  • PHP version: 5.4.x
Re: Improvments request for fields/exportableFields methods
February 04, 2011, 12:54:59 pm

we should do this for ALL the tables and hence all the xml files

however its a pretty big change and we'd prefer to do this at the start of a release cycle than just before code freeze

i'd vote to do it in trunk when we branch 3.4 / 4.0

lobo
A new CiviCRM Q&A resource needs YOUR help to get started. Visit our StackExchange proposed site, sign up and vote on 5 questions

xavier

  • Forum Godess / God
  • I’m (like) Lobo ;)
  • *****
  • Posts: 4453
  • Karma: 161
    • Tech To The People
  • CiviCRM version: yes probably
  • CMS version: drupal
Re: Improvments request for fields/exportableFields methods
February 04, 2011, 02:30:28 pm
Ok,

Will hack something on getfield action, or on civicrm/ajax/doc then

X+
-Hackathon and data journalism about the European parliament 24-26 jan. Watch out the result
Pages: [1]
  • CiviCRM Community Forums (archive) »
  • Old sections (read-only, deprecated) »
  • Developer Discussion »
  • APIs and Hooks (Moderator: Donald Lobo) »
  • Improvments request for fields/exportableFields methods

This forum was archived on 2017-11-26.