Discourse Yearly Review

plugin
,
161

I’m not able to reproduce this. I assume by “trigger creation in sidekiq” you are clicking this button?

image
image2328×570 157 KB

The logic to check if the topic already exists is just based on a custom field per FIX: Check for existing review topic by custom field (#65) · discourse/discourse-yearly-review@98012d8 · GitHub fix, so changing the category shouldn’t make a difference (though of course deleting the topic will):

def review_topic_exists?(review_year)
  TopicCustomField
    .find_by(name: ::YearlyReview::POST_CUSTOM_FIELD, value: review_year.to_s)
    &.topic
    .present?
end

Unless there is something clearing these custom fields or some other issue I am not aware of?

1 Like
162

And yet is happening. Mine is creating new one, and

  • the plugin used category forum at the Jan 1st
  • I changed setting to category community
  • I moved created review from forum to community editing topic itself, not using timer and republishing
  • the plugin created new one next day (I’ve allowed duplicate headers)

Or

  • the plugin is configured to use category staff
  • I moved created topic from staff to community editing topic itself
  • next day the plugin created new one to staff

The last one may been an issue because of

  • I moved created review without staff members and moved the review to community
  • I included staff and triggered creation and it did new review and this time staff included as asked
  • I edited name of that topic and moved to community
  • I changed setting back to staff excluded
  • and the plugin created new review next day

It should create a review, if

  • date is after Jan 1., AND
  • there is not a topic of right name

Well, AFAIK it should follow that logic. I can be very wrong too. But without any knowledge of coding what so ever I would make a bold claim: it doesn’t recoqnize name of topic now because category is different what settings say it should be.

2 Likes
163

Correct.

I am able to replicate this again today using the exact same steps, on my personal site. I now have three of these topics in three different categories.

Happy to invite you to show you.

2 Likes
164

We recently changed this to check for the presence of a custom field on the yearly review topic for that year, the topic title should have no bearing:

Just confirming, but do you and @tobiaseigen have the latest version with this commit FIX: Check for existing review topic by custom field (#65) · discourse/discourse-yearly-review@98012d8 · GitHub installed?

I am not saying it is not happening – there is clearly some difference in configuration or some other difference between my local setup and yours/Tobias’ sites, so just trying to narrow things down here so we can push a fix.

@tobiaseigen yes please!

2 Likes
165

I don’t know, you tell me :smirk:

3.2.0.beta4-dev (9ac3961f23)

Anyway, I’m not big believer on once a year upgrading, so I’ll do rebuilding today too.

2 Likes
166

I thought I updated this topic last week but I didn’t :facepalm: I found the issue, and the fix is here:

TL;DR: That previous commit I made introduced a bug, where if the first year topic for the year is deleted, subsequent sidekiq runs will keep making more and more topics. Once you have that commit the issue should stop.

5 Likes