Using a seperate content type for each survey type means the create content page is going to be a mile long for those who wish to use this module to create lots of different surveys. Can we include an additional setting, or use taxonomy to seperate survey types rather than building a completely new content type for each type.

Suggest: -

1) Building a content type for each set of access permissions.
2) Include survey types options on settings page.
3) Assign a survey label to each node within each enabled survey type, or check boxes to allow nodes to be in multiple survey types.
4) Produce take survey and show results pages according to survey types.
5) Additionally be able to filter survey through time arguments in the url string.

Comments

gibus’s picture

gibus commented

Thanks for this comment, browlands. You're right and it would be interesting to implement it. Have you got any idea for example about a good way to guarantee backward compatibility?

gibus’s picture

gibus commented
Status: Active » Needs work
browlands’s picture

browlands commented

Existing content types, representing the different types of survey could: -

1) Remain as their existing content type, and apply a taxonomy term representing the survey type
2) Convert into the new single content type, and apply a taxonomy term (using http://drupal.org/project/node_convert, or code taken from it).

Option 2) would most likely be adopted by most users though 1) would remain for those with only a few survey types who can't be bothered to convert their nodes.

So your settings page would list all content types and include a check box next to each for those content types to be included as survey types. Typically for new users only one content type will be the content type available to use as a survey.

The taxonomy would represent the survey type.

You need to program the creation of the survey type, the creation of a taxonomy (call it survey types or something) and place a check against the new content type as a node type available for terms on the taxonomy page.

Create two views: -

1) All responses, taxonomy (single) and role (multiple) arguments per survey type. Tabs for responses in last day, week, fortnight, month, quarter, six months, year, ever.
2) All responses, taxonomy (single) and role (multiple) arguments per survey type. Additionally expose filters for from and to dates and roles.

Web designers could clone either of these two to build their own particular views, if say they wanted to exclude particular users, or be gender specific for example. You might need to employ, I think one or two modules available which aggregate data in views.

Using views is a good idea because this allows caching the query and HTML output, for sites not wanting servers to calculate data for each view on the fly, plus the flexibility of allowing a level of customisation without breaking the code.

The access permissions for each survey wouldn't be a problem as the view could be manipulated by users to filter any unwanted responses (say authenticated user had access to write survey response but the web designer wanted a view only for unauthenticated users on a particular survey response.) As long as the web designer clones a view, sets the path, arguments and filters sensibly the correct data will be returned.

Grayside’s picture

Grayside commented

I would take a page from the casetracker module (and integration with casetracker2 in the future would be a good idea!).

Have two node types. One is a survey type, and the other is a specific option. The option has a CCK nodereference or the like to the Survey type. On that basis, you can put together whatever Views you need.

Interesting module, interesting idea. Thank you.

gibus’s picture

gibus commented

I will published a new release (6.x-2.0) next week taking into account this issue, implementing a taxonomy term to identify each survey and a default nodetype (leaving the possibility to use any other nodetype, for backward compatibility or for each set of access permissions). Everything is already implemented but I need to do more test for upgrade from previous release and also update the documentation...

Note that, I will not include in this release the creation of default view since this is another issue. Moreover I'm not sure of what is exactly requested with these views. Anyway, views can still be produced manually if not given automatically by this module. But if this is really needed, I would encourage browlands to fill another issue. Best would be to provide view code you want ot be included.

Hope you'll be happy with this new release.

gibus’s picture

gibus commented
Status: Needs work » Fixed

Revision priorities 6.x-2.0 has been released, see release notes.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.