New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API-Level Integration #196

Open
MisterJames opened this Issue Apr 16, 2016 · 94 comments

Comments

Projects
None yet
7 participants
@MisterJames

MisterJames commented Apr 16, 2016

Hello all,

I'm a contributor on another open source project used by the Red Cross (AllReady) and I'm looking for some information regarding integration with the API.

For certain regions, we are looking to either receive a post-back when a new smoke alarm is detected (preferred) or periodically poll an end point to "pick up" new requests. Any information that you might have would be greatly appreciated.

We are implementing a web hook approach on our site for implementation of such communication, so it would be trivial for us to expose a URI and give you a token to use as part of the post-back, should that work for you. Perhaps this is something that could be registered with a list of cities, states, or geo-coded info of some kind such that only requests for the designated areas are presented to our end point.

If you don't have direct support for this type of integration, we can also use services such as IFTTT or Zapier and consume events from those providers.

Contacts that I am working with:

  • Red Cross: Jim McGowan
  • Humanitarian Toolbox: Tony Surma

Looking forward to working with you folks!

Cheers.

@OhMcGoo

This comment has been minimized.

Show comment
Hide comment
@OhMcGoo

OhMcGoo Apr 16, 2016

Member

@MisterJames, @kfogel and @cecilia-donnelly: I'll facilitate introductions here. James Chambers is more than a contributor to allReady. As a volunteer and project leader, he is one of the main drivers of allReady's success to date. The fact that he works from Manitoba, Canada only adds to his allure! Karl Fogel and Cecilia Donnelly are 2/3 of Open Tech Strategies, great folks here in Chicago who have served as my "digital sherpas" as we venture into the world of OSS. Virtual handshakes all around. So happy to have you all connected!

Member

OhMcGoo commented Apr 16, 2016

@MisterJames, @kfogel and @cecilia-donnelly: I'll facilitate introductions here. James Chambers is more than a contributor to allReady. As a volunteer and project leader, he is one of the main drivers of allReady's success to date. The fact that he works from Manitoba, Canada only adds to his allure! Karl Fogel and Cecilia Donnelly are 2/3 of Open Tech Strategies, great folks here in Chicago who have served as my "digital sherpas" as we venture into the world of OSS. Virtual handshakes all around. So happy to have you all connected!

@kfogel

This comment has been minimized.

Show comment
Hide comment
@kfogel

kfogel Apr 18, 2016

Contributor

Hey, @MisterJames. Looking forward to working with you too! This all sounds technically straightforward; I'll be able to send a more substantive response tomorrow (am about to head out tonight), but don't anticipate any problems.

(virtual handshake)

Contributor

kfogel commented Apr 18, 2016

Hey, @MisterJames. Looking forward to working with you too! This all sounds technically straightforward; I'll be able to send a more substantive response tomorrow (am about to head out tonight), but don't anticipate any problems.

(virtual handshake)

@cecilia-donnelly

This comment has been minimized.

Show comment
Hide comment
@cecilia-donnelly

cecilia-donnelly Apr 19, 2016

Contributor

Hey @MisterJames,
Thanks for reaching out! What you're describing sounds very reasonable. Just to make sure we're on the same page, I'm imagining a workflow as follows:

  1. We receive a request for a smoke alarm.

  2. We store it in our db, as usual, and also POST it to you, along with an authorization token that you've provided to us. We're using HTTPS, by the way, and presumably you are too.

    • You mention limiting the requests sent to AllReady by some kind of geographical info. We assign each new request to a Red Cross region, so could easily limit the requests we send to AllReady to only include those in active regions (i.e., regions currently using the portal to accept smoke alarm installation requests).

    • The fields we store for each request are:

      name, // the name of the person requesting the alarm
      address, // their address
      assigned_rc_region, // the Red Cross region associated with their zip code
      city,
      state,
      zip,
      phone,
      email,
      serial, // our unique identifier: Red Cross region code - 2-digit fiscal year - integer
      status // currently: new, in progress, installed, or canceled
      

      Which of these fields would you like to receive? All of them? The serial field can be used as a key back into our database, in case as a future enhancement we want to send updates to AllReady about the request -- e.g. whenever the status changes.

    \3. You POST back some confirmation code to an endpoint that we make available. We then store that code along with the request.

    Is that consistent with what you were thinking?

Contributor

cecilia-donnelly commented Apr 19, 2016

Hey @MisterJames,
Thanks for reaching out! What you're describing sounds very reasonable. Just to make sure we're on the same page, I'm imagining a workflow as follows:

  1. We receive a request for a smoke alarm.

  2. We store it in our db, as usual, and also POST it to you, along with an authorization token that you've provided to us. We're using HTTPS, by the way, and presumably you are too.

    • You mention limiting the requests sent to AllReady by some kind of geographical info. We assign each new request to a Red Cross region, so could easily limit the requests we send to AllReady to only include those in active regions (i.e., regions currently using the portal to accept smoke alarm installation requests).

    • The fields we store for each request are:

      name, // the name of the person requesting the alarm
      address, // their address
      assigned_rc_region, // the Red Cross region associated with their zip code
      city,
      state,
      zip,
      phone,
      email,
      serial, // our unique identifier: Red Cross region code - 2-digit fiscal year - integer
      status // currently: new, in progress, installed, or canceled
      

      Which of these fields would you like to receive? All of them? The serial field can be used as a key back into our database, in case as a future enhancement we want to send updates to AllReady about the request -- e.g. whenever the status changes.

    \3. You POST back some confirmation code to an endpoint that we make available. We then store that code along with the request.

    Is that consistent with what you were thinking?

@MisterJames

This comment has been minimized.

Show comment
Hide comment
@MisterJames

MisterJames Apr 23, 2016

@cecilia-donnelly Yes, that sounds pretty much in line. Thanks for this detail.

For regions:

  • Can I assume this is the list of currently supported regions?
  • Is there an API endpoint I can call to get the list of regions (perhaps with last mod date or something to help with sync) rather than hard-coding?

I think we will need to introduce the concept of associated region (or some kind of org identification) in our model. This would allow us to test if we support it. I think we would return a HTTP 202 for your post, but then we'd need to let you know somehow that we weren't covering that region.

In instances where we are going to service the request, what status should we send you back? It would seem that the status list you have is fine, but perhaps if there were a flag on the request (third_party_tracked or something) we could set that to true and maintain the status for you as they are currently defined. Thus, an endpoint where we could post a status would be suffice (because we could send the tracking flag, and the status). Here are some ideas of how that might work:

  • We 202 a request out of our region: We send you back a false with the status of new
  • We 202 a request in region: We POST you a true with status of new
  • A volunteer is assigned an installation: We POST a true with status of in progress
  • A user requests a cancellation: We POST a true with status canceled
  • A volunteer marks an installation as complete: We POST back true with status installed

Does that jive? Perhaps @OhMcGoo has some thoughts here as well for how the tasks/installs/statuses might align.

I'm not involved in the deployment process, but I will make sure with our folks that we're on HTTPS before we start exchanging data. Would you also have an auth token for your endpoints that we should use? We can exchange that off-thread of course ;) 👯

Cheers!

MisterJames commented Apr 23, 2016

@cecilia-donnelly Yes, that sounds pretty much in line. Thanks for this detail.

For regions:

  • Can I assume this is the list of currently supported regions?
  • Is there an API endpoint I can call to get the list of regions (perhaps with last mod date or something to help with sync) rather than hard-coding?

I think we will need to introduce the concept of associated region (or some kind of org identification) in our model. This would allow us to test if we support it. I think we would return a HTTP 202 for your post, but then we'd need to let you know somehow that we weren't covering that region.

