Apps-android-commons: "Images Used" and "Thanks Received" erroneously at zero

Created on 14 Aug 2020  路  32Comments  路  Source: commons-app/apps-android-commons

Steps to reproduce:

  1. Log into an account with several images used and several thanks.
  2. Go to Achievements.
  3. "Images Used" and "Thanks Received" show 0

Commons app version:

2.12.3

Query

https://tools.wmflabs.org/urbanecmbot/commonsmisc/feedback.py?user=Syced gives:

Content-type: application/json
()
{"status": "ok", "uniqueUsedImages": 478, "articlesUsingImages": 3022, "database": "commonswiki", "deletedUploads": 27, "featuredImages": {"Quality_images": 0, "Featured_pictures_on_Wikimedia_Commons": 0}, "labs": false, "thanksReceived": 23, "user": "Syced", "imagesEditedBySomeoneElse": 991}
achievements bug

Most helpful comment

First of all, I'd like to apologize for the delay here. Since almost none of my development activities happen on Github, I rarely go through my Github notifications, which is why I missed this issue for so long. If you do need me urgently at any time (and having the app partially broken definitely is urgent :)), the best way to reach me is IRC (I have the client opened when I'm at a computer) or an explicit ping by email.

Ah man, we really do need to follow up on that. AFAIK even if we make the changes to the repo, we still need write access to the tool at https://tools.wmflabs.org/urbanecmbot/commonsmisc/ to implement this? @urbanecm could you help us with this please?

Unfortunately, I'm unable to provide direct access to urbanecmbot tool, as it powers a lot of other things in addition to this script for Commons app (mainly, it powers a cswiki bot with sysop rights). I'm happy to set up a redirect to another tool we would maintain collectively if you wish.

[...]
Of course, we can wait in case there's hope for fixing it in the tool hosted by Martin.

Hopefully it should now work :-).

All 32 comments

Another user reports the same issue:

Content-type: application/json
()
{"status": "ok", "uniqueUsedImages": 245, "articlesUsingImages": 453, "database": "commonswiki", "deletedUploads": 5, "featuredImages": {"Quality_images": 0, "Featured_pictures_on_Wikimedia_Commons": 0}, "labs": false, "thanksReceived": 4, "user": "Salim Khandoker", "imagesEditedBySomeoneElse": 537}

Hi @nicolas-raoul , does this happen in version 2.13 (beta release) too?

@misaochan Yes it also happens with the latest 2.13-release branch.
The () line might be suspicious?

I am not sure why but the result that the app is showing wrong values is because the API is returning invalid json
Content-type: application/json () {"status": "ok", "uniqueUsedImages": 29, "articlesUsingImages": 43, "database": "commonswiki", "deletedUploads": 36, "featuredImages": {"Quality_images": 0, "Featured_pictures_on_Wikimedia_Commons": 0}, "labs": false, "thanksReceived": 0, "user": "Ashishkumar468", "imagesEditedBySomeoneElse": 8} ,

This can be handled from the app side as well, although that is hacky, what do you guys suggest @nicolas-raoul @misaochan ?

Yes, I think it should be handled by the API itself.

I don't think anything changed in the API recently for production. @madhurgupta10 are any of your changes in production?

@maskaravivek All my changes are in the leaderboard branch and the PR didn't merged to master so I don't think so

Also, the tool is different for leaderboard and achievement so I guess it should not affect the APIs.

Another vote for handling it on the API's side. Should we open an issue there?

The () line might be suspicious?

Suspicious indeed. Inferring from the usage of print in feedback.py it seems to be python3. But the result appears as if the source got executed using python2 馃

For example, there's the following lines at the end of feedback.py:

print()
print(jsonify(response))

The print() would print () only when run in python2. To add to that the file does have the following shebang:

#!/usr/bin/env python

... which means there indeed are chances for it to be executed in python2 in case python points to python2 instead of python3. Fixing the shebang like this:

#!/usr/bin/env python3

... would help, I think.

Given my primitive knowledge about the tool and toolforge, I'm not sure if this is the exact reason, though.

The () line might be suspicious?

Suspicious indeed. Inferring from the usage of print in feedback.py it seems to be python3. But the result appears as if the source got executed using python2 馃

I found the following in Help:Toolforge/Python - Wikitech, which seems to confirm that python might indeed be pointing to python2:

Several Python runtimes are available for use inside Toolforge:

python3: Python 3.5.3 (3.7.3 on kubernetes)
python: Python 2.7.13 (2.7.9 on kubernetes; deprecated)

Great find @sivaraam !

Anyone with access (Vivek?), would you mind trying to copy the script, insert #!/usr/bin/env python3 as its top line, and open https://tools.wmflabs.org/urbanecmbot/commonsmisc/feedback_yourcopy.py?user=Syced again? Thanks!

Can confirm that this issue still happens. I don't have access to the tool. @maskaravivek @madhurgupta10 ?

Anyone with access (Vivek?), would you mind trying to copy the script, insert #!/usr/bin/env python3 as its top line, and open https://tools.wmflabs.org/urbanecmbot/commonsmisc/feedback_yourcopy.py?user=Syced again? Thanks!

As per the feedback in our mailing list, this still needs to be fixed.

