CiviCRM Community Forums (archive)

Hello all,

I need a workaround for the seemingly arbitrary selection of fields available in the "Selection Criteria" area of the Member-detailed report, although the inability to simply select whatever fields are available to report seems to be a "feature" of all the CiviReports.

That said for context, here is the actual post:

I have a programmer building me a template page for the Member-detailed report that allows the selection of any available field, including tags and groups.

That said for further/more detailed context, here is the most granular portion of the post:

My programmer tells me that he needs to fix an error with labels for "tags" and "groups" which for some reason, show "status".

He then says (and I am having trouble deciphering this portion) that the labeling error is caused by a bug in CiviCRM exacerbated by a field having the same name in the database, even if it is in a different table (??).  He goes on to use the example of the table for "tags" and the table for "membership_status", both tables have the field "title", which when the report form is built, is treated as one, and so only the most recently processed version of the label is applied, screwing up the report.

He ends by saying that for fetching tags and groups, he made a workaround and instead of using the built-in functionality, he is using GROUP_CONCAT aggregate function from MySQL, which will be faster (I am not sure in which context "faster" applies: faster execution, faster build time, etc.)

I am posting this information as an informative help rather than a criticism.  The criticism is the semi-informed opinion that it would be much, much better and perhaps even less complex to build and maintain, to simply present all currently available fields in the "Report Criteria" area of all reports, and let the person who actually needs the report to decide how to build it out.

On a more pleasant but equally honest note, I am deeply grateful to have CiviCRM at all, much less as the super-capable platform it already presents itself to be.

Hi lobo,

Thank you very much for taking the time to reply.

W/o trying to sound like a smartaleck (sincere) . . I'm paying for results, by the hour.  Posting here is not part of the project specification, although I will ask if he would like to do so on his own time.  Decades of [my] successful project facilitation/management correspondence has been been plenty useful to all manner of other interested parties, so I posted here in the hope of initiating focus on a potential issue, and to offer insight [such as it is] into how others are handling that particular issue.  I doubt that didn't sound smartalecky, although no such intention exists.  I'm sure you had no such intention either, so no one has to make time to be offended.

As I am not paying to scale this functional shortcoming, but remediate it within a very narrow context, The extensibility of the MySQL function in question does not fall within this project specification either.

What would be very helpful indeed , is to be able to exactly confirm and verify that an upgrade would predictably result in the alleviation of this [what is for me] particular problem of field selection in the reporting area(s), or reference the documentation link that addresses same.  "Trying" an upgrade on a production system w/o documented reasoning is not going to be acceptable in my situation.

I am requesting said verification, or a link to the respective documentation.  Even an ill-tempered reference to a comparison between my current reporting feature set and that of the newest version would be welcome. (weak attempt at humor)