In instances where we are going to service the request, what status should we send you back? It would seem that the status list you have is fine, but perhaps if there were a flag on the request (third_party_tracked or something) we could set that to true and maintain the status for you as they are currently defined. Thus, an endpoint where we could post a status would be suffice (because we could send the tracking flag, and the status). Here are some ideas of how that might work:

  • We 202 a request out of our region: We send you back a false with the status of new
  • We 202 a request in region: We POST you a true with status of new
  • A volunteer is assigned an installation: We POST a true with status of in progress
  • A user requests a cancellation: We POST a true with status canceled
  • A volunteer marks an installation as complete: We POST back true with status installed

Does that jive? Perhaps @OhMcGoo has some thoughts here as well for how the tasks/installs/statuses might align.

I'm not involved in the deployment process, but I will make sure with our folks that we're on HTTPS before we start exchanging data. Would you also have an auth token for your endpoints that we should use? We can exchange that off-thread of course ;) 👯

Cheers!

@MisterJames

This comment has been minimized.

Show comment
Hide comment
@MisterJames

MisterJames Apr 30, 2016

Hey folks! Just checking in to see if there is any progress, or if we should perhaps set up a quick call sometime this week to help move this one along. Have a great weekend! cc/ @cecilia-donnelly @OhMcGoo

MisterJames commented Apr 30, 2016

Hey folks! Just checking in to see if there is any progress, or if we should perhaps set up a quick call sometime this week to help move this one along. Have a great weekend! cc/ @cecilia-donnelly @OhMcGoo

@kfogel

This comment has been minimized.

Show comment
Hide comment
@kfogel

kfogel May 4, 2016

Contributor

Hey, @MisterJames. Sorry for the delay; we're doing some prioritization with @OhMcGoo (a few different features in this project, and one other project entirely). That's why you haven't heard back yet. We will try to get this all sorted out with Jim as soon as we can and make this happen. The technical plan as outlined above looks pretty darned sane to me.

Yes, you found the list of supported Red Cross regions (though I would recommend using this live link so that you always have the most up-to-date version of the file). However, your suggestion that we just add an API to provide the supported regions, with effective date provided, is the right solution. We don't have that API yet, but could certainly add it.

Yes, we'd give you an auth token(s) via secure channel, that you would use to authenticate to our API.

For the list of statuses that you send back, we might (?) want to add one more:

  • The installation is actually scheduled: We (meaning allReady) POST a true with status of scheduled

I'd like to get implementing this. We just need to do some planning with Jim to get this on the front burner. Watch this space for more.

Contributor

kfogel commented May 4, 2016

Hey, @MisterJames. Sorry for the delay; we're doing some prioritization with @OhMcGoo (a few different features in this project, and one other project entirely). That's why you haven't heard back yet. We will try to get this all sorted out with Jim as soon as we can and make this happen. The technical plan as outlined above looks pretty darned sane to me.

Yes, you found the list of supported Red Cross regions (though I would recommend using this live link so that you always have the most up-to-date version of the file). However, your suggestion that we just add an API to provide the supported regions, with effective date provided, is the right solution. We don't have that API yet, but could certainly add it.

Yes, we'd give you an auth token(s) via secure channel, that you would use to authenticate to our API.

For the list of statuses that you send back, we might (?) want to add one more:

  • The installation is actually scheduled: We (meaning allReady) POST a true with status of scheduled

I'd like to get implementing this. We just need to do some planning with Jim to get this on the front burner. Watch this space for more.

@cecilia-donnelly

This comment has been minimized.

Show comment
Hide comment
@cecilia-donnelly

cecilia-donnelly May 6, 2016

Contributor

Hey @MisterJames. We've talked to @OhMcGoo and will start work on this next week. #202 is especially time-sensitive and so we'll get started on that first, but expect to see movement in this ticket in the next few days. I imagine we'll have more questions for you as we go -- thanks for getting us going on this.

Contributor

cecilia-donnelly commented May 6, 2016

Hey @MisterJames. We've talked to @OhMcGoo and will start work on this next week. #202 is especially time-sensitive and so we'll get started on that first, but expect to see movement in this ticket in the next few days. I imagine we'll have more questions for you as we go -- thanks for getting us going on this.

@cecilia-donnelly

This comment has been minimized.

Show comment
Hide comment
@cecilia-donnelly

cecilia-donnelly May 12, 2016

Contributor

Hey @MisterJames and @OhMcGoo -- I'm starting on this today, now that I've done some work on #202. I'll ping here if I run across problems/questions.

Contributor

cecilia-donnelly commented May 12, 2016

Hey @MisterJames and @OhMcGoo -- I'm starting on this today, now that I've done some work on #202. I'll ping here if I run across problems/questions.

cecilia-donnelly pushed a commit that referenced this issue May 12, 2016

cecilia-donnelly
Add endpoint to get active regions: #196
As requested by @MisterJames, add an endpoint for requesting all the
current active regions.  I've just included a placeholder for auth here.
Update the API routes list with the others we'll need for integration
with AllReady.

