CiviCRM Community Forums (archive)

This is one from e-mail discussion that I wanted to move to the forums so we don't lost sight of it (even though we might not want to think too much about it right now)

Piotr

"was fixing an issue with participant import today (participant
statuses not importing properly) and ended up altering logic of
API 2’s _civicrm_participant_formatted_param().

Previously, it only handled participant_status_id,
but actually required it to have the status label
(i.e., was broken when passed the numeric id).

I fixed this in r33362 and r33366 to

— allow for a label in participant_status (resolving it to the
relevant status id and putting it in participant_status_id),

— leave participnat_status_id alone if it’s number-ish (an
integer or a string that coerces to a non-zero integer),

— keep handling the previously-handled situation of a label in
participnat_status_id (i.e., resolve it to the relevant status id).

The only edge case that is broken with these fixes is if someone
calls the API directly and passes an integer-starting status label
(‘2foo’, for example) as participant_status_id (PHP will happily
coerce this to 2), but I’d rather have this regression than
a non-working participant status import (and I’d argue passing
labels as *_id fields is not something we must always support…)."


Personally I think we need a function in Utils that will handle / allow 'odd' fields like

participant_status_label (Participant api)
option_group_name (OptionValue api)

I'm sure I'm not the only one who doesn't want to see the api v2 system of having functions like  _civicrm_participant_formatted_param() flourish in v3 but there are cases where 'names' rather than IDs should be supported for convenience & I thought it would be good to compile a list

NB - I'm not keen on v3 supported participant_status_id that can be string or label - I'd rather support the 2 separately as _label & _id.