We’ve been using invitation links to help our users move between platforms and into discourse; however, the new prompt that started to appear with the latest discourse update is causing delay and confusion.
Users using an invite link which redirects to a topic post are not only able to use the link once which is a major issue if we are expecting them to use the link each time they want to visit the topic post. It is important that we are able to redirect users using the same invite link as many times as the user want to revisit the topic and having this feature blocked by the new prompt is causing an issue.
Other technical issues appeared as well. First of all, it takes at least five seconds for the ‘accept invite’ to respond to the click, and then takes some time to redirect user to topic. Second, with this new addition, it is taking more time to load the prompt first. Third, even if you’d clicked the invite link before and accepted the invitation, it will continue to ask you every time you click the link!
To reproduce this issue, create an invite link that redirects users to topic post and/or adds them to a group. Click on the redirect link while logged in to the discourse account.
Please, is there a way to disable this prompt from the settings? This is both urgent and important because for us it will affect the user’s experience.
It might also go unnoticed by others who could be relaying on invitation links but aren’t aware of this new change because there was no notification about this change, thanks!
I would like to add that there is a bug here as well and in our use case we don’t need the prompt in the first place so would it be possible to remove it? or be given the option in Admin settings to disable it?
The bug is that if you click on the ‘Accept invitation’ for the second time, the page will stay static and not show any message. This is not helpful at all. It blocks the user from using the previous context to be redirected to the topic again. This is a major issue. If I put an invite link in a document and expect that the reader might use the same link over and over again to be redirected to the topic, the invite link will no longer work.
We use invite links because the participant need to be added to a private category first to be able to read the topic. If the user needs to find the topic again, they should be able to use the same invitation link. In this case it should auto-accept invite if the user is logged in because the invite is intended for that user and as it worked fine previously, should redirect the user to the intended topic post.
Invitation links worked perfectly before. I hope you can have a second look at this and give admin the option to disable this ‘Accept Invitation’ prompt/button message. Thank you!
I cannot reproduce this 5-second delay. Tested here on meta with multiple invites both with and without adding to a group. If you see this delay every time, can you try it next time with the developer tools open in the console tab and see if there are any errors reported there?
I can reproduce this one, it looks like there is a regression here, we will fix this shortly.
I can’t see any errors in the Firefox console, but when I try in Chrome, I sometimes get these errors.
includes.js?v=35a79b300ab5afa978cb59af0b05e059:839
PUT https://XXX/invites/show/XXX.json 502
XMLHttpRequest.send @ includes.js?v=35a79b300ab5afa978cb59af0b05e059:839
send @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:495
ajax @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:471
y @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3948
(anonymous) @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4309
O @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4309
f @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3948
submit @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:2926
B._run @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4450
B._join @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4449
B.join @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4412
p @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2577
(anonymous) @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:725
a @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2481
(anonymous) @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:725
(anonymous) @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:719
_triggerAction @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:532
click @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:531
trigger @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2235
r @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2092
trigger @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:4230
r @ vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2092
a @ discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:4234
discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3940
SyntaxError: Unexpected token '<', "<html>
<h"... is not valid JSON
at Function.parse [as parseJSON] (<anonymous>)
at i (discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3940:167)
at discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:2926:699
at b (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4291:12)
at g (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4289:128)
at h (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4287:107)
at p.invoke (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4377:192)
at p.flush (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4369:141)
at h.flush (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4384:207)
at B._end (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4448:9)
at B.end (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4401:240)
at B._run (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4450:118)
at B.run (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:4410:13)
at d (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:2577:23)
at u.error (discourse-27b1f43fa762ddf5962cd2fe315ed30d7328317e3f712317bcf73fe42f3e91e3.js:3948:44)
at l (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:200:118)
at Object.fireWith [as rejectWith] (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:201:698)
at E (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:483:468)
at XMLHttpRequest.<anonymous> (vendor-52a227242ff3f3ca9d1116e8a9ef5c5c0470f27df70b8688420e4f4222a222ed.js:494:206)
Please, the prompt message is not helpful in our use case, is there a way for admin to create invitation links without this type of prompt?
Invitation links are used in a course where participants are invited to join the discussion forums. All we want the invitation link to do is to add the user to a group and redirect the user to a topic in a private category (without having to click ‘accept invitation’ each time they use a link), and after the first click users are expected to be able to return to the topic using the same invitation link. This has been working smoothly and perfectly until the message prompt has been enforced overnight.
I have explained how we’re using the invitation links in another topic
@tobiaseigen@dan@JammyDodger , please please help me on this. We must be able to get rid of the prompt message in our use case.
Hi @gassim, we have discussed this internally. Sorry, but the behaviour of accepting the same invitation multiple times as the same user to act as a bookmark is unexpected, and we will be fixing this to hide the “Accept Invitation” button if the logged in user has already accepted the invitation. Instead we will display a message informing the user that they have already claimed the invitation link.
The automatic accepting of an invitation when opening the page was a security issue, which is why we changed to have the interstitial “Accept Invitation” page instead.
If it’s necessary for the user to keep coming back to the same topic, we suggest they bookmark it. Or, if you have some internal document where you put the invitation link, add a link to the topic in the same place for convenience.
Hi @martin, thank you and the discourse team for the consideration. We are discussing alternative solutions at the moment.
Yes, please and we’d be happy to know when this bug is fixed.
Understood… I was hoping that admins are given the option during the creation of the invitation link to choose whether the prompt message is used or not (maybe with a warning of what could happen if they don’t use the prompt message.) We are aware that without the prompt message, anyone would be able to access the private group/category but in our use case that’s not an issue because they are not ‘secret’ groups/categories, they’re private to be kept separate as dedicated spaces for discussion of course topics.
It’s not easy to demand course participants to bookmark the topic, but the latter suggestion sounds like our only option now and the immediate action we could take to fix the issue.
Oh this is an interesting constraint. So you have a Discourse with 1000 rooms anyone can access but you want the course members to have strong affinity to the particular room.
some questions:
What is the value in not using security here? Is latest just a giant amount of noise for the typical user? We also have a “by default all categories are suppressed from latest” setting that may be interesting
Can sidebar alleviate the pain a bit? If you have the category in your sidebar at least it calls it out. Maybe invite should also allow adding to sidebar? I am not sure?
Would spelling stuff out better in the welcome topic help. To find your home please bookmark the following and add to sidebar, here are the steps
I think we both have to accept each other’s constraints in the short term.
Since it sounds like @gassim had a system in place that was working well for them, I think providing some guidance here that stays as close as possible to that is probably best. Continue to use groups to gate access to specific categories and limit noise from elsewhere.
We are interested in cleaning up some rough edges in our invite system to make it more maintainable and understandable, and I expect we’ll bump into issues like this along the way as we do. In this case, we’re insisting on not leaning on invite links as reusable topic links.
Having read the earlier topic, I’m thinking what may make the most sense is to do something like the following:
Replace invite links for each course with links directly to the topic
Near those links, include a generic invite link. “No account yet? Click here to create an account and join the group”
Have the invite link direct to a topic that is more generic overview and instructs the user to go back to their course and join the course-specific topic from there.
The rooms that are kept private are for the course participants. Basically we want these rooms to be a dedicated space without affecting the rest of the forum activity (latest, top…etc) Having the course discussion forums in private categories is not because they are ‘secret’ but because only those who choose to enroll in the course need to see the topics and discussion while those who don’t can continue to use the rest of the site as usual.
Thanks for the suggestion! I have not experimented on the sidebar yet but here’s a free writing about why I have not promoted the side bar yet:
The homepage already displays two columns: Categories in one column, and latest in the other; having the sidebar seems like a repetition in the homepage (there isn’t a way to keep it off in the homepage?)
The sidebar seems to give more than necessary attention to Private Messages and we don’t encourage the use PM much.
Contrary to the thought that this will ease the pain, the sidebar will seem like a distraction for course participants who join the private category because we don’t want the other categories to appear during their participation. (there isn’t an option to disable the sidebar in some categories?)
If there is an option for Admin to customize the sidebar per ‘group’ so the participants in group A get to see things relevant to group A while group B will things relevant to group B, then it would help ease the pain. The reason for this is because we don’t expect all users to treat the site like it’s their email account and spend time learning to customize it; on the other hand, we need to welcome them where they will already feel comfortable and benefit directly from the experience without needing to spend time learning to customize…etc So if we can pre-customize it for each group and then they have the choice to change it, it would be great (plus the option to not show it in the homepage - by default it should be hidden in the homepage, probably a CSS code can fix this but then what about certain categories)
I’m not sure because there will be at least 50 topics for participants who enroll in all the courses. However. we are using @martin’s suggestion:
Thanks for the suggestion @Stephen! However, the homepage is for all members and we don’t want to change that. The course participants will participate in several courses but after each course they are invited to continue participating in the community.
Understood, but then this was the admin’s option to make the invite link expire after a certain number of uses or after a certain date (in addition to limiting it to specific email addresses.) For us because we never wanted the invite link to expire the expire date was 2092 and the number of uses were 1000000 (and of course didn’t specify list of email addresses because we wanted the invite link to remain open to whomever actually wants to join the discussion topic in the private category)! However, now I can’t see how these options are going to be as useful when the link will expire anyway after the first use for each individual user.
Personally, I still believe that if this was enforced differently by adding an option during the creation of the invite link that’s similar to the constraints above (by default the invite link will not be reusable unless the Admin unchecks this option and once unchecked there is a warning about the security issue that the discourse team is concerned about.) It would have made everything so much easier from my perception.