Structure responses in accordance with the [Google Style
Guide](https://google.github.io/styleguide/jsoncstyleguide.xml).

cecilia-donnelly pushed a commit that referenced this issue May 12, 2016

cecilia-donnelly
Update request status from AllReady: #196
Accept a POST request from AllReady that confirms that they're tracking
a request and/or updates the status of that request.

cecilia-donnelly pushed a commit that referenced this issue May 12, 2016

cecilia-donnelly
Send new request to external endpoint: #196
As requested by @MisterJames, we can now send a new request to some
external endpoint (which will be determined in the config file).  I need
to check whether the request is in an active region first and *then*
send it.  I should also not try to do this if no external endpoint has
been chosen.  This is an intermediate step, in other words.  Once I
clean up those loose ends I still need to add proper auth.
@MisterJames

This comment has been minimized.

Show comment
Hide comment
@MisterJames

MisterJames May 14, 2016

Nice! Thanks for the effort here...I'll try to work through my end as expediently as possible so we can start getting these bits chatting.

MisterJames commented May 14, 2016

Nice! Thanks for the effort here...I'll try to work through my end as expediently as possible so we can start getting these bits chatting.

cecilia-donnelly pushed a commit that referenced this issue May 25, 2016

cecilia-donnelly
Send request only for active regions: #196
Also, only try to send the request if an external endpoint has been
defined, so that an instance of this app that doesn't want to send new
requests elsewhere can simply leave the external_endpoint as null in
their config file.

cecilia-donnelly pushed a commit that referenced this issue May 25, 2016

cecilia-donnelly
Check whether incoming POST is authenticated: #196
Store auth tokens for external servers that should have permission to
update status in our database.  Only accept POST requests that have a
valid token.

cecilia-donnelly pushed a commit that referenced this issue May 25, 2016

cecilia-donnelly
Send a token with our outbound POSTs: #196
Store both inbound and outbound tokens.  Send a token to the external
server along with our POSTs.
@kfogel

This comment has been minimized.

Show comment
Hide comment
@kfogel

kfogel Jun 6, 2016

Contributor

Hey, @MisterJames. Let us know when you've got some people working on the corresponding endpoints on the AllReady side -- we're continuing to test here, and looking at tweaking a few aspects of the API design, but we're certainly ready for those conversations and even ready to hit endpoints as soon as they're up.

Contributor

kfogel commented Jun 6, 2016

Hey, @MisterJames. Let us know when you've got some people working on the corresponding endpoints on the AllReady side -- we're continuing to test here, and looking at tweaking a few aspects of the API design, but we're certainly ready for those conversations and even ready to hit endpoints as soon as they're up.

cecilia-donnelly pushed a commit that referenced this issue Jun 6, 2016

cecilia-donnelly
Add documentation on how to test this branch: #196
Until we have a real external endpoint to test against, follow these
instructions to test the API portions of this app.

Also, add notes resulting from @kfogel's review of this codebase.

cecilia-donnelly pushed a commit that referenced this issue Jul 26, 2016

cecilia-donnelly
Small changes/comments resulting from code review
Respond to some of @kfogel's comments in the #196 branch.  More to
follow.
@cecilia-donnelly

This comment has been minimized.

Show comment
Hide comment
@cecilia-donnelly

cecilia-donnelly Aug 6, 2016

Contributor

@tonysurma points out that AllReady wants to avoid having Red Cross business logic in their app as much as possible. He suggests that instead of sending the Red Cross-specific region with the request, AllReady may give us several different tokens, one per region. AllReady would process requests by token, instead of sorting them by region. This way, they could handle all tokens from all external clients the same way, instead of having a particular section of code to sort requests across regions.

Note that the following work has been done on the AllReady side (from conversation in a Slack channel):

@stevejgordon: A lot of the initial work was done by @MisterJames - Check out PR's #802, #964, #966 and #990
stevejgordon: I'm currently working on some code for listing requests for a particular event and following that probably some code to allow manual entry/editing of the requests. Probably won't overlap too much with any API work.
stevejgordon: We have a request status enum as well and would expect any new requests to be in the unassigned status initially.
@seanepping: I am currently looking at Issue #1055
stevejgordon: The idea is then that an organizer can assign those requests into an itinerary. Ah okay, that sounds great. I shouldn't need to change the request object in anything I'm working on so hopefully no merge conflicts later on.

Based on further conversations with them, we probably want to:

  1. Get multiple tokens from them, one per region. Would these be static?
  2. Send the correct token with our request, based on the region it is in. This might have something to do with #207 -- in my mind, the more tokens we have the more it makes sense to keep them in the database. Thoughts, @kfogel?
Contributor

cecilia-donnelly commented Aug 6, 2016

@tonysurma points out that AllReady wants to avoid having Red Cross business logic in their app as much as possible. He suggests that instead of sending the Red Cross-specific region with the request, AllReady may give us several different tokens, one per region. AllReady would process requests by token, instead of sorting them by region. This way, they could handle all tokens from all external clients the same way, instead of having a particular section of code to sort requests across regions.

Note that the following work has been done on the AllReady side (from conversation in a Slack channel):

@stevejgordon: A lot of the initial work was done by @MisterJames - Check out PR's #802, #964, #966 and #990
stevejgordon: I'm currently working on some code for listing requests for a particular event and following that probably some code to allow manual entry/editing of the requests. Probably won't overlap too much with any API work.
stevejgordon: We have a request status enum as well and would expect any new requests to be in the unassigned status initially.
@seanepping: I am currently looking at Issue #1055
stevejgordon: The idea is then that an organizer can assign those requests into an itinerary. Ah okay, that sounds great. I shouldn't need to change the request object in anything I'm working on so hopefully no merge conflicts later on.

Based on further conversations with them, we probably want to:

  1. Get multiple tokens from them, one per region. Would these be static?
  2. Send the correct token with our request, based on the region it is in. This might have something to do with #207 -- in my mind, the more tokens we have the more it makes sense to keep them in the database. Thoughts, @kfogel?

cecilia-donnelly pushed a commit that referenced this issue Aug 6, 2016

cecilia-donnelly
Refactor some integration code for #196
Update status of requests in just one function, instead of POSTing to an
internal endpoint from our server.  Address a couple TODOs about POSTing
to the external server.

cecilia-donnelly pushed a commit that referenced this issue Oct 4, 2016

cecilia-donnelly
Change expected shape of req.body for #196
The request body was coming in as malformed JSON.  This addresses that,
but now if the request comes in properly it'll break.  In other words,
things are fragile.  This works for certain curl calls like:

    $ curl -H "application/json" -X POST -d [JSON data here] [SERVER /
    URL]/admin/requests/status/[SERIAL NUMBER]

After we do some testing I expect to change this again.
@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy Nov 4, 2016

@cecilia-donnelly cc @kfogel @MisterJames

I've been taking up the work on the AllReady side for some parts of this integration. I had a lot of questions on the AllReady side, but after finding this, it sounds like a good amount of my questions have been answered. I'd just like to confirm a couple things:

  • it sounds like each incoming request will have a unique identifier, the serial column. Above is an example: "serial, // our unique identifier: Red Cross region code - 2-digit fiscal year - integer". Am I correct to assume that this will individually identify each and every request you sent to us? The only time we should every receive the same serial value more than once is the case where we're processing a status update, correct?
  • i'm making the assumption that once a region code is assigned, it never changes, as it's part of what makes up your field for the unique identifier per request.
  • do we return the serial value to you with our reply so you can correlate back to your system? In other words, what do you need back, the entire message, or the serial with the status codes/http responses?
  • it sounds like these are the possible four "statuses" you can send us: new, in progress, installed, or canceled. we can map these statuses to our internal AllReady statuses.
  • how is the auth token given to getasmokealarm.org? Is this something our system provides to you via code/endpoint, or is it a auth token we give to you by some other means?
  • do you know if any headway was made on supplying a token per region?
  • sounds like we have yet to reply to your request with the updated status/httpcode as well as testing out the API/auth token code, correct?

Sorry if some of this is already known, but I did just pick this up a while ago, so any details you can provide me with the questions above should help me write the correct code on AllReady's side as well as break down our Issues for this integration into more granular chunks so we can prioritize them.

Thanks!

mgmccarthy commented Nov 4, 2016

@cecilia-donnelly cc @kfogel @MisterJames

I've been taking up the work on the AllReady side for some parts of this integration. I had a lot of questions on the AllReady side, but after finding this, it sounds like a good amount of my questions have been answered. I'd just like to confirm a couple things:

  • it sounds like each incoming request will have a unique identifier, the serial column. Above is an example: "serial, // our unique identifier: Red Cross region code - 2-digit fiscal year - integer". Am I correct to assume that this will individually identify each and every request you sent to us? The only time we should every receive the same serial value more than once is the case where we're processing a status update, correct?
  • i'm making the assumption that once a region code is assigned, it never changes, as it's part of what makes up your field for the unique identifier per request.
  • do we return the serial value to you with our reply so you can correlate back to your system? In other words, what do you need back, the entire message, or the serial with the status codes/http responses?
  • it sounds like these are the possible four "statuses" you can send us: new, in progress, installed, or canceled. we can map these statuses to our internal AllReady statuses.
  • how is the auth token given to getasmokealarm.org? Is this something our system provides to you via code/endpoint, or is it a auth token we give to you by some other means?
  • do you know if any headway was made on supplying a token per region?
  • sounds like we have yet to reply to your request with the updated status/httpcode as well as testing out the API/auth token code, correct?

Sorry if some of this is already known, but I did just pick this up a while ago, so any details you can provide me with the questions above should help me write the correct code on AllReady's side as well as break down our Issues for this integration into more granular chunks so we can prioritize them.

Thanks!

@cecilia-donnelly

This comment has been minimized.

Show comment
Hide comment
@cecilia-donnelly

cecilia-donnelly Nov 7, 2016

Contributor

Hi and welcome, Mike! (@mgmccarthy)

  • it sounds like each incoming request will have a unique identifier, the serial column. Above is an example: "serial, // our unique identifier: Red Cross region code - 2-digit fiscal year - integer". Am I correct to assume that this will individually identify each and every request you sent to us? The only time we should every receive the same serial value more than once is the case where we're processing a status update, correct?

Yes, exactly.

  • i'm making the assumption that once a region code is assigned, it never changes, as it's part of what makes up your field for the unique identifier per request.

Yes, we're making that assumption too. It's possible that the regions might change in the future, of course, but each request will be assigned to the region corresponding to the requester's address when the request is received.

  • do we return the serial value to you with our reply so you can correlate back to your system? In other words, what do you need back, the entire message, or the serial with the status codes/http responses?

Yes, we need the serial number back. @MisterJames' comment here #196 (comment) suggests that you'd send the serial, the status, and a boolean indicating whether or not the request will be tracked in AllReady.

  • it sounds like these are the possible four "statuses" you can send us: new, in progress, installed, or canceled. we can map these statuses to our internal AllReady statuses.

Yes, though we aren't yet enforcing those statuses on our end. If some different or expanded set would be better for you, let us know!

  • how is the auth token given to getasmokealarm.org? Is this something our system provides to you via code/endpoint, or is it a auth token we give to you by some other means?

I think this is up to you.

  • do you know if any headway was made on supplying a token per region?

Not as far as I know.

  • sounds like we have yet to reply to your request with the updated status/httpcode as well as testing out the API/auth token code, correct?

Right. I wrote up some docs for the incoming endpoint here: https://github.com/redcross/smoke-alarm-portal/blob/196-api-integration/docs/API.md, in case you haven't seen those.

I'm glad to hear that you're picking this up. Let me know if you need more detail or have other questions!

Contributor

cecilia-donnelly commented Nov 7, 2016

Hi and welcome, Mike! (@mgmccarthy)

  • it sounds like each incoming request will have a unique identifier, the serial column. Above is an example: "serial, // our unique identifier: Red Cross region code - 2-digit fiscal year - integer". Am I correct to assume that this will individually identify each and every request you sent to us? The only time we should every receive the same serial value more than once is the case where we're processing a status update, correct?

Yes, exactly.

  • i'm making the assumption that once a region code is assigned, it never changes, as it's part of what makes up your field for the unique identifier per request.

Yes, we're making that assumption too. It's possible that the regions might change in the future, of course, but each request will be assigned to the region corresponding to the requester's address when the request is received.

  • do we return the serial value to you with our reply so you can correlate back to your system? In other words, what do you need back, the entire message, or the serial with the status codes/http responses?

Yes, we need the serial number back. @MisterJames' comment here #196 (comment) suggests that you'd send the serial, the status, and a boolean indicating whether or not the request will be tracked in AllReady.

  • it sounds like these are the possible four "statuses" you can send us: new, in progress, installed, or canceled. we can map these statuses to our internal AllReady statuses.

Yes, though we aren't yet enforcing those statuses on our end. If some different or expanded set would be better for you, let us know!

  • how is the auth token given to getasmokealarm.org? Is this something our system provides to you via code/endpoint, or is it a auth token we give to you by some other means?

I think this is up to you.

  • do you know if any headway was made on supplying a token per region?

Not as far as I know.

  • sounds like we have yet to reply to your request with the updated status/httpcode as well as testing out the API/auth token code, correct?

Right. I wrote up some docs for the incoming endpoint here: https://github.com/redcross/smoke-alarm-portal/blob/196-api-integration/docs/API.md, in case you haven't seen those.

I'm glad to hear that you're picking this up. Let me know if you need more detail or have other questions!

@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy Nov 7, 2016

@cecilia-donnelly, thanks so much! Right away, with the information you gave me, I have some changes to make to my initial take on this integration.

I'll talk with @MisterJames about the auth token. I believe something has been written on our end, but I might now know about it yet.

mgmccarthy commented Nov 7, 2016

@cecilia-donnelly, thanks so much! Right away, with the information you gave me, I have some changes to make to my initial take on this integration.

I'll talk with @MisterJames about the auth token. I believe something has been written on our end, but I might now know about it yet.

@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy Nov 7, 2016

@cecilia-donnelly I have a couple more questions for you.

I understand getting a request from you that has a status of "new", but I'm not too sure how your system gets updated to the other three statuses? When the request comes into your site, and you persist it, what actions occur through your site that would change the status of those requests? Do all request updates get funneled back through your API and allReady just needs to track the current status in the context of what our application does?

For example, in this case, a smoke alarm install. Eventually, someone is going to show up and install a smoke alarm somewhere. When the installer finished the job, do they mark the install complete through your site? Or does your site just allow the updating of a status via the API, and allReady tracks that type of information?

mgmccarthy commented Nov 7, 2016

@cecilia-donnelly I have a couple more questions for you.

I understand getting a request from you that has a status of "new", but I'm not too sure how your system gets updated to the other three statuses? When the request comes into your site, and you persist it, what actions occur through your site that would change the status of those requests? Do all request updates get funneled back through your API and allReady just needs to track the current status in the context of what our application does?

For example, in this case, a smoke alarm install. Eventually, someone is going to show up and install a smoke alarm somewhere. When the installer finished the job, do they mark the install complete through your site? Or does your site just allow the updating of a status via the API, and allReady tracks that type of information?

@cecilia-donnelly

This comment has been minimized.

Show comment
Hide comment
@cecilia-donnelly

cecilia-donnelly Nov 7, 2016

Contributor

That's a great question. Currently, users can update the request status on our site but we don't have anything set up to send those updates to AllReady. Let's finish sending requests to you first and then add these updates.

Our site does allow a status update via API from AllReady.

Maybe @OhMcGoo wants to chime in on this. Do you anticipate users updating request status through AllReady, the smoke alarm portal, or both?

Contributor

cecilia-donnelly commented Nov 7, 2016

That's a great question. Currently, users can update the request status on our site but we don't have anything set up to send those updates to AllReady. Let's finish sending requests to you first and then add these updates.

Our site does allow a status update via API from AllReady.

Maybe @OhMcGoo wants to chime in on this. Do you anticipate users updating request status through AllReady, the smoke alarm portal, or both?

@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy Nov 8, 2016

@cecilia-donnelly

Currently, users can update the request status on our site but we don't have anything set up to send those updates to AllReady

Since allReady will be tracking the status of the request internally (if we accept the request), I'm assuming that any request updates once in our system would be funneled back through your API to update the status of the request on your side.

If we do anticipate having to update statuses that we initially received from you, and we're trying to figure out what updates to send back to you, this could get a little confusing.

It sounds like you will receive status updates from your users about smoke alarm install, but who is the "user" doing the updating in this case? Is it the volunteers installing the smoke alarm, or, for example, the resident(s) of the home that initally requested the smoke alarm via your portal?

I'm asking this b/c allReady's job is to coordinate the right volunteer(s) with the right skills on the correct day for the install... and our site is built to track that information. So... I'm thinking that once we receive a new request from you, we either would not want to process status updates for those requests, but rather, report status updates from our system (driven by volunteers) to your side via your API.

It would be good to get a little feedback here from @OhMcGoo cc @MisterJames

mgmccarthy commented Nov 8, 2016

@cecilia-donnelly

Currently, users can update the request status on our site but we don't have anything set up to send those updates to AllReady

Since allReady will be tracking the status of the request internally (if we accept the request), I'm assuming that any request updates once in our system would be funneled back through your API to update the status of the request on your side.

If we do anticipate having to update statuses that we initially received from you, and we're trying to figure out what updates to send back to you, this could get a little confusing.

It sounds like you will receive status updates from your users about smoke alarm install, but who is the "user" doing the updating in this case? Is it the volunteers installing the smoke alarm, or, for example, the resident(s) of the home that initally requested the smoke alarm via your portal?

I'm asking this b/c allReady's job is to coordinate the right volunteer(s) with the right skills on the correct day for the install... and our site is built to track that information. So... I'm thinking that once we receive a new request from you, we either would not want to process status updates for those requests, but rather, report status updates from our system (driven by volunteers) to your side via your API.

It would be good to get a little feedback here from @OhMcGoo cc @MisterJames

@stevejgordon

This comment has been minimized.

Show comment
Hide comment
@stevejgordon

stevejgordon Nov 8, 2016

@mgmccarthy I've just spotted this. I'm a bit weighed up with work (so not read it all properly yet). I do have an API spec @MisterJames forwarded from @cecilia-donnelly describing how allReady can call to getasmokealarm to update statuses. I was going to look at creating a little service/handler for that which will fire when a request status changes at our end.

I did probably have some questions but don't have the email in front of me at the moment

stevejgordon commented Nov 8, 2016

@mgmccarthy I've just spotted this. I'm a bit weighed up with work (so not read it all properly yet). I do have an API spec @MisterJames forwarded from @cecilia-donnelly describing how allReady can call to getasmokealarm to update statuses. I was going to look at creating a little service/handler for that which will fire when a request status changes at our end.

I did probably have some questions but don't have the email in front of me at the moment

@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy Nov 8, 2016

thanks for weighing in @stevejgordon. You can also refer this link for how to send update to getasmokealarm's API: https://github.com/redcross/smoke-alarm-portal/blob/196-api-integration/docs/API.md.

if you have something more concrete, can you share it with me on Slack?

Also, these questions I'm asking are not because I don't understand the API part of what we're building here, but rather, do we need to/want to update our internal statuses as a result of a request we receive from getasmokealarm that is not "new"?

Changing our internal Request status is not as simple as just updating a field, but rather, there are db updates involved and command/notifications we dispatch based on the Request status changing, basically, we have a workflow in place.

What I'm looking for here is the "source of truth". Does allReady just process the "new" requests from getasmokealarm and then publish out when our requests changes to getasmokealarm's API? If that's the case, then this is easy and makes sense.

However, if we need to handle updates from getasmokealarm (for instance, they send us a request update with "in progress"), and then make sure allReady is updated appropriately, it's not as simple. Also, in this example, would we even need to publish an update out to their API b/c we received the status change from them and not from something in allReady?

mgmccarthy commented Nov 8, 2016

thanks for weighing in @stevejgordon. You can also refer this link for how to send update to getasmokealarm's API: https://github.com/redcross/smoke-alarm-portal/blob/196-api-integration/docs/API.md.

if you have something more concrete, can you share it with me on Slack?

Also, these questions I'm asking are not because I don't understand the API part of what we're building here, but rather, do we need to/want to update our internal statuses as a result of a request we receive from getasmokealarm that is not "new"?

Changing our internal Request status is not as simple as just updating a field, but rather, there are db updates involved and command/notifications we dispatch based on the Request status changing, basically, we have a workflow in place.

What I'm looking for here is the "source of truth". Does allReady just process the "new" requests from getasmokealarm and then publish out when our requests changes to getasmokealarm's API? If that's the case, then this is easy and makes sense.

However, if we need to handle updates from getasmokealarm (for instance, they send us a request update with "in progress"), and then make sure allReady is updated appropriately, it's not as simple. Also, in this example, would we even need to publish an update out to their API b/c we received the status change from them and not from something in allReady?

@stevejgordon

This comment has been minimized.

Show comment
Hide comment
@stevejgordon

stevejgordon Nov 8, 2016

@mgmccarthy Agreed, if we need to keep in sync with changes from getasmokealarm after the initial request creation it will be much more complex.

My original impression was that once in allReady we would own the status and update back. getasmokealarm would be mainly the portal to accept the initial requests. Like you, I agree we need to confirm the requirements/expectation.

stevejgordon commented Nov 8, 2016

@mgmccarthy Agreed, if we need to keep in sync with changes from getasmokealarm after the initial request creation it will be much more complex.

My original impression was that once in allReady we would own the status and update back. getasmokealarm would be mainly the portal to accept the initial requests. Like you, I agree we need to confirm the requirements/expectation.

@cecilia-donnelly

This comment has been minimized.

Show comment
Hide comment
@cecilia-donnelly

cecilia-donnelly Nov 8, 2016

Contributor

What I'm looking for here is the "source of truth". Does allReady just process the "new" requests from getasmokealarm and then publish out when our requests changes to getasmokealarm's API? If that's the case, then this is easy and makes sense.

This is the simplest way forward in my opinion. It's best to just have one master, as @mgmccarthy says. @OhMcGoo, is that how you imagined this working? @kfogel, want to chime in?

Contributor

cecilia-donnelly commented Nov 8, 2016

What I'm looking for here is the "source of truth". Does allReady just process the "new" requests from getasmokealarm and then publish out when our requests changes to getasmokealarm's API? If that's the case, then this is easy and makes sense.

This is the simplest way forward in my opinion. It's best to just have one master, as @mgmccarthy says. @OhMcGoo, is that how you imagined this working? @kfogel, want to chime in?

@cecilia-donnelly

This comment has been minimized.

Show comment
Hide comment
@cecilia-donnelly

cecilia-donnelly Nov 14, 2016

Contributor

Hey @mgmccarthy, @stevejgordon, @MisterJames how's it going? Do you need anything else from me at the moment?

Contributor

cecilia-donnelly commented Nov 14, 2016

Hey @mgmccarthy, @stevejgordon, @MisterJames how's it going? Do you need anything else from me at the moment?

@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy Nov 15, 2016

@cecilia-donnelly, @stevejgordon and I still need to talk to @MisterJames about how we're accepting status updates (allready/portal/both) and what that means to our systems trying coordinate tracking the "status" of a request.

mgmccarthy commented Nov 15, 2016

@cecilia-donnelly, @stevejgordon and I still need to talk to @MisterJames about how we're accepting status updates (allready/portal/both) and what that means to our systems trying coordinate tracking the "status" of a request.

@MisterJames

This comment has been minimized.

Show comment
Hide comment
@MisterJames

MisterJames Nov 19, 2016

So, after a few internal and cross-team conversations I'd just like to sum up our understanding and, as @mgmccarthy said, we can get this over the finish line!

@cecilia-donnelly thanks for your patience and continued efforts here, much appreciated!

Here's what we believe to be true:

  • The DB backing getasmokealarm.org is the master of record
  • Ownership of a record can transition from getasmokealarm.org to AllReady
  • Whichever application is the "owner" is the only one that we expect to update statuses
  • Ownership transitions happen when a "new" request is submitted to AllReady and AllReady services the region of the request
  • There is no way for AllReady to transition ownership back to getasmokealarm.org
  • Once ownership is accepted, AllReady is responsible for updating the master of record through the getasmokealarm.org API

Cecilia, if you're good with that and it matched @OhMcGoo's expectations, I think the code pieces can fall in line pretty quickly.

MisterJames commented Nov 19, 2016

So, after a few internal and cross-team conversations I'd just like to sum up our understanding and, as @mgmccarthy said, we can get this over the finish line!

@cecilia-donnelly thanks for your patience and continued efforts here, much appreciated!

Here's what we believe to be true:

  • The DB backing getasmokealarm.org is the master of record
  • Ownership of a record can transition from getasmokealarm.org to AllReady
  • Whichever application is the "owner" is the only one that we expect to update statuses
  • Ownership transitions happen when a "new" request is submitted to AllReady and AllReady services the region of the request
  • There is no way for AllReady to transition ownership back to getasmokealarm.org
  • Once ownership is accepted, AllReady is responsible for updating the master of record through the getasmokealarm.org API

Cecilia, if you're good with that and it matched @OhMcGoo's expectations, I think the code pieces can fall in line pretty quickly.

@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy Dec 18, 2016

cc @tonysurma

@cecilia-donnelly, question on updating status back to you.

Right now, you have the following possible statuses for smoke alarm requests:
new, in progress, installed, or canceled

We've already built the code that accepts a request with a status of new from GASA and sends you the update with a status of new and an acceptance of true when we can service the request.

I'm assuming you expect those same statuses sent back to you when we would update the status of a request in our system after we've agreed to service the request?

That being the case, our statuses don't align one-to-one with yours. So, here is what I think the "mapping" is going to be:

AllReady     GASA
---------    ------
Assigned  -> in progress
Completed -> installed
Canceled  -> canceled

mgmccarthy commented Dec 18, 2016

cc @tonysurma

@cecilia-donnelly, question on updating status back to you.

Right now, you have the following possible statuses for smoke alarm requests:
new, in progress, installed, or canceled

We've already built the code that accepts a request with a status of new from GASA and sends you the update with a status of new and an acceptance of true when we can service the request.

I'm assuming you expect those same statuses sent back to you when we would update the status of a request in our system after we've agreed to service the request?

That being the case, our statuses don't align one-to-one with yours. So, here is what I think the "mapping" is going to be:

AllReady     GASA
---------    ------
Assigned  -> in progress
Completed -> installed
Canceled  -> canceled
@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy Dec 18, 2016

cc @tonysurma

@cecilia-donnelly another question for you. In our system, it's possible for a Request to be Assigned (in progress), then changed back to Unassigned again (which is the initial state of all Requests, so Gasa status of new).

My guess is we allow this in case the installer doesn't get a chance to get to the install on the day of the install, and it's the last day of the Event... so any Requests they didn't get to go back to the drawing board.

In this case, what would we report back to GASA? My guess is:
status = new, acceptance = true?

we are still tacking the request we agreed to service, but the request is no longer doing anything until it can be assigned to another Itinerary in our system.

Thanks

mgmccarthy commented Dec 18, 2016

cc @tonysurma

@cecilia-donnelly another question for you. In our system, it's possible for a Request to be Assigned (in progress), then changed back to Unassigned again (which is the initial state of all Requests, so Gasa status of new).

My guess is we allow this in case the installer doesn't get a chance to get to the install on the day of the install, and it's the last day of the Event... so any Requests they didn't get to go back to the drawing board.

In this case, what would we report back to GASA? My guess is:
status = new, acceptance = true?

we are still tacking the request we agreed to service, but the request is no longer doing anything until it can be assigned to another Itinerary in our system.

Thanks

@cecilia-donnelly

This comment has been minimized.

Show comment
Hide comment
@cecilia-donnelly

cecilia-donnelly Dec 19, 2016

Contributor

Hey @mgmccarthy, thanks for the updates!

I'm assuming you expect those same statuses sent back to you when we would update the status of a request in our system after we've agreed to service the request?

Yes! Those preliminary mappings seem sensible to me.

In our system, it's possible for a Request to be Assigned (in progress), then changed back to Unassigned again (which is the initial state of all Requests, so Gasa status of new).

In this case, what would we report back to GASA? My guess is:
status = new, acceptance = true?

That sounds right to me. We don't have any rules saying that a request can only move from new, not back to it, so going from in progress back to new shouldn't present a problem.

Contributor

cecilia-donnelly commented Dec 19, 2016

Hey @mgmccarthy, thanks for the updates!

I'm assuming you expect those same statuses sent back to you when we would update the status of a request in our system after we've agreed to service the request?

Yes! Those preliminary mappings seem sensible to me.

In our system, it's possible for a Request to be Assigned (in progress), then changed back to Unassigned again (which is the initial state of all Requests, so Gasa status of new).

In this case, what would we report back to GASA? My guess is:
status = new, acceptance = true?

That sounds right to me. We don't have any rules saying that a request can only move from new, not back to it, so going from in progress back to new shouldn't present a problem.

@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy Jan 3, 2017

@cecilia-donnelly, first off, I hope you had a nice holiday and a good new year..

I have a quick question for you. For the Requests you're sending us, have you already validated that the phone number on the Request is a valid mobile number or are you not validating the phone number in any way?

Thanks

mgmccarthy commented Jan 3, 2017

@cecilia-donnelly, first off, I hope you had a nice holiday and a good new year..

I have a quick question for you. For the Requests you're sending us, have you already validated that the phone number on the Request is a valid mobile number or are you not validating the phone number in any way?

Thanks

@cecilia-donnelly

This comment has been minimized.

Show comment
Hide comment
@cecilia-donnelly

cecilia-donnelly Jan 4, 2017

Contributor

Hi @mgmccarthy! Happy new year back atcha.

We validate that the phone number is 10 digits in layout.jade. I believe the validation is based on something in the jQuery Validation Engine codebase.

We don't, however, do anything to make sure that the 10 digits entered are a working mobile number.

Contributor

cecilia-donnelly commented Jan 4, 2017

Hi @mgmccarthy! Happy new year back atcha.

We validate that the phone number is 10 digits in layout.jade. I believe the validation is based on something in the jQuery Validation Engine codebase.

We don't, however, do anything to make sure that the 10 digits entered are a working mobile number.

@cecilia-donnelly

This comment has been minimized.

Show comment
Hide comment
@cecilia-donnelly

cecilia-donnelly Jan 5, 2017

Contributor

@mgmccarthy I'm getting a 502 error when I POST to the endpoint you gave in this comment. Is it still up? Is there a different endpoint I should use?

Thanks!

Contributor

cecilia-donnelly commented Jan 5, 2017

@mgmccarthy I'm getting a 502 error when I POST to the endpoint you gave in this comment. Is it still up? Is there a different endpoint I should use?

Thanks!

cecilia-donnelly pushed a commit that referenced this issue Jan 5, 2017

cecilia-donnelly
Adjust POST to external server for #196
Send the information that the external service expects for each
submitted request.  Note that some work remains to handle errors and
non-standard responses from allReady.
@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy Jan 5, 2017

it should still be up and and it is the endpoint you should use. I don't have access to the production server, so I won't be able to troubleshoot.

cc @tonysurma

Most likely it's a change to the controller (endpoint) and/or the command were sending to do the processing.

Let me look into it

mgmccarthy commented Jan 5, 2017

it should still be up and and it is the endpoint you should use. I don't have access to the production server, so I won't be able to troubleshoot.

cc @tonysurma

Most likely it's a change to the controller (endpoint) and/or the command were sending to do the processing.

Let me look into it

@cecilia-donnelly

This comment has been minimized.

Show comment
Hide comment
@cecilia-donnelly

cecilia-donnelly Jan 5, 2017

Contributor

Thanks for the quick response @mgmccarthy!

Contributor

cecilia-donnelly commented Jan 5, 2017

Thanks for the quick response @mgmccarthy!

@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy Jan 5, 2017

@cecilia-donnelly, I just ran all the latest code locally, and it works.

I'm assuming this could be related to something different in the live environment. I just sent you an email asking you to send me the json you're trying to send to our endpoint so I can run it locally.

Thanks

mgmccarthy commented Jan 5, 2017

@cecilia-donnelly, I just ran all the latest code locally, and it works.

I'm assuming this could be related to something different in the live environment. I just sent you an email asking you to send me the json you're trying to send to our endpoint so I can run it locally.

Thanks

@cecilia-donnelly

This comment has been minimized.

Show comment
Hide comment
@cecilia-donnelly

cecilia-donnelly Jan 5, 2017

Contributor

@mgmccarthy, I didn't get an email from you (?), but I sent you the body of the JSON I was sending to the endpoint (via Postman), and the full error I got in response.

Contributor

cecilia-donnelly commented Jan 5, 2017

@mgmccarthy, I didn't get an email from you (?), but I sent you the body of the JSON I was sending to the endpoint (via Postman), and the full error I got in response.

@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy Jan 5, 2017

@cecilia-donnelly I did get an email to you... it looks like the entire website is down for some reason right now... so I doubt this is a code/config problem with the endpoint.

mgmccarthy commented Jan 5, 2017

@cecilia-donnelly I did get an email to you... it looks like the entire website is down for some reason right now... so I doubt this is a code/config problem with the endpoint.

@cecilia-donnelly

This comment has been minimized.

Show comment
Hide comment
@cecilia-donnelly

cecilia-donnelly Jan 5, 2017

Contributor

@mgmccarthy thanks for the update!

(Sorry to spam this issue with server config questions, everyone.)

Contributor

cecilia-donnelly commented Jan 5, 2017

@mgmccarthy thanks for the update!

(Sorry to spam this issue with server config questions, everyone.)

@tonysurma

This comment has been minimized.

Show comment
Hide comment
@tonysurma

tonysurma Jan 5, 2017

I am looking into it

tonysurma commented Jan 5, 2017

I am looking into it

@cecilia-donnelly

This comment has been minimized.

Show comment
Hide comment
@cecilia-donnelly

cecilia-donnelly Jan 6, 2017

Contributor

@mgmccarthy, it sounds like allReady requires both email and phone, where the smoke alarm portal only requires that at least one of those fields be completed. We can send an "n/a" or similar for a blank field coming from our user. Does that sound right to you?

Contributor

cecilia-donnelly commented Jan 6, 2017

@mgmccarthy, it sounds like allReady requires both email and phone, where the smoke alarm portal only requires that at least one of those fields be completed. We can send an "n/a" or similar for a blank field coming from our user. Does that sound right to you?

@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy Jan 6, 2017

@cecilia-donnelly, this is correct. The reason being that AllReady will choose which communication method to use for requestors based on the specifics of a given integration.

For our v1 launch, we are only supporting communicating back to requestors via sms message for now. Communicating back to requestors via email is something we will implement post-v1.

That being said, since we don't support email yet, I'm imaging we could "relax" the validation around email in our system.

The problem here is once we've written that information into our system, and if we then want to support communicating to requestors via email, then we have a bunch of requests in our system which cannot do that.

not too sure what the answer is here. I'm thinking for now, we'll just continue returning a 400 to your call if email address is misisng and/or invalid.

@tonysurma @stevejgordon, thoughts?

mgmccarthy commented Jan 6, 2017

@cecilia-donnelly, this is correct. The reason being that AllReady will choose which communication method to use for requestors based on the specifics of a given integration.

For our v1 launch, we are only supporting communicating back to requestors via sms message for now. Communicating back to requestors via email is something we will implement post-v1.

That being said, since we don't support email yet, I'm imaging we could "relax" the validation around email in our system.

The problem here is once we've written that information into our system, and if we then want to support communicating to requestors via email, then we have a bunch of requests in our system which cannot do that.

not too sure what the answer is here. I'm thinking for now, we'll just continue returning a 400 to your call if email address is misisng and/or invalid.

@tonysurma @stevejgordon, thoughts?

@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy Jan 6, 2017

@cecilia-donnelly, I should also mention that we most likely for v1 will be validating that the incoming phone number we get from GASA is a mobile number. If it's not a mobile number, we'll most likely return a 400 at the point of the call or communicate back to your endpoint an acceptance of false.

mgmccarthy commented Jan 6, 2017

@cecilia-donnelly, I should also mention that we most likely for v1 will be validating that the incoming phone number we get from GASA is a mobile number. If it's not a mobile number, we'll most likely return a 400 at the point of the call or communicate back to your endpoint an acceptance of false.

@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy Jan 7, 2017

@cecilia-donnelly, looks like we're back up and running. I had messed up an entity framework migration and brought the live site down ☹️

mgmccarthy commented Jan 7, 2017

@cecilia-donnelly, looks like we're back up and running. I had messed up an entity framework migration and brought the live site down ☹️

@kfogel

This comment has been minimized.

Show comment
Hide comment
@kfogel

kfogel Jan 8, 2017

Contributor

Whups -- been there, yeah :-).

