CiviCRM Community Forums (archive)

I recommend an improvement to the event_search api to include a new special parameter allowing the retrieval of only current and future events (currently not possible)

patch here: http://issues.civicrm.org/jira/browse/CRM-7425

is_current is generally passed as a parameter when it's also a column in the table.
in this case, there's no field in the table -- we have to construct the logic for what defines current/future

so i followed the pattern established for the offset and rowCount "special" parameters that are already available in this function.
as for passing down to the BAO -- this API is constructed from a DAO query, as I recall (don't have it in front of me). wouldn't it be easier to just maintain the additional clause there, along with everything else?

I'm thorn on that one.

On one hand, I like the idea of matching as closely as possible the underlying DB, on the other, what happen in 6 month time if we change the structure and implement is_current as a field instead of calculated value ?

I'd argue as I user of the api, I don't care how that's implemented, and the is_current is coherent and does what it says on the box.

Agree with Eileen, shouldn't be a return param, but a "regular" param.

IMO, same goes for return.max_params. Should be rowCount, as in civicrm_contact_get.

X+

P.S. no matter what it should be rowCount everywhere or return.max_results everywhere or whatever, but the same.

The special columns that are currently standard are

'sort'
'rowCount'
'offset'
'smartGroupCache
'return.x'

I agree it would be good to prepend something to the 'special' fields - not sure if we could come up with something that applies to 'is_current' and also to the top 4 (note this would be implemented in v3 (not a change in v2 - Brian - v3 repo is http://svn.civicrm.org/civicrm/branches/trunk.api). If you want to backport the v3 version to code against it (so it will stay there) you might want to change the require once in it to the v2/Utils file or your local to ensure no conflicts for now.

Also, once we agree implementation & description you might want to futureproof your implementation by adding it to one of the event api tests)

As a side node, why would everyone find nicer

array (
return_bla => true,
return_bli => true,
whatever = > 'xy'
);

than

array (
return => array ('bli','bla'), 
whatever = > 'xy'
);

or (mostly as a get param on the rest, already implemented)
array (
return => 'bli,bla', 
whatever = > 'xy'
);

?

"normal" params = value lookups (data)
return.xxx = what fields should be returned
filter.xxx = special use restrictions or behaviors -- which may or may not impact the where clause