search

CON-In-A-Box / CIAB-Portal

The Core of Con-In-A-Box, but so much more! Convention Meetings, Registration and Volunteers management software package
Apache License 2.0
9 stars 5 forks source link

Registration Portal #62

Closed seanbseanb closed 6 years ago

seanbseanb commented 6 years ago

As a registered attendee, I want to be able to login (authenticate) and determine the details of my registration for this year's convention. I want to be able to see how many tickets I've bought, and the names of the other attendees for the event.

AricStewart commented 6 years ago

Just as a started to load the full event registration data from Neon take about 7-8 minutes. This is very much an unacceptable load time for any web page or action. We also cannot search the data only load the whole event.

This leads up to a conundrum. Registration for 2018 has already begun in Neon, so there is live data being updated regularly. To switch to MySQL we would want to have a proper design discussion and then have a cutover date once all the tools using Neon to register events are replaced. I feel like that is maybe too large of a target for the current time scale. If We work hard we could hopefully have something place for 2019 so that when at the CON registrations for 2019 happen they can happen into MySQL and NOT Neon.

But own, that means to look up the data about 2018 takes 7 minutes, per lookup. We can lookup and cache but we have no information as to when our cache has become invalid.

one idea, maybe not a good one but something to start from. We could have 2018 still use Neon for registration however we still design all our new tables and features, Then we have a cron job of some sort that every 5-10 minutes updates the MySQL database from neon. It would be constantly working but it would mean that the database is at most 10 minutes out of date from Neon.

Then our registration related tools all worked against the MySQL db with the speed and responsiveness required there. Very much not Ideal but I do not see an easier way yet.

Thoughts?

tskeeley commented 6 years ago

That would certainly work. The other option is similar, but moving the data from the events part of neon to the membership part.

I'm also willing to cut the cord, but only if we can handle it all, which I don't think we are at.

That all said, there is a big push right now in Anime detour and Furry Migration to have a supportable system. AD is useing something that could work and be built on. I'm getting more info so we can look at it and possibly join in if it's right for us.

AricStewart commented 6 years ago

Both of those ideas requires backend design, What does the database look like? what are the tables etc. Thomas you did all the previous design are you wanting to do this part also?

tskeeley commented 6 years ago

I am gladly willing. But I'd like to have a discussion over it all so I can make a good design from the get go. Are we to the point of a videochat, or, dare I suggest it, lunch?

NOTE: I'm out of town until 3/3 with the loss of my mother in law. so, I'm in and out as I can, and internet here SUCKS. So, if we do video in the near future (not saturday) then I need warning so I can get to a coffee shop or restaurant with a good connection.

cvg-it commented 6 years ago

Audiochat (concall) would be another option..

I’m currently looking for the setup instructions, as I finally have working IP at home.

On Feb 22, 2018, at 1:58 AM, Thomas Keeley notifications@github.com wrote:

I am gladly willing. But I'd like to have a discussion over it all so I can make a good design from the get go. Are we to the point of a videochat, or, dare I suggest it, lunch?

NOTE: I'm out of town until 3/3 with the loss of my mother in law. so, I'm in and out as I can, and internet here SUCKS. So, if we do video in the near future (not saturday) then I need warning so I can get to a coffee shop or restaurant with a good connection.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/CON-In-A-Box/CIAB-Signin/issues/62#issuecomment-367596599, or mute the thread https://github.com/notifications/unsubscribe-auth/AYIiVvBFJZqlDPMyjfrhXyHbtb2j1gsZks5tXR4JgaJpZM4SEaKQ.

cvg-it commented 6 years ago

I’d be fine with replicating what’s in the events db down to Neon and have it lag by X minutes. Then, at some point, cut over new registrations from going into Neon, to going into our DB.

On Feb 16, 2018, at 6:44 PM, Aric Stewart notifications@github.com wrote:

Just as a started to load the full event registration data from Neon take about 5-6 minutes. This is very much an unacceptable load time for any web page or action. We also cannot search the data only load the whole event.

This leads up to a conundrum. Registration for 2018 has already begun in Neon, so there is live data being updated regularly. To switch to MySQL we would want to have a proper design discussion and then have a cutover date once all the tools using Neon to register events are replaced. I feel like that is maybe too large of a target for the current time scale. If We work hard we could hopefully have something place for 2019 so that when at the CON registrations for 2019 happen they can happen into MySQL and NOT Neon.

But own, that means to look up the data about 2018 takes 6 minutes, per lookup. We can lookup and cache but we have no information as to when our cache has become invalid.

one idea, maybe not a good one but something to start from. We could have 2018 still use Neon for registration however we still design all our new tables and features, Then we have a cron job of some sort that every 5-10 minutes updates the MySQL database from neon. It would be constantly working but it would mean that the database is at most 10 minutes out of date from Neon.

Then our registration related tools all worked against the MySQL db with the speed and responsiveness required there. Very much not Ideal but I do not see an easier way yet.

Thoughts?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/CON-In-A-Box/CIAB-Signin/issues/62#issuecomment-366399173, or mute the thread https://github.com/notifications/unsubscribe-auth/AYIiVmhZhxUCaORiAun7_8vuzkc0PGZoks5tViDYgaJpZM4SEaKQ.

tskeeley commented 6 years ago

That is my working plan for this year, as far as i know.

AricStewart commented 6 years ago

Breaking the requests on this one out.

Maybe we could design this so that the first bits of information (My registrations) could fall in as a main dashboard module. And then we add a search for attendees list? It would just be a list of badge names as we don't have any other information we would want to share about them to an unknown party right?

AricStewart commented 6 years ago

From Slack:

Badge Details:

  1. How many attendees (badges) do I have
  2. Who bought the badges
  3. When were the badges bought
  4. Listed badge names for each: “Badge Name: Captain Saffron” 5: Nice to have: In Case Of Emergency (Name and Phone)

Shown for all badges connect on the same transaction and to this account.

seanbseanb commented 6 years ago

" determine the details of my registration for this year's convention" -> For my email address, what badges are associated with my email address?

In the current API, we can pull all badges, and then can sort through them looking for email addresses set on those badges. Ideally we'd periodically dump all badges, and populate them into a set of MySQL tables that we could look up, vs. making synchronous API calls to Neon. Then when we display the data in CIAB we could include the datestamp of when the last DB dump was (indicating how current the data we're looking at is).

We can potentially screen-scrape to get the rest of the data not available in the API, but I don't think that part is critical today.

AricStewart commented 6 years ago

the names of the other attendees for the event

Just associated with this badge, not all attendees

AricStewart commented 6 years ago

I believe this is now resolved.

Re-open if I am incorrect