@mgmccarthy, just FYI @cecilia-donnelly will be afk until Tuesday, possibly Wednesday -- so if there's a delay in substantive response (as opposed to my non-substantive one here!), that's why.

Contributor

kfogel commented Jan 8, 2017

Whups -- been there, yeah :-).

@mgmccarthy, just FYI @cecilia-donnelly will be afk until Tuesday, possibly Wednesday -- so if there's a delay in substantive response (as opposed to my non-substantive one here!), that's why.

@cecilia-donnelly

This comment has been minimized.

Show comment
Hide comment
@cecilia-donnelly

cecilia-donnelly Jan 10, 2017

Contributor

@mgmccarthy thanks for the update! I sent a couple test requests and it looks good from here. 👍 More soon!

Contributor

cecilia-donnelly commented Jan 10, 2017

@mgmccarthy thanks for the update! I sent a couple test requests and it looks good from here. 👍 More soon!

@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy Jan 11, 2017

@cecilia-donnelly, do you by any chance have the ability to send us a country code?

mgmccarthy commented Jan 11, 2017

@cecilia-donnelly, do you by any chance have the ability to send us a country code?

@cecilia-donnelly

This comment has been minimized.

Show comment
Hide comment
@cecilia-donnelly

cecilia-donnelly Jan 11, 2017

