Closed (fixed)
Project:
Webform
Version:
5.x-2.x-dev
Component:
User interface
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
8 Feb 2008 at 05:28 UTC
Updated:
15 Apr 2008 at 05:43 UTC
Jump to comment: Most recent file
1.8 adds a permission option "edit own webform submissions," however I can't see any way to do this. After submitting the form as a logged in user, I return to the form and it's brand new without any of my data filled in. Is there some other way to get users back to their entry?
BTW, the link in the e-mail that goes to the site manager "The results of this submission may be viewed at:
http://...?sid=13" results in this error: Fatal error: [] operator not supported for strings in /home/olivebra/public_html/modules/webform/components/select.inc on line 180
And the e-mail (CC) to the user doesn't seem to work at all.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | webform_edit_own.patch | 6.99 KB | quicksketch |
| #5 | webform_edit_own6.patch | 8 KB | quicksketch |
| #4 | p_219181_editown.patch | 7.13 KB | morbus iff |
| #3 | webform_edit_own.patch | 6.44 KB | quicksketch |
| #2 | p_219181_editown.patch | 5.26 KB | morbus iff |
Comments
Comment #1
rubyjiPlease ignore the part of my message about the e-mails not being sent, it's related to another problem.
It seems the link in the e-mail only works for the user (not the site administrator), which is frustrating. However even when e-mail link works, the form is still not filled in. ie: it is not saving/displaying the user's responses to be edited.
Comment #2
morbus iffPer another issue, one way of doing this is by giving the user's role "access webform results", but this gives the user access to see EVERYONE'S result, which is obviously not the right answer. The attached patch adds an edit link to all the user's submitted webforms to the TOP of the webform itself. I chose top (besides the ease-of-use in using a dsm()), so that, in the case where a user could take the webform again, he is immediately given the option to edit his other ones (as opposed to putting them at the bottom of a long form, where the user could waste time filling in things, only to find out he could have edited an existing one.) I also fixed an "oddity" (I don't think I'd call it a bug, since it was quite deliberate) where the "previous submission" and "next submission" navigation elements would show up on the 'edit submission' pages, even if there were no previous or next submissions. Finally, the 'Delete' tab/form redirects based on the 'access webform results' permission, to prevent an access denied if a normal user (who can only edit their own results, not see anyone else's) deletes their submission.
Comment #3
quicksketchMaking it easier for users to access their previous submissions has been a goal since submissions first became editable (they were view-only up until about 3 months ago). The idea here is good but I think the UI still needed a little help.
Instead of listing all the previous submissions for a user as individual messages, this patch shows only one message directing the user to the node/x/results page. The "Results" tab is not shown for a user that is only allowed to view their own submissions. Then on the results page, they're shown a trimmed-down version of the full administrator UI, where IP Address and user name are hidden as well as all the sub-tabs (Analysis, Download, etc).
Comment #4
morbus iffTook your patch and modified it slightly. If the user deletes his (only) result, he'll land back at the Results table stranded with no way back to the form, and an empty table with nothing to click on. If there are no results, we spit a message saying as much, and give a link back to the 'view' of the webform. Also fixed bug where you forgot to db_result().
Comment #5
quicksketchTwo more small changes:
- Period moved outside of link:
<a href="...">View your submissions</a>.- SQL query wasn't filtering to include submissions only for this node (oops).
Also, a port to 6.
Comment #6
morbus iffLooks good to me (only reviewed the D5 version).
Comment #7
quicksketchCommitted. Thanks Morbus!
Comment #8
scdwhite commentedHi. I tested the webform_edit_own6.patch with a D6 version that I am running on a hosted site. I have two users and site administrator configured. Each user had access to their own submissions. The only thing that I came across was that as a "user" if I tried to "cancel" a delete I was redirected to an Access Denied Page. This did not occur for the site administrator. Thanks.
Comment #9
quicksketchThanks, I corrected the problem in Drupal 5 and 6 versions. Here's the 6 patch:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/webform/web...
Comment #10
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.