Endpoint to populate airtable with data from the FE 'Team Treehouse Licenses' form

[hpjaj]

trafficstars

Feature

Why is this feature being added?

The FE will be creating a form around Team Treehouse Licenses. This form will only be accessible to ID.me verified users. This data needs to ultimately be populated in Airtable in a new airtable.

Associated Issue

https://github.com/OperationCode/operationcode_frontend/issues/890

What should your feature do?

We already have endpoints for:

• creating a scholarship application
• showing an existing scholarship
• getting a collection of all scholarships

This ticket would need to:

For the creating a scholarship application endpoint:

• [ ] add validation to ensure that the passed current_user is verified
• [ ] validate that the following information is present for the current_user:
  • [ ] user.slack_name
  • [ ] user.first_name
  • [ ] user.last_name
  • [ ] user.email
• [ ] test coverage
• [ ] updates our API docs
• [ ] collaboration with the FE team on the endpoint's schema (i.e. what they are sending to the BE)

[hpjaj]

@kylemh !

Can you please describe:

1. Precisely what data this FE form will be passing to the BE?
2. If that data will/will not be a 1:1 mapping to columns in an Airtable airtable?
3. Anything else that I am missing in the description re: acceptance criteria for the FE?
4. Are we using Airtable for this, so that certain people will have line of sight into the data? If yes, this would be another great use case for that forms & tables discussion we were having in Slack.

cc: @ashtemp

[kylemh]

Instead of making this just about Tree House licenses, perhaps it could be our scholarship application page? I envision a drop-down representing all the available scholarships/resources one can sign up with.

Regardless, our prior discussion was relating to administrative tools, so this would be slightly different. Luckily, whatever we do here can be used there.

I presume the following data will get sent to the back-end from such a form:

Slackname (String) Actual name (String) Email (String)

[AshTemp]

Treehouse is the only scholarship we have right now....The idea is good tho.

Sent from my iPad

On Apr 1, 2018, at 12:52 AM, Kyle Holmberg [email protected] wrote:

Instead of making this just about Tree House licenses, perhaps it could be our scholarship application page? I envision a drop-down representing all the available scholarships/resources one can sign up with.

Regardless, our prior discussion was relating to administrative tools, so this would be slightly different. Luckily, whatever we do here can be used there.

I presume the following data will get sent to the back-end from such a form:

Name (String) Branch (String or Number - your choice)

Anything else would be up to @AshTemp

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[hpjaj]

@kylemh - You're right, I did use the admin dashboard as the example, but actually I was more broadly thinking exactly this. Forms & tables, with varied access. Be that "admin" access, or "verified user" access, or "board member" access...whatever we choose. We can create any roles we choose.

But for this example let's say it is for ID.me verified users.

• These verified users can access this form on the frontend
• When they submit the form, the changes are saved to our db (not Airtable)
• The FE has a table that displays the data from the db, that only user's with xyz permissions can see. And we can set that level of access to whatever we choose.

I think we should go this route for all the benefits I mentioned in my thoughts around forms & tables for software devs.

I also think that since we have this as an option, I would prefer spending our time and resources on investing in and building out our application, versus deepening our dependency on a third party service such as Airtable.

You down?

[AshTemp]

Whoa, wait a minute. We are using airtable for a multitude of reasons. The big ones being the mentors can publicly see who still needs a mentor. Others include the fact that the bot can not only read the requests but also write to the table to include who is mentoring an individual. So unless you’re going to also include Allen in this discussion to find out what needs to happen so that the bot still works don’t make too many plans to not use airtable. We’ve already automated a huge part of requesting and fulfilling a mentor, let’s not go backwards.

Sent from my iPad

On Apr 1, 2018, at 12:00 PM, Harry Levine [email protected] wrote:

@kylemh - You're right, I did use the admin dashboard as the example, but actually I was more broadly thinking exactly this. Forms & tables, with varied access. Be that access "admin" access, or "verified user" access, or "board member" access...whatever we choose. We can create any roles we choose.

