Reply via email support

Site Feedback
#21

In Foreman, we have a privacy user group and the members of that group get DM’d on discourse via the privacy email. Is it possible to do that do you think?

#22

A friend of mine had a similar problem when he moved mailman 2 lists to discourse, and I think one of the issue he faced was that people need a account on discourse to create a topic. It can be configured to create one on the fly, but then, people who already have a account couldn’t use the alias. So it was a bit messy (and didn’t work for his usecase).

I do not remember the details as we spoke of it more than 24h ago, so maybe I am wrong.

I think what he did was to add a alias from xxx@example.org that go to the same mailbox, and then attach that alias to a topic, topic who is hidden and restricted.

I will ping him, and see what he has to tell me.

#23

I will split my response in several posts in order to workaround the issue Discourse message Sorry, new users can only put 2 links in a post.

I confirm this issue which is discussed here.

A workaround is to associate the email to a group instead of a category. Indeed, the everyone value for the Who can message this group? setting allows unregistered users and registered users to send a message to a group (whereas the Accept emails from anonymous users with no accounts setting of a category will refuse messages from registered users if they don’t have the create permission).

1 Like
#24

Some related documentation (part 1/2):

1 Like
#25

Some related documentation (2/2):

Note that:

1 Like
#26

@pilou - Thank you. I will read through these today.

#27

So I added the privacy alias going to discourse for now. We can change for a email based workflow later if needed.

MR: Add a privacy alias (!483) · Merge requests · OSCI / community-cage-infra-ansible · GitLab

1 Like
#28

@misc From what I understand from the docs on this thread, I now create a privacy group who receive those into their inbox for now?

#29

Yeah, I think that’s the way to do it. I haven’t looked that much on that side of discourse but we can just test.

I think we also want to see if it work in the following way:

  • people with a account can create a ticket
  • people without a account can create a ticket
  • check if authorized people (staff, privacy group) can access new tickets
  • check if authorized people can access old tickets
  • check that people who commented can’t access the ticket if we remove them from the group
  • check the requester can (or can’t, if that’s what we want) access the discussion.

I think the last one is tricky, if someone open a ticket, how is the communication with them going to be done ? And where is the discussion between the team going to be ?

Asking that because while we are speaking of privacy@ alias and it will just be 1 answer, I assume a similar discussion will need to occurs for the CoC, with a bigger focus on privacy and ACL (for example, I would point to that bug on pagure that I happened to trigger while reporting a ticket last year).

Also, should there be a read indicator, or a way to say “this was handled”, and what it should be (as a norm for the team in charge) ?

1 Like
#30

I haven’t seen this in Foreman, but a good point!
I will investigate. I am trying to formulate some text around the right to request privacy info. For example, I’m pretty sure that we need to verify identity for the account before we engage. This came up as part of the Princeton study controversy.

#31

I think it depend on the request. For example and speaking of the Princeton study, a request for information would be valid and under the purview of GDPR principles (article 12, point 1), and wouldn’t requires to verify any identity. I got the mail for Gluster, and I just checked, the privacy policy say:

If you have any questions about any of these practices or Gluster’s use of your personal information,
please feel free to contact us by email at privacy@

I can see why people were nervous, but we are in the 4th year of the GDPR adoption, I do not think anyone should have been surprised. Now, of course, I live and work in a country under GDPR-like laws dating around the time of release of Hotel California and nothing bad happened, so I guess I have a more relaxed view of the problem than a lot of people.

1 Like
#32

I went through everything in the Discourse docs (some applied more to consumer/customer type forums than a FOSS forum) and I compared against the Foreman settings.

I’ve set up a privacy groups and put the Pulp admins in there. The general idea was 2 members on either side of the Atlantic to cover most TZs.

All we need now it seems is the email address PR to be merged and a bit of testing!

Thank you !

1 Like
#33

Hey @duck @misc

Looks like we are good to go? Can you confirm the email address so I can add it to our website?

#34

It should be privacy@

#35

However, I might have typed privacy@@ in the config file, so let me redploy that part first … (should be good soon)

1 Like
#36

I tried to test it there out of curiosity and it failed.

#37

So seems the smtp side is ok, I guess I forgot something on the discourse side (and I didn’t test due to me being on PTO, I should have warned)

#38

Ok, i think adding the email on the staff category is the fix. Discourse sent back a email saying “the email didn’t work”, so I guess that’s because it wasn’t attached to any categories. Now, it just refuse because I used a different email. So I hope the 3rd one is working (“accept from anonymous mail”)

1 Like
#39

So it now work. The way discourse deal with it by auto creating a user is maybe not great, since I wonder if discourse will continue to mail summaries, etc (and since I think automated mail is one of the main driver behind privacy requests…). But time will tell.

1 Like
#40

Strange. I wonder have I misconfigured something.
It’s working but in Foreman it comes through as a DM to our inbox, while here it is posted to the staff group. I had created a separate “privacy” group to receive these mails… I’ll take a look.