metadata specification pattern about org.civicrm.api4 HOT 2 OPEN

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

from org.civicrm.api4.

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 🗄️ 📁

from org.civicrm.api4.