Often a webform is used to gather information from the user that the administrator can use for different purposes. We are using webform to collect people that want to have a leaflet about our organization sent by postal service. It would be great if webform had the ability to mark submissions as read by some sort of toggle button?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

quicksketch’s picture

This probably won't be added, but you can make a select component that is "Private" so that only administrators can see it and then change its value as submissions come in.

lsolesen’s picture

Ok. I already experimented a bit with that and it seems to work allright. The only thing though is that there is no way to see which submissions has been flagged from the overview.

athanor’s picture

In my case all submissions had to be reviewed by let's say "operators". So I use hook_webform_submission_actions to add a "Accept it" link to each submission. Action code changes the value of a new field, "status", in webform_submissions table.

To get better overview which submissions are accepted I replaced the IP address column from submission page to my "Status" column. Works fine.

I did try to this in my custom module but failed so I actually hacked few lines in webform.submissions.inc and webform.report.inc to accomplish this.

lsolesen’s picture

Could you post the code?

quicksketch’s picture

The only thing though is that there is no way to see which submissions has been flagged from the overview.

Yeah, eventually this problem could be solved with Views, if #680386: Views integration for the webform_submitted_data table is completed.

athanor’s picture

function webform_get_submissions($filters = array(), $header = NULL, $pager_count = 0) from webform.submissions.inc, added new line 701:

$submissions[$row->sid]->status = $row->status;

function webform_results_submissions($node, $user_filter, $pager_count) from webform.report.inc
replaced line 52 :

$row[] = $submission->remote_addr; 

with:

$row[] = $submission->status;

in function theme_webform_results_submissions_header($variables) from webform.report.inc
changed the line 151 to:

$columns[] = array('data' => t('Status'), 'field' => 'status');

same in function theme_webform_results_table_header($variables) from webform.report.inc
line 197: to

array('data' => t('Status'), 'field' => 'status'),

in my custom module hook_webform_submission_actions looks like this:

function mymodule_webform_submission_actions($node, $submission) {
  if (webform_results_access($node)) {
    if (!$submission->is_draft) {
      // i query here database because for some reason $submission->status 
      // method does not work. 
       $result = db_query(
        'SELECT t1.status
        FROM webform_submissions t1 
        WHERE t1.sid = :sid
        AND t1.status = 0',
        array(':sid' => $submission->sid));
    if ($result->rowCount() > 0) {
      $actions['myaction'] = array(
        'title' => t('Accept submission'),
        'href' => 'mymodule/' . $node->nid . '/submission/' . $submission->sid . '/confirm',
        'query' => drupal_get_destination(),
      );
    }
    else {
      $actions['myaction'] = array(
        'title' => t('Submission accepted'),
       
      );
    }
  }
  else {
    $actions['myaction'] = array(
        'title' => t('This is a draft'),
       
      );
  }
    
  }

  return $actions;
}

in my module_menu I registered menu item:

$items['mymodule/%webform_menu/submission/%webform_menu_submission/confirm'] = array(
    'title' => 'Confirm',
    'load arguments' => array(1),
    'page callback' => 'mymodule_submission_page',
    'page arguments' => array(1, 3),
    'access callback' => 'webform_submission_access',
    'access arguments' => array(1, 3, 'edit'),
    'weight' => 1,
    'type' => MENU_LOCAL_TASK,
  );

and function mymodule_submission_page($node, $submission) do the stuff I want and if everything is ok, changes the status field:

 db_update('webform_submissions')
    ->fields(array(
      'status' => 1,
    ))
    ->condition('sid', $submission->sid)
    ->execute();

shows confimation message and redirects back to submission page.

quicksketch’s picture

I've changed my position on this issue. After thinking about the way that other systems work (such as Gmail or any other e-mail system), they commonly provide two main toggles: "mark as read" and "flagged" (or "starred"). I think building this into the main Webform functionality would be similarly helpful. Rather than our current listing of submissions, turning it into a bulk-operation table could be enormously helpful. Then you could do things like "delete", "mark as read", or "flagged" to multiple submissions at the same time.

While the ability to use Views Bulk Operations to do this same thing should be supported, native support for "mark as read" sounds like a common enough thing that it would benefit the majority of users.

vernond’s picture

@quicksketch: A bundle of questions:

1) Are you thinking of adding this to submission view, table view, or both?
2) If both, will we be adding edit, view, delete actions into table view also?
3) Would the new actions (mark as read, starred et al) also be available in submission edit and view modes?
4) Do you envisage a new permission, or will 'access webform results' cover it adequately?

Regarding questions 1, 2 and 3: Or have I missed your point and the intention is to redesign the whole results interface?

quicksketch’s picture

1) Are you thinking of adding this to submission view, table view, or both?

Probably just the listing of submissions. Viewing a submission would mark it "read". The table view would probably result in all submissions being marked read at the same time, which might not be desirable.

3) Would the new actions (mark as read, starred et al) also be available in submission edit and view modes?

Yes I would think so.

4) Do you envisage a new permission, or will 'access webform results' cover it adequately?

Access webform results will be the same I think. Though I am wondering if we should have a toggle in the Webform settings somewhere (perhaps the e-mail configuration) for whether the submissions should be "marked as read" when an e-mail is sent.

I'm definitely not planning on an entire rewrite of the interface, just adding some abilities to the existing submission listings.

arosboro’s picture

Version: 7.x-3.x-dev » 7.x-4.x-dev
FileSize
25.51 KB

I've implemented this feature request for a project I'm working on. I'd like the community to review it and accept this into a future webform 4.x release.

webform-actions.png

I'll post the patch when we've reviewed the functionality internally.

arosboro’s picture

Here is the patch. It changes the database schema, so don't install it on a production site. Only try this patch on a sandbox, or development server.

I only integrated views, I did not change the webform-ui. The new fields appear under webform submissions.

arosboro’s picture

Fixed whitespace issues.

webnicola’s picture

Issue summary: View changes

Thanks @arosboro!!

I tried to add this cool feature to 7.x-4.0-rc1 and ...

I changed the function 'webform_update_7409()' in 'webform_update_7418()' => 'Add columns to webform_submissions for "mark as read", "flag for follow up".'

Apparently everything seems to be going through. I created the view with the flag and mark as read.

But the links do not seem to work. The only thing that happens is the change of style font-weight normal to bold.
No flag, no mark as red, no data saved in the database.

Any suggestions? thanks

EKK’s picture

This is a great feature, Arosboro!

Did You get this module work in 7.x-4.0-rc1?

DanChadwick’s picture

Status: Active » Closed (won't fix)

webnicola -- I have hidden the patch because applying it to a production site will result in subsequent database damage. It will cause the "real" update function to not run.

ANY SITE TO WHICH THE PATCH #11 or #12 IS APPLIED WILL BE DAMAGED.

I don't think a Mark as Read feature should be part of webform, but it certainly could be an add-on module, especially after we use views for the submission /result lists. Also, you can use a view as provided in the patch. I would like to see this moved into a module, such hook_schema_modify or another table.