But for this example let's say it is for ID.me verified users.

These verified users can access this form on the frontend When they submit the form, the changes are saved to our db (not Airtable) The FE has a table that displays the data from the db, that only user's with xyz permissions can see. And we can set that level of access to whatever we choose. I think we should go this route for all the benefits I mentioned in my thoughts around forms & tables for software devs.

I also think that since we have this as an option, I would prefer spending our time and resources on investing in and building out our application, versus deepening our dependency on a third party service such as Airtable.

You down?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[hpjaj]

Right, this is not for mentors or the mentor process. This is for Team Treehouse (or scholarship applications).

[AshTemp]

Oh, would still need a quick searchable way to find that and teamtree house is basically going to be a spreadsheet so airtable is perfect for that.

Sent from my iPad

On Apr 1, 2018, at 2:26 PM, Harry Levine [email protected] wrote:

Right, this is not for mentors or the mentor process. This is for Team Treehouse (or scholarship applications).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[hpjaj]

Airtable is one option. What I am describing accomplishes the same end goal, with many additional benefits for our contributors and for the OC.

[AshTemp]

Before we make big changes you need to talk with Nell.

Sent from my iPad

On Apr 1, 2018, at 2:35 PM, Harry Levine [email protected] wrote:

Airtable is one option. What I am describing accomplishes the same end goal, with many additional benefits.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[hpjaj]

Agreed! @nellshamrell was part of my original discussion on the topic.

I just implemented the concept of "roles" in PR https://github.com/OperationCode/operationcode_backend/pull/290. This, in conjunction with Pundit, provides varied access to forms, links, tables, etc.

But for sure, @nellshamrell can you pls share your thoughts?

[nellshamrell]

Reading through the backscroll now :)

[nellshamrell]

Here are my thoughts:

I think everyone (including me) is in agreement that the mentorship process should stay in Airtable.

What I'm hearing here, though, is that we'd like to use our own database to track scholarship information (starting with Tree House). I believe this would not alter any current behavior - this is entirely new behavior. Is this correct? Or do we currently track scholarship information in Airtable (I know we did at one point, I don't know if we do now)?

If we do not, then I think we should go forward with the plan to have it in our own database. The reason is I think this will provide more learning opportunities for new developers to our open source projects - creating forms and views that create, display, and manipulate data is a great beginning coding project.

[AshTemp]

I am tracking exactly 1 entry in airtable at the moment, the other scholarship stuff I'm handling in Google forms so nothing will be affected.

On Fri, May 11, 2018 at 10:07 PM Nell Shamrell-Harrington < [email protected]> wrote:

Here are my thoughts:

I think everyone (including me) is in agreement that the mentorship process should stay in Airtable.

What I'm hearing here, though, is that we'd like to use our own database to track scholarship information (starting with Tree House). I believe this would not alter any current behavior - this is entirely new behavior. Is this correct? Or do we currently track scholarship information in Airtable (I know we did at one point, I don't know if we do now)?

If we do not, then I think we should go forward with the plan to have it in our own database. The reason is I think this will provide more learning opportunities for new developers to our open source projects - creating forms and views that create, display, and manipulate data is a great beginning coding project.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OperationCode/operationcode_backend/issues/288#issuecomment-388522870, or mute the thread https://github.com/notifications/unsubscribe-auth/AS35GO6wGEz2sB2jRkPawUf52b_eBhBIks5txkPigaJpZM4TCnYY .

[dmarchante]

@AshTemp @nellshamrell can we revisit the direction we want this to go? Are we still looking to move away from AirTable, and track this ourselves?

[dmarchante]

@AshTemp @nellshamrell @hollomancer @JennWeideman We need to have a discussion around this as I think we need a db for a variety of reason not just scholarships, and we will have to update the original issue as well.