Contributor

@mgmccarthy do you mean a country code for the phone number? We assume all phone numbers coming in through the Smoke Alarm Portal are US numbers, so the country code would always be "1".

Contributor

cecilia-donnelly commented Jan 11, 2017

@mgmccarthy do you mean a country code for the phone number? We assume all phone numbers coming in through the Smoke Alarm Portal are US numbers, so the country code would always be "1".

@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy Jan 12, 2017

@cecilia-donnelly thanks for that clarification...

cc @stevejgordon

right now, in our system, if wee don't have a country code available, we assume "US"

mgmccarthy commented Jan 12, 2017

@cecilia-donnelly thanks for that clarification...

cc @stevejgordon

right now, in our system, if wee don't have a country code available, we assume "US"

@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy Jan 20, 2017

@cecilia-donnelly, just an FYI if you try to invoke our API:

We've finally fixed the problem with user-generated tokens not being recognized on post-back to our system. What this means is two things:

  1. the route/path to the API has changed
  2. I need to provide you with a user and a token that you will attach to your http headers in order for your request to be properly authorized by AllReady

When the PR is merged, I'll create a user for GASA in the AllReady live environment, then generate a token for you. I'll then email you the information.

Thanks

mgmccarthy commented Jan 20, 2017

@cecilia-donnelly, just an FYI if you try to invoke our API:

