introduce new salesforce table for services

[jjwon0]

i think we're going to need a few new tables and will have to migrate to it eventually. this also might be what the Provider table is for, but it appears to be unused right now. no clue how to do this in salesforce.

this is lower-priority, but it's a requirement for self-sustainability.

something like:

class Service(Model):
    """Represents a service that can be offered at an event."""

    id = Column(BigInteger)
    event = Column(ForeignKey('PhcEvent'))
    title = Column(String(100))
    description = Column(Text)
    tooltip = Column(String(250))

class EventRegistrationService(Model):
    """Represents the status of a ``Service`` for a particular ``EventRegistration``."""

    id = Column(BigInteger)
    status = Column(ForeignKey(EventRegistrationServiceStatus))  # can just be a picklist in salesforce

regarding the first table, right now there's a lot that is hardcoded: tooltips, descriptions/friendly names, titles (these don't even seem to be editable in salesforce anywhere, and would probably break a lot of things if they were edited in say, a PHC event object). rather than be strings, these probably should be foreign keys to other objects. the second table would just come naturally from having the first one.

cc @altonzheng for thoughts or opinions

[jjwon0]

Another alternative to get around some of these Salesforce annoyances is using Google Spreadsheets as a backend instead. This would potentially maintain the reports capability (and probably, would be easier to create/edit/display them), and be much easier for us to rewrite the schema correctly.

[jjwon0]

However, the good library for working with spreadsheets that I've found is gspread, which is a Python library, so if we used this, we'd have to make a few modifications:

• rewrite the server code using Python (I think I'd prefer Flask over Django since we don't have any server-side state to keep track of, and also a custom backend that isn't a database, but no huge preference)
• update deploy script to compile webpack assets before serving
• get rid of a lot of the boilerplate code that we aren't even using right now (e.g. server-side rendering, etc)

There is a javascript lib for working with spreadsheets that seems okay, but it does not seem as good.

[jjwon0]

On second thought, we'd probably need to prototype Google Sheets first, because it'd be bad if the API broke or stopped working during an event; another idea is using Postgres or a regular database, and adding a cron job that dumps to a sheet daily.

[altonzheng]

Google spreadsheets is an interesting idea. So do you envision having each sheet being like a table and PHC people manually go in and edit rows?

Another option is using an admin library and adding a regular DB with the existing stack.

I found this one but there's probably more around:
https://www.npmjs.com/package/nodeadmin

[altonzheng]

Okay apparently there's already a Service object

https://na2.salesforce.com/01I40000000MF9s?setupid=CustomObjects

What do you think of using the salesforce object for V1 and instead of having a phc event foreign key, just have a boolean field in the service object itself, like "enabled"?

[jjwon0]

Oh yeah, none of this is really that important for v1 of the check-out form. I already have a branch going for that locally, I think it should work.

It sounds like the Service object as exists would work if we just add the PHC_Event__c field, but there still needs to be some way (likely some sort of join table) to connect Service objects to Event_Registration__c. If this is all easy-ish to do in Salesforce, then maybe we don't really need any of the other solutions I mentioned; I just thought they might be cleaner.

[jjwon0]

Whoops, never sent the comment below (supposed to be inserted before your one about the Service object)

Yeah -- each sheet is a table (although perhaps we can condense them, still not sure what the schema would look like). The rationale here would be that Google Sheets is easy to use for generating reports, and basically all Salesforce is doing as far as I know is storing data and providing a crappy tool to make reports with.

I'm starting to think that having an regular DB would be a better option, but I'm not totally sure if it's true.