You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jun 10, 2019. It is now read-only.
Repository navigation
This repository was archived by the owner on Jun 10, 2019. It is now read-only.
While logged in and navigating directly to /mentor-request it redirects you to login page. This is due to a change I made that set the default to false. The only way to get to /mentor-request is to navigate from profile, which doesn't use the react mentor-request but uses the airtable form.
What is the expected behavior?
Use the site form only if logged in, preferably not use the airtable form directly but the backend api.
What steps did you take to get this behavior?
navigate to /mentor-request while logged in
One thing to note, when it redirects you, it does show the header in the logged in state.
@wimo7083 Is the OC back-end API actually set up to populate mentor requests to Airtable yet? I remember that last fall, it was not - which is also why we weren't using the React MentorRequest form component (which communicated w/ the OC back-end API). We were defaulting link navigation to the Airtable UI form because it was the only one that actually populated new Mentor Requests to Airtable.
Originally, this was thought to be a bug on the back-end, (not being able to populate Mentor requests to Airtable), but turns out, it was actually never a feature request: OperationCode/operationcode_backend#155
Good question. I wrote documentation for the supposed functionality.
And It looks like there's a route that allows you to send a request for the current user. But I don't know if this is hooked up.
I'm not sure where current_user.requests.create(requests_params) actually goes to.
But prior to me breaking the web request form, a different form appeared even if you weren't logged in. @hpjaj can you shed any light on if the backend is actually setup or if the current route is stubbed off?
To add to the problem. If you are logged out, and try to navigate to the link found in profile op.co.de/mentor-request by typing it into your navbar you can view the form even if you don't have an account.
If you take this publicly available link (if you have a profile account) and add a single char to the end you can view all mentor-request
@wimo7083 - That endpoint creates a new Request record in the database, derived from the passed in request_params. It does not ping Airtable's API.
For that, as @jjhampton said, we would need a new process and background job.
@nellshamrell@kylemh@jjhampton @wimo7083 - is that something we want? Before we move forward on this, can we please step back and outline exactly how we want the whole mentor request flow and experience to work?
I know that I changed something that made user flow less clear; in an effort to hide content that shouldn't be viewed unless authenticated. This brought up the fact that for a while there was an active route to do mentor requests in the frontend application, that doesn't actually process them.
Change ideas:
Simple revert and ignore the issue that there's still a way for authenticated and non-auth users to submit mentor requests that dissapear into void.
Remove our mentor request form on the front end and redirect route to airtable form (if authed).
Disable the airtable mentor request form. Only allow mentor requests from the front end profile page for authed and verified veterans. Implement the manner to handle the api request in backend.
Same as 3, but perform the request solely in the frontend. This means we have to store the api token somehow in the react app. I'm not versed enough to know if this is possible in a secure manner.
Keep things as they are now, and ignore the weird UX.
I don't have any preference for any one solution, I don't want to confuse new people.
@wimo7083 I think that for now, that route for the path /mentor-request could just be removed from the router file at home.js, since the MentorRequest component shouldn't be displayed to users anyway (since submitting it doesn't actually populate a mentor request). AFAIK there aren't any navigation links that point to that path in the app, and I don't see why a user would be compelled to load that route via URL. The 'Request a Mentor' link on the profile page already routes to the Airtables form, which currently works.
I'd prefer to re-evaluate the entire mentor request workflow/experience (as Harry suggests) before making any changes.
Activity
apex-omontgomery commentedon Jan 28, 2018
currently working on something for this, so we can move the mentor-request form behind the authenticated route component.
jjhampton commentedon Jan 28, 2018
@wimo7083 Is the OC back-end API actually set up to populate mentor requests to Airtable yet? I remember that last fall, it was not - which is also why we weren't using the React
MentorRequestform component (which communicated w/ the OC back-end API). We were defaulting link navigation to the Airtable UI form because it was the only one that actually populated new Mentor Requests to Airtable.Originally, this was thought to be a bug on the back-end, (not being able to populate Mentor requests to Airtable), but turns out, it was actually never a feature request: OperationCode/operationcode_backend#155
apex-omontgomery commentedon Jan 28, 2018
Good question. I wrote documentation for the supposed functionality.
And It looks like there's a route that allows you to send a request for the current user. But I don't know if this is hooked up.
I'm not sure where
current_user.requests.create(requests_params)actually goes to.But prior to me breaking the web request form, a different form appeared even if you weren't logged in.
@hpjaj can you shed any light on if the backend is actually setup or if the current route is stubbed off?
apex-omontgomery commentedon Jan 28, 2018
To add to the problem. If you are logged out, and try to navigate to the link found in profile
op.co.de/mentor-requestby typing it into your navbar you can view the form even if you don't have an account.If you take this publicly available link (if you have a profile account) and add a single char to the end you can view all mentor-request
hpjaj commentedon Jan 28, 2018
@wimo7083 - That endpoint creates a new
Requestrecord in the database, derived from the passed inrequest_params. It does not ping Airtable's API.For that, as @jjhampton said, we would need a new process and background job.
@nellshamrell @kylemh @jjhampton @wimo7083 - is that something we want? Before we move forward on this, can we please step back and outline exactly how we want the whole mentor request flow and experience to work?
apex-omontgomery commentedon Jan 28, 2018
I know that I changed something that made user flow less clear; in an effort to hide content that shouldn't be viewed unless authenticated. This brought up the fact that for a while there was an active route to do mentor requests in the frontend application, that doesn't actually process them.
Change ideas:
I don't have any preference for any one solution, I don't want to confuse new people.
jjhampton commentedon Jan 28, 2018
@wimo7083 I think that for now, that route for the path
/mentor-requestcould just be removed from the router file at home.js, since theMentorRequestcomponent shouldn't be displayed to users anyway (since submitting it doesn't actually populate a mentor request). AFAIK there aren't any navigation links that point to that path in the app, and I don't see why a user would be compelled to load that route via URL. The 'Request a Mentor' link on the profile page already routes to the Airtables form, which currently works.I'd prefer to re-evaluate the entire mentor request workflow/experience (as Harry suggests) before making any changes.
apex-omontgomery commentedon Jan 29, 2018
PR to remove route submitted. We can leave this issue open to discuss further plans if there's a desire or we can close.