Thanks for responding! Glad to hear you have visibility on the issue.
Unfortunately we do not have a test-passed instance with SSO, as we’ve always stuck with stable. I do have a test-passed branch without SSO and there are no issues there.
EDIT: I’ll give it a go to see if I can get a test-passed instance with SSO running
EDIT:
Just an FYI for others who may be experiencing this:
Version 2.8.11 of stable does not fix the issue. Clicking on Accept Invitation spews out a console log error now though: PUT https://<DOMAIN>/invites/show/<INVITE_CODE>.json 404
The .json url takes you to:
// https://<DOMAIN>/invites/show/<INVITE_CODE>.json
{
"errors": [
"The requested URL or resource could not be found."
],
"error_type": "not_found"
}
Hi @hyphalos I’ve started taking a look at this today. I’m unfamiliar with our SAML setup so please bear with me.
This is a little strange, the “Accept Invitation” button should only show for logged in users. Can you please post a screenshot of what both logged in and logged out users see for a specific invitation, and also what options are you choosing for the invitation here:
Thanks for getting back to me. Sorry for the delayed response, I was out sick.
I did some more testing and what I’ve observed is after updating to v2.8.11 is that people can only accept an invitation once no matter the create invite settings. I’ve tested it with Arrive at topic, without arrive at topic, add to group, without add to group, etc. and people can only accept invites once. Is this intended behaviour?
What if a guest signs up but uses the same invite URL again, they’ll get stuck in the invite page (no redirection with arrive at topic). When they click Accept Invitation, this error pops up:
EDIT: Just wanted to add that if it is intended behaviour, there is no error that shows up that “You’ve accepted this invitation before” or something along those lines, or just redirect to wherever the arrive at topic is set to in the invitation.
I’ve updated to 2.8.12 (which according to the commit tag in the admin panel includes the fixes) and I now see an error message (on a test account) for attempting to accept an invite I’ve once accepted on the test account:
Which is great!
Although as someone already logged in, I didn’t expect the “Okta SSO” button to be displayed. When the button is clicked, it loops into SSO and then brings be back to the invite page. As the user is logged in, shouldn’t the login button be hidden to avoid confusion?
Yes I see the issue here now, we are still showing the Discourse Connect button even if the invitation has already been redeemed, and also for an existing user who has not redeemed the invite.
Invite not yet redeemed for existing user with DiscourseConnect enabled:
I think the correct thing is to hide the “Accept Invitation” button in the first case and the “Continue” button in the second case though I am not entirely sure, since going via the SSO login path accepts the invitation as well discourse/session_controller.rb at 13db6234940e50f66bc712a054003e362ae9dbcd · discourse/discourse · GitHub . @sam do you have any thoughts on this? I am just a little reluctant to make more changes to this UI/system at the moment…
The UI change sound pretty straight forward, I know how annoying this is, but if it is just hiding a button conditionally I recommend doing it, but not backporting.
So sorry, I think @hyphalos can simply use CSS here to work around, no? Hide the elements that are a problem? I would prefer not to backport anything we are too close to 3.0 release.
This is not really doable since a different button needs to be hidden depending on state:
However if its too risky before 3.0 then there is not much we can do here, I will just make the fix in main and it will trickle down to stable in the new year.