Flow/Thanks

Flow Thanks is an upcoming feature to allow users to thank others for their comments on Flow discussion boards. It is currently under development by Facebook Open Academy students. This page serves both to identify issues and document ideas and progress. Trello card

As of 6 March

 * Done:
 * Back button handling (in the form of showing an alert on repeated thanks)
 * i18n description strings
 * In progress:
 * Unit tests and browser tests (Thanks, Flow)
 * To do:
 * Implement no-JavaScript fallback

As of 1 March

 * Done:
 * Submitted patches for code review
 * PHPUnit integration tests for Flow
 * In progress
 * PHPUnit tests for Thanks
 * Browser tests
 * To do
 * Handle back button after thanking (currently the state is not preserved)
 * i18n description strings
 * Implement no-JavaScript fallback

As of 25 February

 * Done:
 * Initial version done, not yet submitted to Gerrit
 * In progress / to do:
 * Submit initial version for code review
 * Create browser tests
 * Implement no-JavaScript fallback

Issues

 * Figure out if we can re-use Extension:Thanks
 * Thanks stores states in session and cookies for last 100 thanks made
 * Thanks link for edits appears on a history page, but according to trello, Flow has it besides the post itself.
 * Thanks depends on revId, Flow stores its own id.
 * on local wikis changed: earlier posts return a string, newer return an integer. As a result code confused about which posts were written by someone else and are thankable.
 * Security:
 * Sanitizing all inputs
 * Right now AbstractRevision::getContent is used to obtain topic title; method docs say we should use Templating::getContent which does permission checks--is this necessary? Fixed
 * The API should check whether a post ID is valid I think this is done in getFlowData
 * Supporting users with JavaScript disabled
 * Right now the link links to a non-existent special page
 * Testing! JavaScript unit tests and browser tests
 * Remembering Thanked state (Thanks does it in PHP session and cookie)
 * Ensure the cookie and session functionality to remember Thanked state does the right thing
 * Validate assumptions (thanking original poster vs. editor, etc.)
 * Other refinements
 * Make sure emailed notifications work properly
 * Can't test this in mediawiki-vagrant
 * Tested on ee-flow. Seems to work.

Things spage noticed

 * I wound up with two  cookies, one for the path /wiki/index.php and one for /wXXXXpath  That might be a Thanks issue.
 * After I did a Flow thanks, I had a thanks-thanked cookie with no value.
 * In the Thanks.flow  hook,   isn't a Revision object, it's a FlowRevision.

What Thanks does

 * Register a new type of notifications with Echo
 * Eventually calls ApiThank::sendThanks, which creates an Echo event
 * Handles Echo's hooks to format and display notifications

Normal page Thanks implementation
Thanks responds to HistoryRevisionTools and PageHistoryBeforeList hooks,
 * responds in  by adding HTML

no-JavaScript: link to https://www.mediawiki.org/wiki/Special:Thanks/677745

JS: jQuery dialog, upon confirm make API call https://www.mediawiki.org/w/api.php?action=thank&format=json&rev=677745&source=diff&token=1aabf45aa2917fd61527b2941ad19304%2B%5C, response is success: 1, recipient: "username"

Recipient sees
 * Thanker thanked you for your edit on Page

Thanker links to person, the text links to https://www.mediawiki.org/w/index.php?title=Page&oldid=prev&diff=677745

Normal Echo notification of a Flow post
A Flow mention generates:
 * User mentioned you in their post Text of post on "Talk:Main Page".


 * User links to person
 * Entire notification links to https://www.mediawiki.org/w/index.php?title=Talk:Flow&workflow=050f35daa31600e9aae290b11c2788d8#flow-post-050f575cfa098b080b88782bcb087047
 * post links to the same thing

Submitting patch
$ git checkout master $ git fetch origin $ git merge origin/master
 * 1) basically git pull origin master to keep master up to date

$ git checkout flow-thanks $ git checkout -b my-patch # keep the reference to flow-thanks, in case we screw up later. Give it a better name, see gerrit branch naming convention. $ git rebase -i master # squash all commits into a single one, see also http://git-scm.com/book/en/Git-Tools-Rewriting-History the squashing commit part
 * 1) rebasing

$ git commit --amend # make sure the commit message is proper $ git review -R # submit without rebasing against master
 * 1) prepare to submit patch

Modifying the patch
After we've submitted the first patch, I recommend we only use the old branch for new patch sets of that original patch. For other purposes we start new branches (be it tests, or new features).