We've finally fixed the problem with user-generated tokens not being recognized on post-back to our system. What this means is two things:

  1. the route/path to the API has changed
  2. I need to provide you with a user and a token that you will attach to your http headers in order for your request to be properly authorized by AllReady

When the PR is merged, I'll create a user for GASA in the AllReady live environment, then generate a token for you. I'll then email you the information.

Thanks

@cecilia-donnelly

This comment has been minimized.

Show comment
Hide comment
@cecilia-donnelly

cecilia-donnelly Jan 27, 2017

Contributor

@mgmccarthy fantastic! Thanks for the heads up. I'll keep an eye out for the token.

Contributor

cecilia-donnelly commented Jan 27, 2017

@mgmccarthy fantastic! Thanks for the heads up. I'll keep an eye out for the token.

@cecilia-donnelly

This comment has been minimized.

Show comment
Hide comment
@cecilia-donnelly

cecilia-donnelly Apr 21, 2017

Contributor

Hey @mgmccarthy, checking back on this. Were you able to get your PR merged? What's the new route to the API?

Contributor

cecilia-donnelly commented Apr 21, 2017

Hey @mgmccarthy, checking back on this. Were you able to get your PR merged? What's the new route to the API?

@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy Apr 23, 2017

@cecilia-donnelly, I've been out of the loop for awhile with the AllReady project. The PR was merged a while ago.

