Events plugin Server side refactor

Branch: https://github.com/paviliondev/discourse-events/tree/server-refactor

Changes Made

  • Refactored monkey patches to server plugin api methods
  • Consolidated imports
  • Refactored event creation logic in to EventCreator class.
  • Refactored event updation to EventRevisor class.
  • Grouped similar pieces of code together.
  • Fixed sorting issue on agenda topic list.
  • Deleting a user removes them from all rsvp lists

Yet to come

  • Tests

Thanks @md-misko, @tobiaseigen for testing the code out and spotting bugs

Final Testing checklist

Plugin Specific Features

[ ]

Integration Features

[*] Wizard Integration (The code is in place. I’ll officially release the feature afte these tests)
[] Locations Integration

Note This is merged now.

Sure, please let me know which branch it is and what functionality it changes and I’ll put it to test.

Since you plan to do a major refactor, may I draw your attention to the following:

Thanks for this.

Here’s the branch
https://github.com/paviliondev/discourse-events/tree/server-refactor

  • launcher rebuild with the server-refactor branch completed without errors, login is presented
  • upon login > server error 500

Error log:

Message

NoMethodError (undefined method `events_required' for #<Class:0x00007f2017c1c120>)
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/activerecord-6.0.2.2/lib/active_record/dynamic_matchers.rb:22:in `method_missing'

Backtrace

activerecord-6.0.2.2/lib/active_record/dynamic_matchers.rb:22:in `method_missing'
/var/www/discourse/plugins/discourse-events/plugin.rb:66:in `block (3 levels) in activate!'
/var/www/discourse/lib/plugin/instance.rb:210:in `public_send'
/var/www/discourse/lib/plugin/instance.rb:210:in `block (2 levels) in add_to_class'
/var/www/discourse/plugins/discourse-events/plugin.rb:68:in `block (3 levels) in activate!'
(eval):42:in `_fast_attributes'
active_model_serializers-0.8.4/lib/active_model/serializer.rb:468:in `rescue in attributes'
active_model_serializers-0.8.4/lib/active_model/serializer.rb:455:in `attributes'
active_model_serializers-0.8.4/lib/active_model/serializer.rb:480:in `_serializable_hash'
active_model_serializers-0.8.4/lib/active_model/serializer.rb:359:in `serializable_hash'

Env

HTTP HOSTS: discourse.forum.tld

Thanks for running that test. :slight_smile:
Converting this to a public topic

Couldn’t repro it. I’ve just pushed the stuff I did today.

But this analysis is correct. There’s indeed an error if I try to save that property

p.s.
This is fixed.

  • Open subcategory with events enabled and Calendar view set as default
    • Agenda view is displayed instead
  • Select Calendar view again > this displays the correct view
    • Select Subscribe button and copy the webcal link
    • link doesn’t include the user api key
    • two errors are logged:
Message (3 copies reported)

ApiKey::KeyAccessError (API key is only accessible immediately after creation)
/var/www/discourse/app/models/user_api_key.rb:37:in `key'

Backtrace

/var/www/discourse/app/models/user_api_key.rb:37:in `key'
/var/www/discourse/plugins/discourse-events/controllers/api_keys.rb:19:in `index'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.2.2/lib/action_controller/metal/basic_implicit_render.rb:6:in `send_action'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.2.2/lib/abstract_controller/base.rb:196:in `process_action'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.2.2/lib/action_controller/metal/rendering.rb:30:in `process_action'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.2.2/lib/abstract_controller/callbacks.rb:42:in `block in process_action'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.2.2/lib/active_support/callbacks.rb:135:in `run_callbacks'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.2.2/lib/abstract_controller/callbacks.rb:41:in `process_action'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.2.2/lib/action_controller/metal/rescue.rb:22:in `process_action'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.2.2/lib/action_controller/metal/instrumentation.rb:33:in `block in process_action'

Env

HTTP HOSTS: discourse.forum.tld
Message (2 copies reported)

Uncaught [object Object]
Url: https://discourse.forum.tld/assets/ember_jquery-cfe7d8017a9bcfea8efdaf942b2d9b28f4612bb74544d917c6d9ce03221d86b4.js
Line: 1
Column: 267440
Window Location: https://discourse.forum.tld/c/topic/subtopic/20/l/calendar

Backtrace



Env

HTTP HOSTS: discourse.forum.tld

Are there any specific scenarios you want me to test next?

I tried to repro the Agenda issues but was unsuccesful, all the events are sorted in the correct order (but I never experienced this issue on the production either, so I cannot confirm it is fixed).

Looks like you guys have this in hand :+1:

@md-misko Really appreciate your help.

24 posts were split to a new topic: Event iCal feed implementation update

Thinking about this one now.

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.

Please see my real case scenario here: https://thepavilion.io/t/wiki-topics-with-events-dont-allow-regular-users-to-change-date/1578/6?u=md-misko

That is actually much more excessive and problematic for GDPR and sanity reasons :stuck_out_tongue_winking_eye:

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 :wink:

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).

This is a bug, see: https://thepavilion.io/t/changes-to-date-and-time-on-topics-made-with-edit-wiki-feature-do-not-save/2186 and should be fixed IMO, changing event details definitely should leave a track in the edit history.

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. :rocket:

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 :slight_smile:

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.

Agreed. People shouldn’t be allowed to mess things up. Maybe mod approval is one of the options.

Just a fellow enthusiast, I guess :smile:. And while my ruby coding skills are fairly limited I have been able to contribute a miniscule amount of code :blush:, and I am doing my best to keep track of the changes, testing them out and finding potential bugs before putting them in production :sweat_smile: (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 believe it’s perfectly in line with the core Discourse vision, which can be seen in the discussion about the similar request to be able to edit tags on wikis, and by Sam’s response on Meta.

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.