Closed
Bug 406558
Opened 17 years ago
Closed 17 years ago
Implement article feedback questions
Categories
(support.mozilla.org :: Knowledge Base Software, task)
support.mozilla.org
Knowledge Base Software
Tracking
(Not tracked)
RESOLVED
FIXED
0.3
People
(Reporter: djst, Assigned: nkoth)
References
Details
(Whiteboard: tiki_feature, tiki_upstream)
Each article should have two polls at the end of the document, and a general feedback text area:
Did this article solve a | Was this article easy
problem you had with Firefox? | to understand?
[ Yes ] [ No ] | [ Yes ] [ No ]
Have more to tell us?
-----------------------------------------------------------
| |
| |
| |
| |
-----------------------------------------------------------
Enter [35235] here: [_____] (why?) [Submit Feedback]
Ideally, the last row with the captcha and Submit button shouldn't be displayed until the user types something in the text box. For logged in users, the captcha shouldn't be displayed at all.
Comment 1•17 years ago
|
||
> Ideally, the last row with the captcha and Submit button shouldn't be displayed
> until the user types something in the text box. For logged in users, the
> captcha shouldn't be displayed at all.
The patch in bug 396810 makes it so that logged in users just get a normal forum-style "Post a reply" rather than the article feedback UI. This is going on the assumption that all logged in users are contributors, which is true for now.
Reporter | ||
Comment 2•17 years ago
|
||
(In reply to comment #1)
> The patch in bug 396810 makes it so that logged in users just get a normal
> forum-style "Post a reply" rather than the article feedback UI. This is going
> on the assumption that all logged in users are contributors, which is true for
> now.
>
That could be fine for now, if you mean logged in users see the "article contributor feedback", which is not related to this feedback at all.
Comment 3•17 years ago
|
||
I'm not sure I know how to fix this.
Assignee | ||
Comment 4•17 years ago
|
||
Need some code refactoring upstream to easily cater to multiple polls per page.
Assignee: bmo2008 → nelson
Assignee | ||
Updated•17 years ago
|
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Reporter | ||
Updated•15 years ago
|
Whiteboard: tiki_triage nelson (see comment 4)
Assignee | ||
Comment 6•15 years ago
|
||
lph, please contact sylvieg for some info - she had a go at it but she said "it needed a rewritting to be generic - I did the specific - but did not go further" and that she has some notes.
The feature is basically "allow multiple polls per page" but in sumo it's not really generic.
Whiteboard: tiki_triage nelson (see comment 4) → tiki_feature
Comment 7•15 years ago
|
||
Basically, the database structure allows for multiple polls per page. This is not an issue. Only the UI prevents it by assuming there will only ever be one "rating" per page.
The changes create new methods to obtain multiple under "questions" rather than "ratings", causing a lot of confusion.
The templates seem to expect certain questions to be present rather than display the incoming data in a generic way.
The steps to upstream are basically:
* Modify the interface to allow adding multiple polls
* Add an option to disable adding polls as this is hidden in SUMO
* Change how polls are displayed from the tiny pop-up at the top to questions at the bottom of the page.
The part I am unsure about is how the polls are automatically being added at page creation. I could find nothing related to this.
Am I missing something?
Comment 8•15 years ago
|
||
Only adding the ratings automatically is missing.
Whiteboard: tiki_feature → tiki_feature, tiki_discuss
Reporter | ||
Comment 9•15 years ago
|
||
paul/james/morgamic: any comments about LPH's proposed upstream approach?
Nelson, maybe you could help with answering how polls are automatically added at page creation?
Assignee | ||
Comment 10•15 years ago
|
||
> Am I missing something?
The way it used to work in Tiki is that the user can select poll of type 't' (template) from the drop down when editing (if he has sufficient perms), and a new poll (ie. rating) is created for that page with the name of the page as the title.
When I did this, the get_ratings() function did not exist yet. There was only the old get_rating() function. Also, I noticed the behavior in the polls system resulted in multiple ratings per page (based on the same template) being created in the DB over time. There was no "cleanup" of multiple rating entries based on the same template, and queries all over the place simply getOne the last rating as the one for the page. These "bugs" may or may not have been fixed in Tiki since then (I do not know). That was why I created the questionId approach with the aim to get more flexibility and robustness.
Moreover, with the concept of questions, it is possible to selectively display a specific question in a particular part of the screen (or in modules), for example. Otherwise, there is no way to create a module that asks question 1, if it exists as a rating for this page. Originally the idea was to put the questions in modules (layout wise), instead of showing them all below the page. This was part of the thinking behind introducing the concept of questions.
It is also conceivable that in future, questions might change, for example they might decide no longer to ask question 1, but ask a new question, question 3 instead. However, we might not actually want to remove question 1 from the db. By using the get_ratings (as it currently is), it will return all the ratings and we still need a way to selectively show question 2 and question 3. I also considered the possibility in future of the need perhaps to ask different types of users different questions on the same page.
Assignee | ||
Comment 11•15 years ago
|
||
> Am I missing something?
The way it used to work in Tiki is that the user can select poll of type 't' (template) from the drop down when editing (if he has sufficient perms), and a new poll (ie. rating) is created for that page with the name of the page as the title.
When I did this, the get_ratings() function did not exist yet. There was only the old get_rating() function. Also, I noticed the behavior in the polls system resulted in multiple ratings per page (based on the same template) being created in the DB over time. There was no "cleanup" of multiple rating entries based on the same template, and queries all over the place simply getOne the last rating as the one for the page. These "bugs" may or may not have been fixed in Tiki since then (I do not know). That was why I created the questionId approach with the aim to get more flexibility and robustness.
Moreover, with the concept of questions, it is possible to selectively display a specific question in a particular part of the screen (or in modules), for example. Otherwise, there is no way to create a module that asks question 1, if it exists as a rating for this page. Originally the idea was to put the questions in modules (layout wise), instead of showing them all below the page. This was part of the thinking behind introducing the concept of questions.
There was also a need to make sure that the polls appeared in the correct order on the template.
It is also conceivable that in future, questions might change, for example they might decide no longer to ask question 1, but ask a new question, question 3 instead. However, we might not actually want to remove the ratings for question 1 from the db. By using the get_ratings (as it currently is), it will return all the ratings and we still need a way to selectively show question 2 and question 3. I also considered the possibility in future of the need to ask different types of users different questions on the same page.
Introducing questions, though (I agree with LPH) can be confusing. Maybe there is another way to make sure the above issues I was trying to address is addressed.
Assignee | ||
Comment 12•15 years ago
|
||
> The part I am unsure about is how the polls are automatically being added at
> page creation. I could find nothing related to this.
>
The code for this is somewhat hardcoded in poll_categorize.php. It's commented in there for Mozilla.
Comment 13•15 years ago
|
||
Louis-Philippe: Can you make this generic and upstream?
M ;-)
Comment 14•15 years ago
|
||
Unlikely. There is a lot of template hacking involved to obtain the desired result.
Comment 15•15 years ago
|
||
Sounds like this might have to be a sumo_only hack for the time being? I'd love if there was a way to do our type of CSAT/feedback without relying on a broken implementation of Polls, though.
Comment 16•15 years ago
|
||
Which aspects do you refer to?
There were several changes to allow for multiple polls per page. The implementation varies because there were changes on tiki for that too.
Comment 17•15 years ago
|
||
The multiple questions are supported in t-t. We still need to upstream the "more to tell us" functionality.
Whiteboard: tiki_feature, tiki_discuss → tiki_feature, tiki_upstream
Comment 18•15 years ago
|
||
As far as I know, those are just comments in the background. Unless there were changes to the libraries burried in there, it shouldn't be much more than adding tiki-feedback.php back in.
You need to log in
before you can comment on or make changes to this bug.
Description
•