Is there any setting for setting which timerange is selected by default on the Latest Topic page when a user accepts an email invitation?
It currently shows “All time”, but I’d like to set it to “Last month”.
Do you mean the ‘Top’ page? There is top page default timeframe but it appies to everyone, not just invited.
In our setup, the top page default timeframe setting is set to monthly, but for a newly-invited user it is shown for all time.
Do you know which email they receive? I wonder if it is redirecting them to /top/all directly?
The link is like this:
I can reproduce it stably by inviting my other email to register and clicking the link from there.
Yeah, I meant internally once they arrive and verify the invite process. That may be enough to let me dig into this later and see what it is doing.
3 Likes
I’ve just clicked your link and after changing to “Top” I see only topics from past month.
This is a fake (example) link which with an invalid invitation secret key. It will lead to the home page, which makes this link not suitable for further testing.
With a good link, you won’t have to click on “Top” - it will show you “Top” by default.
Can you help me with repro steps?
Here is what I did, as a user go to my Profile page > Invites > Send an invite.
Receive invite and I’m automatically signed in… but it dropped me off at the homepage, not to Top…
Can you give me clear steps that produce the result you are experiencing?
@cpradio hm the repro steps you’re trying are correct - I’m doing exactly the same.
However, once I click on the link from the invitation email, it opens the “TOP” page:
Maybe there is a difference in our Settings that affect the scenario?
Remember users who are new or have been absent a long time get the top page .
I had sent the email to a non-existant user and it properly created an account on link click…
I’ll see if I can attempt this again later today.
Okay, so I couldn’t repo locally because it seems my sandbox and local sites do not have enough traffic to warrant redirecting to top/all. But when I did it on a live site that is active, it definitely redirects to top/all. It is that /all that is causing it to select the ALL timeframe.
Provided I can figure out where that gets set, what is the verdict here? Can we redirect to top/ and ignore the “all” so it uses the default in Site Settings?
Found it.
discovery.js.es6 has the following
https://github.com/discourse/discourse/blob/5dbd6a304bed5400be481d71061d3e3ebb4d6785/app/assets/javascripts/discourse/routes/discovery.js.es6#L13-L21
Which then utilizes the redirect_to_top.period found in user_option.rb
https://github.com/discourse/discourse/blob/5dbd6a304bed5400be481d71061d3e3ebb4d6785/app/models/user_option.rb#L86-L110
And that method pulls its value for the time period from min_redirected_to_top_period
https://github.com/discourse/discourse/blob/5dbd6a304bed5400be481d71061d3e3ebb4d6785/app/models/site_setting.rb#L100-L107
The site_setting.rb doesn’t take into account the default time period. It simply returns the first time period that has enough topics to meet topics per period in top page site setting
3 Likes
Thanks for the research.
So is there a way to let the user be redirected as per configuration of the default top period?
Not without changes.
I’m actually wondering why we wouldn’t reuse the logic for handling the default top page period.
https://github.com/discourse/discourse/blob/600b23c0a40a4453532d20c1a53ce426ae8e3e68/app/controllers/list_controller.rb#L330-L350
Calling that to get the period to show, seems logical to me. It would ensure the user sees the top most recent topics giving them a better insight to the activity of the community. But that is purely my own opinion.
2 Likes
Nice detective work @cpradio 
Feel free to submit a PR. Might have been done by someone who didn’t know that logic existed elsewhere.
1 Like
Okay, I think this will solve it
https://github.com/discourse/discourse/pull/4485
I wrote additional tests (and verified the existing ones still pass) to verify it returns the Top redirect when it should since I’m still struggling to recreate the workflow consistently using the UI.
1 Like
Okay, so that first PR was a major oops. This second one is much better and isn’t causing a bunch of tests to fail.
https://github.com/discourse/discourse/pull/4487
3 Likes