[BUG] Votes are not saved correctly to the config file

[nephros]

SailfishOS VERSION (Settings → About product → Build): 4.2

HARDWARE (Settings → About product → Manufacturer & Product name): Xperia 10

PATCHMANAGER VERSION (Settings → Patchmanager → [Top pulley] About): 3.2.1

BUG DESCRIPTION

/etc/patchmanager2.conf records user's votes on patches in the configuration file.

The config file has a [votes] section for that.

Votes are (sometimes?) not (only?) saved in that section, but in the [settings] section in addition, using a votes\ prefix.

STEPS TO REPRODUCE

1. cat /etc/patchmanager2.conf
2. Vote for a patch
3. cat /etc/patchmanager2.conf

ADDITIONAL INFORMATION

Example config file snippet:

[settings]
applied=[...]
applyOnBoot=false
bitnessMangle=true
developerMode=true
notifyOnSuccess=false
order=[...]
votes\patch-email-plain=2
votes\remove-cross-icon-from-remorse-timer-iii=2
votes\smooth-remorse-counters=2

[votes]
patch-email-plain=2
remove-cross-icon-from-remorse-timer-iii=2
smooth-remorse-counters=2

I would like to have that confirmed by someone, as it's possible my config file has been messed up by a interim development snapshot version.

[nephros]

References:

https://github.com/sailfishos-patches/patchmanager/tree/master/src/bin/patchmanager-daemon/patchmanagerobject.cpp#L2161
https://github.com/sailfishos-patches/patchmanager/tree/master/src/bin/patchmanager-daemon/patchmanagerobject.cpp#L2161
https://github.com/sailfishos-patches/patchmanager/tree/master/src/qml/patchmanager.cpp#L475
https://github.com/sailfishos-patches/patchmanager/tree/master/src/qml/patchmanager.cpp#L488

[Olf0]

Test 1

1. Voted positively for calculator-result-copying, a single vote was already there (displayed at Web Catalog).
   Result:

   • Line added to [settings] section: votes/calculator-result-copying=2
   • Line added to [votes] section: calculator-result-copying=2
   • Now I have 7 lines in the [votes] section and 7 entries in the [settings] section starting with votes/ (both up from 6).
   • Side note: Sub-page of calculator-result-copying in the Web Catalog does not automatically refresh, but leaving and entering it shows 2 up-votes.

   All fine so far, AFAICS.

2. Removed up-vote and cast a down-vote for calculator-result-copying.
   Result:

   • Line changed in [settings] section: votes/calculator-result-copying=1
   • Line changed in [votes] section: calculator-result-copying=1
   • Side note: Sub-page of calculator-result-copying in the Web Catalog does not automatically refresh, but leaving and entering it still shows 2 up-votes!

   IMO vote count should be 0 and it is obviously not properly propagated / synchronised to the Web Catalog.

3. Removed the down-vote for calculator-result-copying.
   Result:

   • Line changed in [settings] section: votes/calculator-result-copying=0!
   • Line changed in [votes] section: calculator-result-copying=0!
   • Side note: Sub-page of calculator-result-copying in the Web Catalog does not automatically refresh, but leaving and entering it still shows 2 up-votes.

   IMO vote count should be 1 and it is obviously not properly propagated / synchronised to the Web Catalog.

4. Cast an up-vote for calculator-result-copying again.
   Result:

   • Line changed in [settings] section: votes/calculator-result-copying=2!!
   • Line changed in [votes] section: calculator-result-copying=2!!
   • Side note: Sub-page of calculator-result-copying in the Web Catalog does not automatically refresh, but leaving and entering it now shows 3 up-votes.

   IMO vote count should be 2 (as in step 1) and obviously something goes wrong with the propagation / synchronisation with the Web Catalog.

Preliminary conclusion:
The two corresponding lines and the whole sections always seem to be in sync, but something is wrong with the vote counting logic and the interaction with / transmission to the Web Catalog.
Actually your example does not show anything different, AFAICS.

Hence I suggest to disregard the double entries for now and analyse what is wrong with the counting logic and the interaction with / transmission ("sync'ing") to the Web Catalog.
Maybe the double entries act as a kind of backup and are updated at different stages in the voting process / code?

[nephros]

Looking through the code it turns out that the values are correct.

The do not represent vote count, but rather voting state.

• 0 - not voted
• 1 - dislike
• 2 - like

[Olf0]

… which makes sense: Only save the own voting locally.

So accidentally my suggestion was spot on:

Hence I suggest to disregard the double entries for now and analyse what is wrong with the counting logic and the interaction with / transmission ("sync'ing") to the Web Catalog.

But it obviously is the Web Catalog's counting logic or the transmission of down-votes and revoking a vote on either side, which is flawed (i.e., only up-votes are transmitted and / or transmitted successfully).