ISSUE:
The cohort webservice functions allow for the creation of cohorts that include values for the external idnumber field, but they inconsistently allow for the lookup of cohorts and cohort_members based on the idnumber value. This should be uniformly supported across the cohort functions. This will allow external systems to create and populate cohorts consistently without both systems needing to know and store the id/idnumber pairs.

SUMMARY:
There are 7 cohorts webservices:
core_cohort_get_cohorts,
core_cohort_create_cohorts,
core_cohort_delete_cohorts,
core_cohort_update_cohorts,
core_cohort_add_cohort_members,
core_cohort_delete_cohort_members,
core_cohort_get_cohort_members

Of these only a few support the use of the IDNUMBER field associated cohorts and users. Some allow for lookup based on ID or IDNUMBER, some allow ID and USERNAME (in the case of core_cohort_get_cohort_members, and core_cohort_add_cohort_members) and others only allow by ID.

Considering that external systems must create their own cohorts into moodle (or provide admins with the capability of applying a specific cohortid to a related object), and the fact that some service functions allow for the passing of IDNUMBER, it would make sense if this was handled in a more unified fashion across the services.

FIX:
I've introduced an optional field called "type" that can be used to tell the service what kind of ID field the id value is a reference to. This has been added to all of the services in an applicable spot (this is either with the ID/IDNUMBER, or as second argument passed in to the service. The precedence for this is set with core_cohort_create_cohort's category['type'] and the core_cohort_add_cohort_members cohorttype['type'] and usertype['type'].

I know that according to the Webservice API documentation, altering the API is a very taboo thing to do. Keeping this in mind, I made sure that all functions work as-is, thus preserving existing calls to the webservice. The type requirement for the ID fields of some of the services changed to be more relaxed, and the service functions handle that correctly.

FUTURE STEPS:
There are some things that should be modified during an API breaking cycle, but these are not included here. The two major such suggestions would be 1) to change core_cohort_get_cohorts to be a listing engine that does not require existing knowledge of ID's, and 2) to change how all ID fields are handled to consistently be value/type pairs (as how core_cohort_add_cohort_members currently handles id's) rather than stand alone values (as how core_cohort_delete_cohort_members handles id's).

CODE TO REVIEW:
https://github.com/netw3rker/moodle/compare/moodle:MOODLE_28_STABLE...cohort_webservice_idnumber_support