JasonTheAdams
commented
1 year ago Hi @dreazee!
Good catch! Yeesh, these kinds of bugs are finicky. The culprit was in capitalization in the data. When a user RSVP'd via the event page, the form stored the data as "Yes". Whereas when the user RSVP'd via the Portal the data was stored as "yes".
What's finicky about this that depending on what you're doing (and what operating system the server is running on) different systems do and don't care about the change in case. For example, if I queried in the database for attending = "yes", then it would return both — as it's not case-sensitive by default. But, for the portal, I'm pulling in the data and comparing it on the server as $attending === 'yes' which is case-sensitive.
Hahah! Fun stuff. I just thought you mind find that interesting. Anyway, here's what I did:
- The RSVP form now saves the data as "yes" for consistency
- All existing RSVP attending data has been switched from "Yes" to "yes"
Now, whether I RSVP via the Portal or form, it's showing up correctly. I also tested an existing form RSVP, which should now show up as expected since I updated all existing RSVPs as well. So, while you were very close that it could be a single word in the code, it ended up being no code change at all. 😉
Please let me know if you run into anything further and I'll jump on it as quickly as I can!
@JasonTheAdams Hi! I have another fun one for you. I am visualizing that it can be fixed super easily by just changing a word in the code :) I kept noticing double RSVPs. Coming first from the calendar and then thru the Portal. (A Calendar-originating RSVP shows the event start time on them and Portal RSVPs don't). I thought I was imagining it, but then more came thru so I did some sleuthing. Found out that if a User RSVPs 'yes' in an event page, it shows up in the Portal as a 'no' RSVP instead of a 'yes' RSVP! (The 'no' event RSVP also shows up in the Portal as a 'no', too, so that's good!) Help??