search

civicrm / org.civicrm.api4

CiviCRM api version 4
Other
8 stars 19 forks source link

metadata specification pattern #45

Open ErichBSchulz opened 7 years ago

ErichBSchulz commented 7 years ago

@eileenmcnaughton pointed me at the conformance test as a good pattern to follow for API4.

I'm seeing there is a bunch of entity-level and action-level metadata in there, in various flavours of:

I API4 should publish this information via getActions() and getFields() in order to make it discoverable?? and should there be a centralised 'source of truth'??

eileenmcnaughton commented 7 years ago

ah yeah - those things reflect the places where our api aspirations surpass reality. We don't do getActions because one of our rules is 'If there is a crud api it should implement all crud actions' - so discovering the actions will omit the entities who have failed to live up to that rule

ErichBSchulz commented 7 years ago

mmm... I guess this tied to #29 (which is still a separate issue in my mind still ).

so I'm on the path of add "functional get methods" for " Contact, Contribution, Participant, Activity"...

currently I know that if I add contribution (for example) to API4 I can make extend my crude "sample data factory method then the generic "conformance" test will try and do a full set of CRUD on it. Only @JoeMurray said he doesn't want the API to be able to delete contributions (and the little bit of accounting training I've had screams agreement with that)... and there maybe entities that we dont want to create directly (but allow updating and getting??) and at a field level, some fields that maybe updated via the API and those we dont want directly touched?

so I'm thinking specifying some of these rules as metadata would be a good thing?? but in the API layer?? or extending the XML that drives the DAOs??

I can just start adding exceptions to the unit test - but that just feels like the wrong place :file_cabinet: :file_folder: