Create a migration script from Events to Discourse Events

Field map

event_start Unix time stamp: of the event start date/time
event_end, Unix time stamp: of the end start date/time
event_all_day, boolean : whether its an all day event or not
event_timezone, Event’s timezone(Rails style)
event_rsvp, Whether users are allowed to rsvp
event_going, RSVP user ids
event_going_max, max number of people allowed to rsvp
event_version, iCal event version

Unable to migrate

  • category_custom_fields
    • events_enabled
    • events_agenda_enabled
    • events_calendar_enabled
    • events_required
3 Likes

If it’s OK, I’ll join the discussion @fzngagan.

1 Like

Sure @Bletch

1 Like

@fzngagan To kick us off could you start a list of the fields we need to map?

@Bletch Thanks for joining in! Perhaps you could have a think about how the migration script itself would work. I’m not sure a db migration would be the best, as you’d have to make too many assumptions about the user’s environment.

1 Like

event_start Unix time stamp: of the event start date/time
event_end, Unix time stamp: of the end start date/time
event_all_day, boolean : whether its an all day event or not
event_timezone, Event’s timezone(Rails style)
event_rsvp, Whether users are allowed to rsvp
event_going, RSVP user ids
event_going_max, max number of people allowed to rsvp
event_version, iCal event version

these are the values events plugin stores

There are also a bunch of category custom fields that control the way events are handled and configured at the category level.

I don’t know if these have equivalents in Discourse Event.

category_custom_fields: {
  events_enabled: false,
  events_agenda_enabled: false,
  events_calendar_enabled: false,
  events_required: false,
},

Sorry Angus, I’m not sure what you mean by a migration other than a DB migration.

Are you making a distinction between a Discourse plugin/rake task that understands the context of Discourse config/settings, etc. and a SQL-only migration? If it’s the former then that’s my starting point.

A couple of caveats to start with.

Firstly, my use is widespread but in a very specific way. For example, I do not use the RSVP functionality so I feel you’ll need to rope some other users into the project for that side of the plugin. Secondly, I haven’t even looked at Discourse Event yet so I don’t have a view of the delta or the possible workarounds that might be needed.

Let me install Discourse Event on my beta site and I’ll take a look so I can get a feel for what’s required - for my needs.

Dan.

1 Like

@all I’ve started a spec in the OP as a wiki. Please add further details there as you determine them. Anyone is allowed to edit it. The right sidebar is this layouts widget. If you find it too busy you can hide it by clicking the minus -.

@fzngagan We’ll need to map those fields against the relevant fields in the Discourse Events plugin.

This will probably need to be a rake task, as it’ll need to be run when the site admin is ready.

@how Feel free to add anything in here. If you could provide a relevant dataset that would be great too.

1 Like

I’m starting to take a look on how the official event plugin works overall. Will post my findings here.

As for the import script, I’m picturing it to be shipped with our events plugin and a similar UI to discourse backup screen which displays the current status of the process too.

1 Like

@Bletch
A few things that came into mind after using the official plugin

  1. Category settings - No changes required
  2. All the events will be open
  3. RSVP users will be migrated
  4. Event title will be defaulted to topic title
  5. All the rsvp users will be Going

Simplest way to accomplish this migration would be to add event markdown to the beginning of the first post. This will add the event data without us needing to go deep into the mechanism of how events are created by the plugin.