Staged users can't reply to their own topics

bug
#1

Use case is private email support portal. We have a private category that a handful of users can access. The general public can send emails to info@foo.bar and they are posted in our public emails category. When one of the discourse users replies, it gets posted in the topic, and the member of the public (now a staged user) gets the reply in an email. This all works well.

As of about a month ago (I just noticed this now and don’t know exactly when it started) when that staged user replies to the topic they started their email is rejected:

Email can not be processed: Something has gone wrong. Perhaps this topic was closed or deleted while you were looking at it?

This is happening even though the topic is certainly not closed or deleted. Recently updated to 1.6.0.beta8 and the problem persists.

1 Like
#2

Any ideas here @zogstrip?

1 Like
#3

I scrolled through the logs and found the first occurrence was on April 23rd. Is there a way to find what version we were running at that time?

Backtrace

/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/logster-1.2.2/lib/logster/logger.rb:74:in `add_with_opts'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/logster-1.2.2/lib/logster/logger.rb:35:in `add'
/usr/local/lib/ruby/2.0.0/logger.rb:445:in `warn'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:160:in `log_email_process_failure'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:52:in `handle_failure'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:42:in `rescue in process_popmail'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:24:in `process_popmail'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:117:in `block (2 levels) in poll_pop3'
/usr/local/lib/ruby/2.0.0/net/pop.rb:688:in `block in delete_all'
/usr/local/lib/ruby/2.0.0/net/pop.rb:687:in `each'
/usr/local/lib/ruby/2.0.0/net/pop.rb:687:in `delete_all'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:116:in `block in poll_pop3'
/usr/local/lib/ruby/2.0.0/net/pop.rb:531:in `start'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:115:in `poll_pop3'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:15:in `execute'
/var/www/discourse/app/jobs/base.rb:154:in `block (2 levels) in perform'
#4

I’m not sure I understand. What is your private category for? What is its relation to the “public emails” category?

#5

The name of the private category is public emails. The private category is the one for the incoming email, set up as described in paragraph B4.

#6

Ok, can you share the security settings you’ve set up for that category?

#7

We have a group of users who can Create / Reply / See, and we Accept emails from anonymous users with no accounts. The site wide email in min trust is set at 0.

1 Like
#8

Just pushed a fix :rice:

2 Likes
#9

Do users lose the ability to do this once they log in on the web, converting them to a regular user?

#10

If they aren’t part of the restricted groups, yes.

#11

That feels wrong – logging in should never cause you to lose permissions.

Maybe this should affect both staged and non-staged users, as long as the category is set to allow emails from strangers? After all, even non-staged users are strangers to this category :wink:

(This still leaves the confusion that the user can interact with the topic by mail but doesn’t see it on the web.)

There is a large overlap between categories with email-in for strangers and groups with email-in messaging. It feels like this problem is part of the confusion caused by this.
In the group messaging world, this feels way more natural, because messages offer full access to their participants.

1 Like
#12

Working great so far. Thanks! :yey:

I disagree. Remember the use case is a private email support system. We are a membership based organization (a makerspace) who uses discourse for communication between members, and to handle emails from the public. Only a few of our members get access to read or reply to public emails. We regularly have people email us with questions about our organization before they join, and in turn register on discourse. Just because they have emailed us in the past as a member of the public, does not mean they should be granted access to all our communication with the public, past and future.

1 Like
#13

Wait, that’s not what I’ve been trying to say.

As I understand, the current behavior is:

  1. Non-member emails you.
  2. This creates a non-public topic.
  3. The user can read your replies because they are mailed to him, and can reply to your posts by mail.
  4. When the user becomes a member, his old mailed-in posts are associated with him.
  5. He still cannot see them on the web, because he cannot read the restricted category.
  6. He can no longer send mails to info@foo.bar or reply to old conversations per mail, because he no longer is a staged user.

Is that correct with your recent fix, @zogstrip?

If so, I think that (5) is possibly confusing but okay, but (6) is a bug. The fact that the user logged in on the web should not take away the possibility to email info@foo.bar or to reply on older conversations he started via mail before he was a member.

Of course, this user should never get full access to the “Public emails” category just because he has posts in there – maybe his own topics (as would be the case with group messaging), but certainly not all.

Does this make more sense? :slight_smile:

2 Likes
#14

Ah sorry I misunderstood. I get what you are saying now. I just did a quick test by activating the staged user I was using to diagnose the original bug. Once activated that user can actually access and reply to their non-public topic. There was a reply notification that when followed takes the user to the topic. Interestingly there is no category listed under the topic title, and of course they don’t see any other evidence that the restricted category exists. Looks like everything is working as it should :slight_smile:

4 Likes
#15

That sounds great! Thanks for testing :slight_smile:

Can the user still reply via mail, and can he reply on the web?

#16

Yes the user can do both.

2 Likes
#17