commons-app
Attach correct tags when sending thank
Currently thanks are sent with no tag, see the first line below (thanks viewing tool):
By comparison, the last line is sent via the Wikipedia mobile app, I think.
We should send tags like we do for uploads:
https://commons.wikimedia.org/w/index.php?title=File:Transcosmos_building.jpeg&action=history
It is important so that we can evaluate the app's impact. It will show how much the app contributes to a more "thankful" Commons.
(off-topic: are there other modifications made by the app which are also not tagged?)
OK, it is yours! Please let us know about your progress every few days at least :-)
@nicolas-raoul According to our doc isn't it kind of contradictory to assign the good-first-issue and enhancement labels for the same issue? 🤔
@sivaraam Indeed, actually I was hesitating between bug and enhancement for this one :-) I will avoid tagging enhancements as good-first-issue in the future.
Indeed, actually I was hesitating between bug and enhancement for this one
Ah! I would have gone with bug as we generally want the actions made from the app to be tagged appropriately 🙂
I worked on building it today. I will work on the feature very soon as soon my midterm ends this Friday.
No reply from HasanatJahan so I guess it is OK to take over. @sonukushwaha403 Sorry for not telling you sooner... if you are still interested in this, please say so within 24 hours and we will assign it to you. In case of negative reply or no reply from sonukushwaha403 within 24 hours, feel free to ask again and we will assign it to you, @rebeccachild74.
@nicolas-raoul After looking into this issue and testing thanking from the app, I think that the source field is already implemented to post with a new thank from the app, but the Thanks Log is not configured to show the source. I'll continue working on adding tags though, since other thanks entries display them, as seen below. Let me know what you think when you get a chance.
Thank you for the investigation!
When tapping to send a thank, would you mind finding (and posting here) what web requests are sent? A) by this app B) by the Wikipedia app or mobile Wikipedia website Thanks!
@nicolas-raoul
A) The request POST https://commons.wikimedia.org/w/api.php?format=json&formatversion=2&errorformat=plaintext&action=thank is logged in the logcat output, but this is not making sense because no properties are passed. The thank can be seen in the log though so it was successful. I'm going to look into the logging of that more and see why it's not accurate.
B) POST https://commons.wikimedia.org/w/api.php?format=json&formatversion=2&errorformat=plaintext&action=thank&format=json&source=log&rev=491664731&token=<TOKEN>%2B%5C is executed when you click thank in the website. I'm looking more into the mobile website since that results in tags like the ones we want.
Thanks for helping with this!
Maybe properties are passed in the POST body? In that case you would have to either:
- Run the app in debug mode, for instance with Android Studio, and put a breakpoint where the web request is sent.
- Use a network analyzer such as HttpCanary, it lets you see all details of the requests.
I am still struggling to figure out the next steps for implementing this. I think the mobile site which includes tags in the thanks log hits a different endpoint than the android app and website. It looks like its making a post request when you hit the thank button and gets the "You thanked ___" html in response.
The form data is wpEditToken=4d67843890df0cf4079ed34faa0710275f8d0ba9%2B%5C&title=Special%3AThanks%2F494208581&redirectparams=&id=494208581&type=rev. I can debug the code to see the request arguments, which end up being what is passed in the ThanksClient.thank method. Is there a different endpoint for adding tags or can I add them to an existing argument for the thanks extension?
Any idea what 494208581 refers to? Maybe user Fae?
Could you please paste the whole request here? I believe you can right-click and copy as cURL. I hope tags can be found in that.
curl "https://commons.m.wikimedia.org/wiki/Special:Thanks/494253494" -H "User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 11_0 like Mac OS X) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Mobile/15A372 Safari/604.1" -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8" -H "Accept-Language: en-US,en;q=0.5" --compressed -H "Referer: https://commons.m.wikimedia.org/wiki/Special:Thanks/494253494" -H "Content-Type: application/x-www-form-urlencoded" -H "Origin: https://commons.m.wikimedia.org" -H "Connection: keep-alive" -H "Cookie: GeoIP=US:WA:Snohomish:47.90:-122.07:v4; WMF-Last-Access=19-Oct-2020; commonswikimwuser-sessionId=508a59fb94b3e3b9481e; ss0-commonswikiSession=squcuddbd6cl5a8ckqrg8bct2nlsjr68; commonswikiSession=squcuddbd6cl5a8ckqrg8bct2nlsjr68; commonswikiss0-UserID=9762397; commonswikiUserID=9762397; commonswikiss0-UserName=Rebeccachild; commonswikiUserName=Rebeccachild; centralauth_ss0-User=Rebeccachild; centralauth_User=Rebeccachild; centralauth_ss0-Token=5daf7cf8d58d3277f8a66c44cc986479; centralauth_Token=5daf7cf8d58d3277f8a66c44cc986479; ss0-centralauth_Session=7c3f9f47e49734be8319ee53cef49908; centralauth_Session=7c3f9f47e49734be8319ee53cef49908; loginnotify_prevlogins=2020-zn5an8-2lcbxu6gkfs7auf5k4xfrc3aslxyztd" -H "Upgrade-Insecure-Requests: 1" -H "TE: Trailers" --data-raw "wpEditToken=d5e201ce54809703c3d49340f218c9675f8d1941"%"2B"%"5C&title=Special"%"3AThanks"%"2F494253494&redirectparams=&id=494253494&type=rev"
The plain request is https://commons.m.wikimedia.org/wiki/Special:Thanks/494253494
This is another thank call from mobile for the same user, Fae, but the id is different: 494253494
Strange, none of the parameters/headers seems to be about tags... maybe the matching is done server-side 🤔 Have a look around https://phabricator.wikimedia.org/diffusion/ETHA/browse/master/includes/ApiThank.php$99 (including other scripts in the same folder) and see whether anything is about tags. If not, would you mind asking at https://www.mediawiki.org/wiki/Extension_talk:Thanks ?
@rebeccarothschild I unassign for now, but if you are you still working on this, please let us know. If no answer, someone else may be assigned to it. Thanks a lot. :-)
Hi, I'm looking to solve this issue. Could you please assign me? Thanks.
@noahvendrig I just assigned the other issue to you. When done, feel free to ask again for this one. Thanks a lot! 🙂
@Dawit110 That's fair. Please let us know about your progress every week or so. 🙂
Hi @nicolas-raoul , Just a quick update on my progress. I faced some problems when trying to build/run the project on Android Studio, more specifically I kept running into a java.lang.IllegalAccessError with the message "jdk.compiler does not export com.sun.tools.javac.main to unnamed module". Updating the Kotlin version to 1.9.22 and the kotlinCompilerExtensionVersion to 1.5.8 fixed this issue. However, I also faced some problems regarding DepictsDao.kts, UploadedStatusDao.kts and NotUploadedStatusDao.kts files, mainly the error "Not sure how to convert a Cursor to this method's return type". Removing the "suspend" modifier from the related functions fixes this and allows the project to build and run on Android Studio. Apart from these changes, I have yet to make significant progress on the actual issue.
Hi @nicolas-raoul, I found that the thanks log entries are formatted on the server side, more specifically the log entries for the thanks extension are handled through the thanksLogFormater PHP file, (https://phabricator.wikimedia.org/diffusion/ETHA/browse/master/includes/ThanksLogFormatter.php), and it seems that the thanksClient and thanksIntereface purely act as API calls to the server side which then handles all the log entry activities including the inclusion of tags. I'm currently unsure how to proceed with the issue without testing/modifying thanksLogFormater or testing other server-side code.
You mean there is no way to tag thanks (for instance tagging a thank as being sent from the Commons Mobile App), right?
If so, I guess we can close this issue until upstream implements such a feature.
Thanks @Dawit110 for researching the matter and reporting your findings here!