Just talked to @madhurgupta10 about this. It seems that although he does have access to the repo, he does not have access to the VM at https://tools.wmflabs.org/urbanecmbot/commonsmisc/ . @urbanecm would it be at all possible for you to either fix this on your end, or to give Madhur access? Thanks a lot. :)

@misaochan I added a feedback_test.py file with the suggested solution, here is the URL to test it https://commons-android-app.toolforge.org/tool-commons-android-app/feedback_test.py?user=Syced

The code is available here https://phabricator.wikimedia.org/source/tool-commons-android-app/repository/master/

I don't see any changes between the response provided by feedback.py and feedback_test.py

Thanks @madhurgupta10 ! I think the results at https://commons-android-app.toolforge.org/tool-commons-android-app/feedback_test.py?user=Syced are actually correct (pinging @nicolas-raoul to confirm).

Content-type: application/json
()
{"status": "ok", "uniqueUsedImages": 595, "articlesUsingImages": 3247, "database": "commonswiki", "deletedUploads": 36, "featuredImages": {"Quality_images": 0, "Featured_pictures_on_Wikimedia_Commons": 0}, "labs": false, "thanksReceived": 23, "user": "Syced", "imagesEditedBySomeoneElse": 1509}

The numbers look reasonable! :-)
Still not sure whether the () is here on purpose or not.

I remember using print("\n") with the header instead of an empty print() and none of my API's print () I think this might be the fix, I can push a commit if you like :)

Let's try and see whether the app likes it :-)
To debug you can modify the URL used by the app.

I pushed another commit with my solution, the new API seems to be working as expected without any garbage characters https://commons-android-app.toolforge.org/tool-commons-android-app/feedback_test.py?user=Syced I also tested on the app and it is working as expected. So we can close this issue here and open an issue on https://github.com/commons-app/commonsmisc

Sounds good, thanks a lot. :)

I can reproduce this on the latest master.
When the progress bar is active (still loading) numbers are shown in their respective fields, but as soon as the loading is finished a dialog "You haven't made any contributions" is shown, all the fields are set to zero and level reset to 1.

I would like to work on this one.

This issue is blocked by this server-side problem: https://github.com/commons-app/commonsmisc/issues/22

@4D17Y4 This requires getting access to the server side, which takes a lot of time and administrative wikimedia "paperwork", and almost no programming. If you are interested and motivated you can try, though.

Ah man, we really do need to follow up on that. AFAIK even if we make the changes to the repo, we still need write access to the tool at https://tools.wmflabs.org/urbanecmbot/commonsmisc/ to implement this? @urbanecm could you help us with this please?

Ah man, we really do need to follow up on that. AFAIK even if we make the changes to the repo, we still need write access to the tool at tools.wmflabs.org/urbanecmbot/commonsmisc to implement this? @urbanecm could you help us with this please?

I'm curious as there's been a long period of time since we've heard from @urbanecm related to this issue. Should we think about forking the tool and hosting it elsewhere ? Or should we just wait for some more time?

Ah man, we really do need to follow up on that. AFAIK even if we make the changes to the repo, we still need write access to the tool at tools.wmflabs.org/urbanecmbot/commonsmisc to implement this? @urbanecm could you help us with this please?

I'm curious as there's been a long period of time since we've heard from @urbanecm related to this issue. Should we think about forking the tool and hosting it elsewhere ? Or should we just wait for some more time?

There is already a copy available https://commons-android-app.toolforge.org/tool-commons-android-app/

There is already a copy available commons-android-app.toolforge.org/tool-commons-android-app

Interesting. So, we just have to switch to using it in the app then ? Or is there something that it lacks ?

Of course, we can wait in case there's hope for fixing it in the tool hosted by Martin.

There is already a copy available commons-android-app.toolforge.org/tool-commons-android-app

Interesting. So, we just have to switch to using it in the app then ? Or is there something that it lacks ?

We can but I think it is much better to handle it from the server-side as it doesn't require users to update to the latest version to see the change.

it doesn't require users to update

Users who do not update will just not get the fix, which is not different from the current situation :-)
I think it is better to switch to a server we can update easily, rather than suffer such delays again in the future when we need to modify something.

I agree with @nicolas-raoul and @sivaraam , I think we should move to a server that we have easy access to. This issue has been going on for a very long time unfortunately. :(

First of all, I'd like to apologize for the delay here. Since almost none of my development activities happen on Github, I rarely go through my Github notifications, which is why I missed this issue for so long. If you do need me urgently at any time (and having the app partially broken definitely is urgent :)), the best way to reach me is IRC (I have the client opened when I'm at a computer) or an explicit ping by email.

Ah man, we really do need to follow up on that. AFAIK even if we make the changes to the repo, we still need write access to the tool at https://tools.wmflabs.org/urbanecmbot/commonsmisc/ to implement this? @urbanecm could you help us with this please?

Unfortunately, I'm unable to provide direct access to urbanecmbot tool, as it powers a lot of other things in addition to this script for Commons app (mainly, it powers a cswiki bot with sysop rights). I'm happy to set up a redirect to another tool we would maintain collectively if you wish.

[...]
Of course, we can wait in case there's hope for fixing it in the tool hosted by Martin.

Hopefully it should now work :-).

Tested successfully. Closing this, thanks a lot Martin! :-)

Was this page helpful?
0 / 5 - 0 ratings