Hello guys,

What would be the best way to generate custom reports and custom pages from the data in lime? What I'm trying to do is as follows:

1. create custom lists of responses (for now just to display or export the respondents who passed screening and those that failed.)

2. create a translation page for submitted responses (both closed and open ended).

3. on the same page, a coding/tagging interface for translated responses to categorize them for reporting.

4. create custom reports based on the coded responses.

Thanks,
Mark

Hello Mark,

I'll move this thread to the "Development" forum, I think it's better to discuss it there.

thanks, steve. =)

I've been playing around with custom reports. The biggest challenge is the SGQA naming conventions. In version 2, a unique question code is likely to be required, I'm hopeful that the actual field names in the database will then be those codes, which will make external custom reports trivial: select * from results_<code>, then display the values you want.

Perhaps the YII architecture or the API will make custom reporting easier as well.

Tac

Tac-

Sounds like a good configuration option: give users the ability to specify whether to use SGQA or Qcode naming in the database. That's an easy change for the database, but would have broader implications for the statistics reporting and quotas.

We'd likely need to either change the variable names for the "reserved" fields in the database (like sid and submitdate) so that Qcode names don't overwrite those values.

perhaps the lime vars could be prefixed, e.g. lime_sid, lime_submitdate? Alternatively, there could just be a list of reserved words.

The bigger implication is for EM, but EM already supports question codes. I know a lot of JS exists using the SGQA naming, although I don't understand how those surveys are ever able to be moved.

I'm hoping that reports will be rewritten using MVC architecture anyway. I still haven't gotten a chance to dive into the Yii version yet. Is that being actively developed at the moment?

Tac

@tacman1123, thanks for bringing up the idea of the yii framework. =) is it possible to create the app externally instead with yii? i've only tried yii a little a bit. is it possible to create custom lists/forms from custom mysql in yii?

Two issues, not specific to Yii, but to any external program.

1. Security: Not sure if/how to integrate LS tokens and security with an external app.
2. Database: "Select * from <results_table>" gives you back a list of SGQA indexes to your data. You can write a custom report based on that, but then if you ever move it, or copy the survey, or whatever, the report won't work.

Tac

How about an alternative approach: Convert response data in Limesurvey into a different table structure (one row per response with related data like SID, GID, QID, ...). This way you can get rid of the strange column naming at Limesurvey and can easily query data fro a certain survey, group or question.

Another approach might be to use some more tables, e.g. one table for the raw answer data with an ID pointing to table 2 which holds general information on related SID, GID, QID, parent_QID and the like. You can even have a thrid table with all the metadata like related token, submitdate, ref. URL, ...

In general it all depends on how you want to analyse data, which layout a certain tool needs to rely on and the like.

I've spent the last few hours poking around the Yii branch, trying to figure out a strategy for adding custom reports. The reason I'm using Yii is that it seems more likely to be included in the LS core, as I assume 1.92 is pretty much frozen.

Part of the issue is figuring out how to associate reports with specific surveys. I guess it could be done the same way that token attributes are done, a new field in the survey table that's a list of reports. The UI could then render that list for those reports.

For reporting, I prefer using Twig, and see that it can be easily integrated with Yii (yiiext.github.com/extensions/twig-renderer/index.html). Not sure the best way to get community buy-in that having Twig as an option is a good idea. I resisted it for a long time ("After all, php IS a templating language!"), but once I adopted it I became a huge fan, and it makes the MVC architecture easier to follow.

Eventually I'll figure out git and branches and just add it to my repository and do a pull request once it's working and can be justified.

Tac