Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix poll fraction calculation for Pleroma #284

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Xen4n
Copy link

@Xen4n Xen4n commented Oct 20, 2023

I don't know why, but Pleroma returns poll.votersCount equals 1 for polls. So let's just use poll.votesCount as total value for fraction calculation.

@LucasGGamerM
Copy link
Owner

This is not a good workaround

@Xen4n
Copy link
Author

Xen4n commented Oct 22, 2023

Why? votersCount - users, votesCount - all votes. Fraction result for pollOption = votes / allVotes, not voteRs

@LucasGGamerM
Copy link
Owner

That is only true in the Single option polls. In a multi option poll, the number of votes is higher than the number of voteRs. Its a weird edge case, but it has to be considered as well

@Xen4n
Copy link
Author

Xen4n commented Oct 23, 2023

For example only 1 user takes part in the survey with Multi option polls. He checks 2 options.
With my fix it is 50% on each checked option. With your realisation it is 100% on each. What is better?

@LucasGGamerM
Copy link
Owner

I forgot to respond. But I feel like what the web interface does is best. I just forgot to check what it does

@Xen4n
Copy link
Author

Xen4n commented Nov 6, 2023

But with this we have failure poll values in Pleroma. Of course if you not planed to implement separated Pleroma realisation :)

@FineFindus
Copy link

FineFindus commented Nov 6, 2023

You can change the calculation, depending on if the server uses plemora. Not if that works break multiple choice plemora polls though.

@TheOneric
Copy link

fyi, current versions of Akkoma no longer expose votersCount for single-choice polls. But regardless the correct way to to check whether a poll is a multiple-choice or not, is to just check the multiple field directly instead of relying on Mastodon zeroing out votersCount for single-choice polls. It looks like multiple is already part of the model, so the following should in theory just work™:

diff --git a/mastodon/src/main/java/org/joinmastodon/android/ui/displayitems/PollOptionStatusDisplayItem.java b/mastodon/src/main/java/org/joinmastodon/android/ui/displayitems/PollOptionStatusDisplayItem.java
index 1966c0fed..c4593265a 100644
--- a/mastodon/src/main/java/org/joinmastodon/android/ui/displayitems/PollOptionStatusDisplayItem.java
+++ b/mastodon/src/main/java/org/joinmastodon/android/ui/displayitems/PollOptionStatusDisplayItem.java
@@ -54,7 +54,7 @@ public class PollOptionStatusDisplayItem extends StatusDisplayItem{
 	}
 
 	private void calculateResults() {
-		int total=poll.votersCount>0 ? poll.votersCount : poll.votesCount;
+		int total=poll.multiple ? poll.votersCount : poll.votesCount;
 		if(showResults && option.votesCount!=null && total>0){
 			votesFraction=(float)option.votesCount/(float)total;
 			int mostVotedCount=0;

There’s however an unrelated bug in *oma backends which may lead to votersCount desyncing from the actual number for remote polls; in particular it may lead to a zero value so until this is fixed a safer check working raround div-by-zero errors is (polls.multiple && polls.votersCount>0) ? ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants