Using the 🗓 Discourse Event functionality, I find it quite cumbersome to download and use the .
Currently it uses a similar mechanism to the User Export, giving you:
a zip file via a PM to those with edit privileges on that post
gives you these fields: username status first_answered_at last_updated_at
Suggestion 1
That a direct .csv download be provided from the modal
This would be much simpler from the user perspective
Suggestion 2
That primary emails be reported in this download (or there be an option for this)
This would allow easy export of participants when needed for other purposes related to the event.
I’ve got a Data Explorer query for this at the mo which works well enough, but requires a lot of fiddle to give event organisers (i.e. the OP) access to it:
-- [params]
-- int :post_id
WITH e AS (
SELECT email, user_id
FROM user_emails u
WHERE u.primary = true
)
SELECT dpei.user_id, email, status, notified
FROM discourse_post_event_invitees dpei
JOIN e ON e.user_id = dpei.user_id
WHERE dpei.post_id = :post_id
ORDER BY status, email
Just caught out by this again today, when one of our admins asked how to see when people had clicked “Going”.
The UX issue we had was that clicking on Export event doesn’t appear to actually do anything (i.e. there is no feedback). It was only when I noticed that I had a few messages later (as I clicked several times while looking for errors in the console) that I realised it had actually worked.
Zipping the file just seems to add a lot of friction for zero value. Any CSV is likely to be quite small.
It would be nice to tidy this up a little bit, as it is quite useful functionality (once you work out how it works).
We use Discourse’s [event] syntax (via the Calendar plugin) to schedule and coordinate official council meetings — each event lives inside a dedicated topic, and we encourage members to RSVP using the built-in interface.
The problem is: we currently have no clean way to extract that RSVP data in a usable format. For public engagement sessions, executive meetings, and internal briefings, it would be incredibly useful to export:
Event topic title + URL
Display name / username of RSVPs
RSVP status (going / interested / not going)
Email address (admin-only, for attendance logs or direct follow-up)
Timestamp of RSVP (if possible)
Our clerks and chairs often don’t use Discourse themselves, so being able to download a CSV and share attendance with them is essential.
Understandably, email visibility would need to be permission-limited to site staff or group moderators — but without it, the export loses most of its administrative value.
This kind of structured export would significantly improve the plugin’s usefulness for real-world orgs that use Discourse to coordinate offline meetings.
This data explorer query will go a long way towards giving you what you need:
-- [params]
-- int :topic_id
WITH user_emails AS (
SELECT
ue.user_id,
ue.email
FROM
user_emails ue
WHERE
ue.primary = true
),
forum_timezone AS (
SELECT
value AS timezone
FROM
site_settings
WHERE
name = 'discourse_local_dates_email_timezone'
)
SELECT
u.name AS display_name,
u.username,
ue.email,
CASE dpei.status
WHEN 0 THEN 'Going'
WHEN 1 THEN 'Interested'
WHEN 2 THEN 'Not Going'
END AS status,
to_char(dpei.created_at AT TIME ZONE 'UTC' AT TIME ZONE ft.timezone, 'YYYY-MM-DD HH24:MI:SS') AS rsvp_timestamp
FROM
discourse_post_event_invitees dpei
JOIN
posts p ON p.id = dpei.post_id
JOIN
users u ON u.id = dpei.user_id
JOIN
user_emails ue ON ue.user_id = dpei.user_id
JOIN
forum_timezone ft ON true
WHERE
p.topic_id = :topic_id
ORDER BY
dpei.status, ue.email
If you make a group for your admins staff, and make this query accessible to them it will likely do the job nicely. You’ll probably want to set the Discourse Local Dates Email Timezone setting (or hack the query to ignore it).
You’ll need to teach them to use the Topic ID, and what that means in terms of URL. But that is probably doable.
Yeah, but your administrative staff probably shouldn’t be admins for your Discourse site unless they truly need that level of access.
So you can either make them full admins and use @admins, or make a new group which contains them. Then just assign the Data Explorer query to that group (they can then access it under the Reports tab.
.