Closed Bug 406558 Opened 17 years ago Closed 17 years ago

Implement article feedback questions

Categories

(support.mozilla.org :: Knowledge Base Software, task)

Product:
support.mozilla.org
Component:
Knowledge Base Software
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

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.
> 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.

(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.
I'm not sure I know how to fix this.
Need some code refactoring upstream to easily cater to multiple polls per page.
Assignee: bmo2008 → nelson
Blocks: 402862
Moving to 0.3. Not required for 0.2.
Target Milestone: 0.2 → 0.3
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Whiteboard: tiki_triage nelson (see comment 4)
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
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?
Only adding the ratings automatically is missing.
Whiteboard: tiki_feature → tiki_feature, tiki_discuss
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?
> 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.
> 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.
> 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.
Louis-Philippe: Can you make this generic and upstream?

M ;-)
Unlikely. There is a lot of template hacking involved to obtain the desired result.
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.
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.
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
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.