When creating a user, we're going to need an email address/mobile phone number, and both will need to be verified. If there is a GASA email and a mobile phone number you would like to use, you can register with the site here: http://allready-d.azurewebsites.net/Account/Register

then verify both email/mobile number (I don't think you HAVE to verify a mobile number, it's optional)... once that's done, I can log in as a site admin and generate the token for you and email you the info.

Thanks!

mgmccarthy commented Apr 23, 2017

@cecilia-donnelly, I've been out of the loop for awhile with the AllReady project. The PR was merged a while ago.

When creating a user, we're going to need an email address/mobile phone number, and both will need to be verified. If there is a GASA email and a mobile phone number you would like to use, you can register with the site here: http://allready-d.azurewebsites.net/Account/Register

then verify both email/mobile number (I don't think you HAVE to verify a mobile number, it's optional)... once that's done, I can log in as a site admin and generate the token for you and email you the info.

Thanks!

@cecilia-donnelly

This comment has been minimized.

Show comment
Hide comment
@cecilia-donnelly

cecilia-donnelly Apr 24, 2017

Contributor

@mgmccarthy thanks for the quick response! I created a "Get a Smoke Alarm" account on allReady. Let me know if you need any more from me to generate the token.

Contributor

cecilia-donnelly commented Apr 24, 2017

