I’m not so sure this is a good idea… better to give some users moderator privs so they can access event details. But weren’t we also planning to provide the ability to export a csv of attendees and their status? If that’s going to happen (and I hope it does) then it would be potentially pretty bad to open this up to members of discourse instances for GDPR and sanity reasons. Also, events details is a bit sensitive and it would be hard for moderators to manage if anyone can edit, esp since unlike wikis there is no ability to track changes.
That is actually much more excessive and problematic for GDPR and sanity reasons
Wiki topics are meant to be edited by the community, and I see no reason why event date and time shouldn’t be edited on a wiki topic.
Where this is undesirable, simply don’t make topic a wiki
I don’t want to play down your concerns, they are definitely valid, but for such cases simply don’t make event a wiki!
Editing event details on wiki topics (for appropriately high trust level users, which can be controlled by site settings for both wikis and events) is also in line with the core ability to edit tags on wikis (which was a part of a similar conversation on meta a while ago and was already implemented).
OK - your use case and explanation sounds reasonable to me. But you are expecting quite a bit more from this third party plugin than I am! Not sure what your role is here but hope you can contribute money or code to make this level of integration happen. Anyway it’s good to meet you and happy to have another co-conspirator to help make this plugin as awesome in reality as in its potential.
The functionality to export rsvp details has not been added yet. If you do decide to allow everyone with access to “wiki events” to edit event details and to access rsvp details, I’d recommend a sane approach that allows limiting access to personally identifiable information to highly trusted roles e.g. admin only.
The revision logging question is interesting - I just checked and it is indeed weird that editing event details actually saves a revision even though the old and new revisions look identical, and event detail changes are not logged. I do not know how hard it would be to store event details with revisions along with all the functionality included to roll back to earlier revisions etc. Or if this is a worthwhile goal to have given that core functionality tends to change, creating work for third party plugin maintainers. At the very least, it should not be logging a revision if none of the data stored with revisions is actually changed. That does seem to be a bug.
Would a revision be added also whenever someone changes their RSVP? That’s alot of revisions! So I would guess not.
Meanwhile, if permission is going to be opened up to access PII of those who RSVP then some way of logging accesses and exports would be essential for GDPR. This is done already when moderators access email addresses of users via their profiles.
I want to thank you guys for your support. It means a lot
This PR was originally meant just for simplifying the server side code. Co-incidentally some bugs which had resurfaced, or had been prevalent for a long time were taken care of. I am completely in favour of enhancements, but in a systematic fashion.
We’re working towards improving unit tests coverage which means writing tests for existing codebase.
I’m looking to first merge this branch before our 1st scheduled update cycle(starting from 1st May) so that this code is made available in production.
Just a fellow enthusiast, I guess . And while my ruby coding skills are fairly limited I have been able to contribute a miniscule amount of code , and I am doing my best to keep track of the changes, testing them out and finding potential bugs before putting them in production (I’m running a very small private forum, where I have connected a small custom app with the forum via API, which relies on the events plugin).
And definitely nice to meet you too, this plugin (and others here) really are awesome and deserve every bit of effort.
I don’t really see the ability to edit event details on wikis as a request for any new functionality, more just as a natural consequence of what the purpose of a wiki is: collaborative effort.
I don’t know about RSVP’s, there seems to be a real PII issue there which perhaps requires an additional setting, and a thorough consideration before making such an event into a wiki (I don’t suspect many users will ever do this anyway, but it would be consistent with the purpose of the wikis to be able to do so).
But for a regular event, which is also a wiki, permissions to edit the event details can be governed by events min trust to create setting, used analogously as per Sam’s post above (‘Wiki editors should be allowed to edit tags as long as: min trust level to tag topics is met’)—meaning anyone who has permissions to create events can also edit them, not only on their own topics but also in all wiki topics.