Add "What brings you to FF?" to sign-up form

[joepavitt]

Description

Adds a new question "What brings you to FlowForge?" to the sign up form. This will likely need to be configurable at at the admin level too, and have a DB migration script (assuming we're storing this as part of the User object in the DB, which seems reasonable?)

Posthog-only storage of data

• Question added to UI
• Include value in "Person" object for PostHog analysis

FlowForge storage of data

Work started here: https://github.com/flowforge/flowforge/tree/2362-db-storage

• DB Migration Script
• Admin Setting Added
• Store value in DB when form submitted

Related Issue(s)

• Blocked by Radio group updates forge-ui-components#145
• Closes "What brings you to FlowForge?" question at sign-up #2362

Checklist

• I have read the contribution guidelines
• Suitable unit/system level tests have been added and they pass
• Documentation has been updated
  • Upgrade instructions
  • Configuration details
  • Concepts
• Changes flowforge.yml?
  • Issue/PR raised on flowforge/helm to update ConfigMap Template
  • Issue/PR raised on flowforge/CloudProject to update values for Staging/Production

Labels

• Backport needed? -> add the backport label
• Includes a DB migration? -> add the area:migration label

[joepavitt]

Question included on the site, with (currently) 3 options - can we think of any other options here @MarianRaphael? Want them vague enough that they're not overwhelmed with options, but defined enough to provide us value in customer segmentation.

[joepavitt]

@knolleary options welcome/required on the storage of the answer too, is the Users table reasonable?

[hardillb]

Aware this is still draft, but would this show on even a local install at the moment if sign up is enabled?

[joepavitt]

even a local install at the moment if sign up is enabled?

right now, yes, but that's my open checklist item about Admin Setting Added. Not my expertise in that part of the code base, so was hoping for an assist there

[joepavitt]

default would be that this is disabled, and I only expect us to have this in FF Cloud.

[MarianRaphael]

@joepavitt, having the default set as disabled is a great idea (Self hosted vs. FF Cloud). The four categories are a good choice. I might suggest changing the wording from "Learning Node-RED" to “Educational Use” in order to more clearly delineate the categories and prevent potential overlap. But it's ultimately up to you to decide.

[Steve-Mcl]

@joepavitt I am not sure the FF database is the right place to store this?

Should this not be something passed to posthog or another service intended for meta data?

[joepavitt]

@knolleary If I recall, we had the conversation about where this data is stored, and agreed it had to go in FF database? I was happy just to throw it into PostHog, and nowhere else. Input please.

[knolleary]

Personally, I don't think it fits in the database as its a one-off piece of information that we never need to refer to again in the platform. As I understand it, the requirement is to get this information into Hubspot. We need to identify the path it takes to get there. Lets have a chat with @robmarcer as he owns the bit that syncs up hubspot afaik.

[joepavitt]

I was hoping to have this in PostHog as priority, although could also see why this is useful in HubSpot too. HubSpot data is driven by our FF Database. PostHog is driven by API calls on sign-up.

[robmarcer]

Currently, any data which flows from FF Cloud to Hubspot has to go via the database. The system checks the database for specific user actions every X minutes (including new sign ups) and creates or updates the corresponding record in Hubspot as needed.

Therefore, if we want to add the users' reply to this question to their record in Hubspot without developing an alternative path we will need the answers to be in the database.

I assume that the marketing and sales functions of FlowForge (@iskerrett @ZJvandeWeg) would like to have this data in Hubspot although I don't see that stated in this issue as a specific requirement.

I appreciate that storing the data in the database forever (well at least until a user is deleted) is not ideal but I suspect it's also the path of least resistance to achieve the ACs.

[joepavitt]

Just to size the dev work required here ahead of the release on Thursday:

• To include in PostHog = done
• Requires:
  • DB Migration Script (Written) - checked out to 2362-db-storage
  • User/Admin configuration to define whether or not to show the question (not written)
    • Requires changes to the settings API, settings DB? and models.

[joepavitt]

I would propose, for 1.9.0, we push as we are (PH storage), and then utilise the PH /persons API to populate HubSpot in a similar fashion for now given the additional work required by Thursday if we want this into our DB.

As part of 1.10.0, we could then come up with a non-ph dependent solution which makes DB retrieval an option (subject to agreement on how it's stored in said DB)

[knolleary]

Looks fine - just needs the new ui-components to be published and package/package-lock updated to pick it up.

[ZJvandeWeg]

It'd rather have some data from Thursday onwards than nothing, so I recommend we move forward with this as is and find a definitive solution next release

[knolleary]

postgres tests appear to have got stuck - have cancelled and kicked off again

[knolleary]

This line breaks sign-up for instances without posthog, as join_reason is never set to anything so the sign-up button is never enabled.