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

Receive request from smoke alarm portal #1055

Closed
cecilia-donnelly opened this Issue Aug 6, 2016 · 9 comments

Comments

Projects
None yet
5 participants
@cecilia-donnelly

cecilia-donnelly commented Aug 6, 2016

@MisterJames opened redcross/smoke-alarm-portal#196 in the "get a smoke alarm" repo, and this is the corresponding half of that work:

  1. An endpoint we can hit with each new smoke alarm request that comes in. This endpoint would receive a request object with these fields:
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  

and respond with a status and a boolean indicating whether or not AllReady will handle this request (see this comment for details).

  1. When the status of a request changes, you can post the new status to our /admin/requests/status/:id endpoint.
  2. You might want to hit our endpoint at /regions for the list of currently active regions.
@seanepping

This comment has been minimized.

Show comment
Hide comment
@seanepping

seanepping Aug 6, 2016

Contributor

@tonysurma I will take a look at this one

Contributor

seanepping commented Aug 6, 2016

@tonysurma I will take a look at this one

@seanepping

This comment has been minimized.

Show comment
Hide comment
@seanepping

seanepping Aug 6, 2016

Contributor

@tonysurma Summing up out conversation:

We want to move the latter part of the above description into a new story/issue

When the status of a request changes, you can post the new status to our /admin/requests/status/:id endpoint.

You might want to hit our endpoint at /regions for the list of currently active regions.

We also discussed that we need to have a way for a user, when registering for an api key, could add a status change endpoint. This would be a known status url that can be called when the status of the request changes and can be looked up internally.

Did I miss anything?

Contributor

seanepping commented Aug 6, 2016

@tonysurma Summing up out conversation:

We want to move the latter part of the above description into a new story/issue

When the status of a request changes, you can post the new status to our /admin/requests/status/:id endpoint.

You might want to hit our endpoint at /regions for the list of currently active regions.

We also discussed that we need to have a way for a user, when registering for an api key, could add a status change endpoint. This would be a known status url that can be called when the status of the request changes and can be looked up internally.

Did I miss anything?

@seanepping

This comment has been minimized.

Show comment
Hide comment
@seanepping

seanepping Aug 6, 2016

Contributor

--edit-- ProviderId already exists.

I will am thinking about how the id for the above status endpoint will be received as part of the request. I believe that it would be keyed off of the token itself, or some other id that is associated with the token.

Looking at #964, it is possible that an admin can manage this url in the same way they manage the api key.

Contributor

seanepping commented Aug 6, 2016

--edit-- ProviderId already exists.

I will am thinking about how the id for the above status endpoint will be received as part of the request. I believe that it would be keyed off of the token itself, or some other id that is associated with the token.

Looking at #964, it is possible that an admin can manage this url in the same way they manage the api key.

seanepping pushed a commit to seanepping/allReady that referenced this issue Aug 6, 2016

Sean Epping Sean Epping
Addresses Issue #1055 - External Request Endpoint
Added RequestApiController
Added Tests for controller
Added RequestViewModel
Added RequestCommand components
Added ExternalEndpointAttribute that can be used to avoid
AntoForgeryTokenChecking in tests

@tonysurma tonysurma closed this in #1068 Aug 7, 2016

tonysurma added a commit that referenced this issue Aug 7, 2016

Fixes #1055 - External Request Endpoint (#1068)
* Addresses Issue #1055 - External Request Endpoint
Added RequestApiController
Added Tests for controller
Added RequestViewModel
Added RequestCommand components
Added ExternalEndpointAttribute that can be used to avoid
AntoForgeryTokenChecking in tests

* Added Tests for AddRequestCommandHandler
Added IAllreadyDataaccess extensions for Requests
Refactored Request code into async and fixed tests

* Fixed call to add request to add when not created
Changed web.config to be what it was before tooling changes were made

* Added Lat and Long to View Model for Request
Updated it accordingly in the controller

@tonysurma tonysurma reopened this Aug 7, 2016

@tonysurma

This comment has been minimized.

Show comment
Hide comment
@tonysurma

tonysurma Aug 7, 2016

Member

Keeping this open so we can do further work as needed as well as validate this 'works' from the getamokearlarm side

Member

tonysurma commented Aug 7, 2016

Keeping this open so we can do further work as needed as well as validate this 'works' from the getamokearlarm side

@stevejgordon

This comment has been minimized.

Show comment
Hide comment
@stevejgordon

stevejgordon Oct 5, 2016

Member

@MisterJames We touched on maybe using IdentityServer4 for auth between APIs. Is this something we need to figure out for this milestone, or would a fixed token that can be generated (one per campaign) be enough at this point to allow us to start creating endpoints to accept requests?

It looks like we have an endpoint ready to accept requests.

Member

stevejgordon commented Oct 5, 2016

@MisterJames We touched on maybe using IdentityServer4 for auth between APIs. Is this something we need to figure out for this milestone, or would a fixed token that can be generated (one per campaign) be enough at this point to allow us to start creating endpoints to accept requests?

It looks like we have an endpoint ready to accept requests.

@tonysurma

This comment has been minimized.

Show comment
Hide comment
@tonysurma

tonysurma Nov 3, 2016

Member

@MisterJames can you help update where we are on this? cc @mgmccarthy

Member

tonysurma commented Nov 3, 2016

@MisterJames can you help update where we are on this? cc @mgmccarthy

@tonysurma tonysurma modified the milestones: November v0.11 Milestone, December v1.0 Release Milestone Nov 23, 2016

@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy Nov 30, 2016

Collaborator

@tonysurma please assign this to me

Collaborator

mgmccarthy commented Nov 30, 2016

@tonysurma please assign this to me

@tonysurma tonysurma assigned mgmccarthy and unassigned seanepping Nov 30, 2016

@tonysurma

This comment has been minimized.

Show comment
Hide comment
@tonysurma

tonysurma Dec 17, 2016

Member

@mgmccarthy do you feel we can close this for december milestone?

Member

tonysurma commented Dec 17, 2016

@mgmccarthy do you feel we can close this for december milestone?

@mgmccarthy

This comment has been minimized.

Show comment
Hide comment
@mgmccarthy

mgmccarthy Dec 18, 2016

Collaborator

@tonysurma, this part of this Issue is still not done:

When the status of a request changes, you can post the new status to our /admin/requests/status/:id endpoint.

what we have done is the initial request back to GASA's endpoint when we receive a new API Request.

As far as what statuses they expect us to update back to them on a request we've decided to service, I'm assuming it's one of these:
new, in progress, installed, or canceled

I'll check with the GASA folks using Issue #196

I'm working on a PR now for this. If you want, you can break this item into a separate Issue, or leave this one open. Thanks

Collaborator

mgmccarthy commented Dec 18, 2016

@tonysurma, this part of this Issue is still not done:

When the status of a request changes, you can post the new status to our /admin/requests/status/:id endpoint.

what we have done is the initial request back to GASA's endpoint when we receive a new API Request.

As far as what statuses they expect us to update back to them on a request we've decided to service, I'm assuming it's one of these:
new, in progress, installed, or canceled

I'll check with the GASA folks using Issue #196

I'm working on a PR now for this. If you want, you can break this item into a separate Issue, or leave this one open. Thanks

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