@mgmccarthy thanks for the quick response! I created a "Get a Smoke Alarm" account on allReady. Let me know if you need any more from me to generate the token.

@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy Apr 24, 2017

@cecilia-donnelly just sent you an email with your token and the path to our API

mgmccarthy commented Apr 24, 2017

@cecilia-donnelly just sent you an email with your token and the path to our API

@cecilia-donnelly

This comment has been minimized.

Show comment
Hide comment
@cecilia-donnelly

cecilia-donnelly May 11, 2017

Contributor

@mgmccarthy, thanks for all your help with this!

I'm now sending the following request using Postman:

POST to http://allready-d.azurewebsites.net/api/request

Body:

{ "ProviderRequestId": "MINN-17-00123",
  "ProviderData": "MINN",
  "Status": "new",
  "Name": "Cecilia Donnelly",
  "Address": "5300 S Pleasant Ave",
  "City": "Minneapolis",
  "State": "Minnesota",
  "Zip": "55404",
  "Phone": "444-555-3534",
  "Email": "" }

Headers:

Content-Type:application/json
ApiUser:__Registered_Email_Address__
ApiKey:__API_Key__

Instead of getting a 202 response with values for status and acceptance, I get a 200 response with the AllReady Login page. Presumably I'm doing something wrong -- maybe the body values it expects are different now? Any ideas? (The address and phone number are made up -- could that be a problem?)

Contributor

cecilia-donnelly commented May 11, 2017

@mgmccarthy, thanks for all your help with this!

I'm now sending the following request using Postman:

POST to http://allready-d.azurewebsites.net/api/request

Body:

{ "ProviderRequestId": "MINN-17-00123",
  "ProviderData": "MINN",
  "Status": "new",
  "Name": "Cecilia Donnelly",
  "Address": "5300 S Pleasant Ave",
  "City": "Minneapolis",
  "State": "Minnesota",
  "Zip": "55404",
  "Phone": "444-555-3534",
  "Email": "" }

Headers:

Content-Type:application/json
ApiUser:__Registered_Email_Address__
ApiKey:__API_Key__

Instead of getting a 202 response with values for status and acceptance, I get a 200 response with the AllReady Login page. Presumably I'm doing something wrong -- maybe the body values it expects are different now? Any ideas? (The address and phone number are made up -- could that be a problem?)

@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy May 11, 2017

@cecilia-donnelly Email is a required field. If you fill that out, does it work?

If that is the problem, that means we're not handling the failure of the request properly, b/c you're still getting a 200 and being redirected to our home page... that doesn't sound right

mgmccarthy commented May 11, 2017

@cecilia-donnelly Email is a required field. If you fill that out, does it work?

If that is the problem, that means we're not handling the failure of the request properly, b/c you're still getting a 200 and being redirected to our home page... that doesn't sound right

@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy May 11, 2017

Also, is the phone number from a mobile phone?

mgmccarthy commented May 11, 2017

Also, is the phone number from a mobile phone?

@cecilia-donnelly

This comment has been minimized.

Show comment
Hide comment
@cecilia-donnelly

cecilia-donnelly May 11, 2017

Contributor

@mgmccarthy I just tried it with email filled in (test@example.com) and a real mobile phone number, and no dice. (That phone number above is just made up.) Even with those changes, I still get a 200 and the home page. Can you see anything in your logs?

Contributor

cecilia-donnelly commented May 11, 2017

@mgmccarthy I just tried it with email filled in (test@example.com) and a real mobile phone number, and no dice. (That phone number above is just made up.) Even with those changes, I still get a 200 and the home page. Can you see anything in your logs?

@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy May 11, 2017

@cecilia-donnelly the problem is I don't have access to our production environment/and/logs.

Let me try to set everything up locally, and give it a shot. If it works locally, then there is some problem on production, and I'll have to get project owners involved to figure out what that is.

mgmccarthy commented May 11, 2017

@cecilia-donnelly the problem is I don't have access to our production environment/and/logs.

Let me try to set everything up locally, and give it a shot. If it works locally, then there is some problem on production, and I'll have to get project owners involved to figure out what that is.

@cecilia-donnelly

This comment has been minimized.

Show comment
Hide comment
@cecilia-donnelly

cecilia-donnelly May 11, 2017

Contributor

Thanks so much, @mgmccarthy! I'll take another look at it later with fresh eyes, in case it's something obvious and silly. (The fact that I'm getting some response makes me think I'm probably sending the request to the right place and so on, but still...)

Contributor

cecilia-donnelly commented May 11, 2017

Thanks so much, @mgmccarthy! I'll take another look at it later with fresh eyes, in case it's something obvious and silly. (The fact that I'm getting some response makes me think I'm probably sending the request to the right place and so on, but still...)

@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy May 11, 2017

@cecilia-donnelly I'm 95% sure it's a problem with our token-protected middleware... I'll take a look.

mgmccarthy commented May 11, 2017

@cecilia-donnelly I'm 95% sure it's a problem with our token-protected middleware... I'll take a look.

@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy May 11, 2017

@cecilia-donnelly it looks like there was an API change to the model we're expecting from you... instead of a field named Zip we're expecting a field named PostalCode.

try that change and let me know what you get.

mgmccarthy commented May 11, 2017

@cecilia-donnelly it looks like there was an API change to the model we're expecting from you... instead of a field named Zip we're expecting a field named PostalCode.

try that change and let me know what you get.

@cecilia-donnelly

This comment has been minimized.

Show comment
Hide comment
@cecilia-donnelly

cecilia-donnelly May 11, 2017

Contributor

No luck yet @mgmccarthy. :(

(To be clear, I tried sending PostalCode instead of Zip, with all other values being the same, and still got the Login page back.)

Contributor

cecilia-donnelly commented May 11, 2017

No luck yet @mgmccarthy. :(

(To be clear, I tried sending PostalCode instead of Zip, with all other values being the same, and still got the Login page back.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment