Tuesday, August 4, 2015

Product Update: App LearnStuff + Fixes For RSVP Lists, Old Venue Cards & More

Our biweekly Product Updates give you a rundown of all the features and bug fixes that are being deployed - plus one handy tip of the week.

App LearnStuff

Presenting: a dedicated section of our knowledge base for all things related to the APP. Head over to the DoStuff App section of LearnStuff for answers to FAQs, release notesknown issues and (perhaps most importantly) an updated list of workflow changes for content managers now that the app is live.


Have something you'd like added to this knowledge base? Just let us know!

Features & Fixes - Coming This Afternoon

We made sure that RSVP Lists are displaying all users in alphabetical order. Prior to this update, users who entered their names in lowercase were being displayed after all of the users who entered their names in uppercase. Confusing, right? Props to Kelsey615 for pointing this out.

We added a validation check to Radmin to ensure that users can not save an event with an end time that is before the start time. This will prevent a bunch of small errors (and also some confusion) that can arise from having an event end before it starts.

We removed the 'Your entry will also register you for DoXYZ...' language from giveaways and RSVPs on ECPs since that statement is no longer true (and hasn't been for awhile).

Quick review: All users who enter giveaways or RSVP on ECPs and do not have an account for the metro that powers that ECP are given the option to sign up for the metro after completing their entry (rather than being automatically registered).

A warning will now display when attempting to update a locked event in the dupes queue. Any locked event will also now have a 'locked' symbol beside the event title to indicate it as such. Please note that you will still be able to update locked events via the duplicate queue if you click 'OK' on the warning.


We set up unsubscribe links from band notification emails to look for all instances of a user's account on the metro. Prior to this update, users with duplicate accounts or duplicate preferences on a given metro were having trouble unsubscribing from band notification emails. Now, the 'unsubscribe' action will look for all accounts with the given email address and update the band email preferences on all of them accordingly.

We added 'topline info' to the list of fields that we can target via scraper rules. This was done specifically to fix some accent issues with a HazDF scraper - but this will be a valuable tool for every metro. Are you a CM and interested in learning more about scraper rules? Send us an email!

We prevented blank spaces from being accepted in RSVP passcodes. HazDF requested this feature so that users who accidentally copied and pasted RSVP passcodes along with a blank space would not have any trouble RSVPing to an event.

By popular request - Dev has worked some magic and adjusted /p pages to ensure that any 'old' embedded venue cards will now work correctly. We also recently adjusted venue cards to run off of venue IDs instead of venue permalinks - since permalinks change but IDs never do. Both of these updates mean that your venue cards should be much more stable going forward.

We fixed a glitch that was preventing event end times from properly saving in Radmin.

Tip of the Week

We all have a general understanding of the difference between the pending queue and the duplicates queue - but what is the best way to communicate the differences between these queues? What logic do scrapers use to decide where to put an event? 

For this week's tip, we thought it would be beneficial to draw out the process by which scrapers decide what to do with their incoming events.
A couple interesting things to note:
  • Incoming events are not validated against pending events - only approved events. That's just another reason why your Content Manager should bring the pending queue down to 0 at least 3 times per week. Otherwise, duplicate editions of the same event may sneak into the pending queue and end up on our site.
  • Two additional rules that operate in addition to the above process (but didn't fit neatly into the chart):
    • Scrapers also ignore incoming events that have the same venue, time, day of the week and title as an existing weekly repeating event. 
    • And scrapers ignore incoming ongoing events that have the same venue, title and end date as existing ongoing events. This rule was added recently - and if you've ever suddenly encountered multiple dupes of the same ongoing event on your site (I'm looking at you, DoLA), you will be very glad it exists!
If you have any questions about the scraping process or would like to see more diagrams like these, please let us know!

No comments:

Post a Comment

Thoughts to share? DO!

Tuesday, August 4, 2015

Product Update: App LearnStuff + Fixes For RSVP Lists, Old Venue Cards & More

Our biweekly Product Updates give you a rundown of all the features and bug fixes that are being deployed - plus one handy tip of the week.

App LearnStuff

Presenting: a dedicated section of our knowledge base for all things related to the APP. Head over to the DoStuff App section of LearnStuff for answers to FAQs, release notesknown issues and (perhaps most importantly) an updated list of workflow changes for content managers now that the app is live.


Have something you'd like added to this knowledge base? Just let us know!

Features & Fixes - Coming This Afternoon

We made sure that RSVP Lists are displaying all users in alphabetical order. Prior to this update, users who entered their names in lowercase were being displayed after all of the users who entered their names in uppercase. Confusing, right? Props to Kelsey615 for pointing this out.

We added a validation check to Radmin to ensure that users can not save an event with an end time that is before the start time. This will prevent a bunch of small errors (and also some confusion) that can arise from having an event end before it starts.

We removed the 'Your entry will also register you for DoXYZ...' language from giveaways and RSVPs on ECPs since that statement is no longer true (and hasn't been for awhile).

Quick review: All users who enter giveaways or RSVP on ECPs and do not have an account for the metro that powers that ECP are given the option to sign up for the metro after completing their entry (rather than being automatically registered).

A warning will now display when attempting to update a locked event in the dupes queue. Any locked event will also now have a 'locked' symbol beside the event title to indicate it as such. Please note that you will still be able to update locked events via the duplicate queue if you click 'OK' on the warning.


We set up unsubscribe links from band notification emails to look for all instances of a user's account on the metro. Prior to this update, users with duplicate accounts or duplicate preferences on a given metro were having trouble unsubscribing from band notification emails. Now, the 'unsubscribe' action will look for all accounts with the given email address and update the band email preferences on all of them accordingly.

We added 'topline info' to the list of fields that we can target via scraper rules. This was done specifically to fix some accent issues with a HazDF scraper - but this will be a valuable tool for every metro. Are you a CM and interested in learning more about scraper rules? Send us an email!

We prevented blank spaces from being accepted in RSVP passcodes. HazDF requested this feature so that users who accidentally copied and pasted RSVP passcodes along with a blank space would not have any trouble RSVPing to an event.

By popular request - Dev has worked some magic and adjusted /p pages to ensure that any 'old' embedded venue cards will now work correctly. We also recently adjusted venue cards to run off of venue IDs instead of venue permalinks - since permalinks change but IDs never do. Both of these updates mean that your venue cards should be much more stable going forward.

We fixed a glitch that was preventing event end times from properly saving in Radmin.

Tip of the Week

We all have a general understanding of the difference between the pending queue and the duplicates queue - but what is the best way to communicate the differences between these queues? What logic do scrapers use to decide where to put an event? 

For this week's tip, we thought it would be beneficial to draw out the process by which scrapers decide what to do with their incoming events.
A couple interesting things to note:
  • Incoming events are not validated against pending events - only approved events. That's just another reason why your Content Manager should bring the pending queue down to 0 at least 3 times per week. Otherwise, duplicate editions of the same event may sneak into the pending queue and end up on our site.
  • Two additional rules that operate in addition to the above process (but didn't fit neatly into the chart):
    • Scrapers also ignore incoming events that have the same venue, time, day of the week and title as an existing weekly repeating event. 
    • And scrapers ignore incoming ongoing events that have the same venue, title and end date as existing ongoing events. This rule was added recently - and if you've ever suddenly encountered multiple dupes of the same ongoing event on your site (I'm looking at you, DoLA), you will be very glad it exists!
If you have any questions about the scraping process or would like to see more diagrams like these, please let us know!

No comments:

Post a Comment

Thoughts to share? DO!