I reply myself. When you open 20 diferent topics, the prompt appears at the end of the last post in the topic
Is there an issue with the webhook implementation? We configured everything correctly. The normal sync works. And the Patreon tests of the webhook return status 200, though new pledges are not added/synced via the webhook, just over the 6 hours Sidekiq job.
Another question, if a user used a different email address for the Patreon account and the Discourse account, is it sufficient to add the email used at Patreon manually as an “alternate/secondary email” in the Discourse account? Will those be synced, too or is the Discourse user required to change his/her primary email for the sync to work?
I just tried this, and it worked. This is a much better solution than what I’ve been doing manually. Now I can push back on these troublesome users and tell them to add their own alternate email.
Perfect, thanks for letting me know. That is a lot easier than.
I have not had a chance to look at this super in-depth yet, but is it possible to have a different badge per Patreon tier?
It is possible to add users to a custom Discourse group based on their Patreon tier. See the Linking Patreon tiers to custom Discourse groups section of the guide for details about how to do that.
Once you are adding users to the custom group based on their Patreon tier, you could add a group flair to the group. You could also create a custom badge that is granted to members of the group.
This is the part I was interested in. I suppose with the proper setup, I could make it so that the user gets the badge for every month they are in the group which is dependant on whether you are still a patreon or not. Though making several different groups feels like a workaround. I’ll keep thinking on it.
If you are interested in our usecase:
We have 3 tiers, each one gets you a bronze or silver or gold shark (we model our badges after different colored sharks!). The gold tier also gets you the bronze and silver one for example. We’ve been manually doing these for years on our previous/current software, so automating all of the patreon badge granting once we are fully on Discourse will be awesome.
If I understand correctly, the plugin will already do everything you want. You might be missing the fact that the plugin truly “syncs” the groups every 6 hours. If they stop being a patreon, it will remove them from the groups. If they upgrade to gold-shark contribution level, it will move them to the gold-shark group.
Then award the badges with a badge query, or the group flair as @simon mentioned.
Making three groups doesn’t feel like a workaround to me.
Fair enough, I mean it does work really well. How about making it so that you get the badge every month you are in the group?
So after a year you have 12 gold sharks? I don’t know how to do that, and you’re going to run out of room.
That didn’t seem to be the case, in our testing just from the out of the box badges that come with discourse, if you get the same one multiple times, you get a little number in the corner marking how many times you have acquired said badge. I’ll have more time to poke at it over the weekend, but I appreciate all the feedback so far, it has given me things to think about.
Thanks for the plugin. Is it possible to combine manual assignment of users into a discourse usergroup with automatic assignment done by this plugin? Or will the plugin remove any member without a tier?
Yes, it will remove them.
On a site I manage I created a mirror group for these users, same settings and privileges as the automatic group, same flair, but manually managed.
Not sure if this is different from what I’ve done. I have the automated Patreon group, and a manually-managed Patreon-with-a-trailing-space group for members who contribute financially but not through Patreon. The problem with this is if you go to /groups there are two groups. Is “mirror group” different?
I have an issue with web hooks sent by Patreon: When a member delete his/her pledge, this event is immediately sent to the Discourse instance (using a hook) and as the consequence, my user looses immediately access to areas reserved to contributors (I do this using synchronized groups). As I understand, the current implementation of the Discourse-Patron plugin does not take into account this situation. Any idea of how to solve this problem?
This seems like the intended behavior- if they stop paying, they lose access to premium content. Are you saying you want them to stay in the group forever, even if they stop paying?
No, I was not clear enough. When someone pays, it is for the full month (in general, there is an exception). If you pay on the 1st of December, you get rewards for the whole month of December, even if you delete the pledge on December 2nd.
My first thought on reading this is that it’s the intended behaviour, but as you note:
I agree. If a user pays for a month’s membership on Patreon, they should not be removed from the membership tier’s associated Discourse group until the end of the monthly period, even if they have deleted their pledge after making the month’s payment. I’ll test this on my own site. If I am able to duplicate the issue, we will look into what can be done to resolve it.
Sorry for the delay in getting back to you about this. I can confirm that when a user cancels a membership on Patreon, they will be removed from the Discourse groups that are associated with the membership the next time Patreon data is synced to Discourse.
This seems less than ideal, but it is consistent with how Patreon handle cancelled membership. Here’s what I see when I cancel a membership on Patreon:
Given that, I’m not sure it would surprise a user that they are also loosing access to the associated Discourse group. I’m not sure how this could be handled differently on the Discourse end.
@falco, do you know if Patreon supply any details when groups are synced that could be used to determine if a user has cancelled their membership before the end of a billing period? My assumption is that they don’t supply that information.
Well, the way Patreon is working is somewhat complicated: if you activate “Charge upfront” (it is my case), the access stops at the end of the month:
If “Charge upfront” is not activated, the access stops immediately (as in your example).
There is also Annual membership, which ends after the 1 year period, not when the user cancel the membership.