I think for the diaper bank project we set up rubocop to run after your specs are run (and all passing). Should we set that up here? I forget to run rubocop sometimes, so it's nice to have it run automatically. 😄

This came in from a partner, via a diaperbank:

My inventory items to sync with PartnerBase so that partners don't have to sort through items we don't carry when ordering.

I've clarified to the diaperbank that the intent here is to allow Partners to request items that they need so that the diaperbank is aware of the demand.

That said, it might be useful to pull down the inventory total summaries (or maybe just "yes"/"no") so that the Partners can be aware -- they could then filter to have it only show items that are available, and know when they're wishlisting an item? Might be good to ask some Partners how they'd like to do this.

We spiked out a lot of functionality and consequently didn't include many tests. We'd love any help if people are interested!

Expand the RSpec suite.

Push up a PR mentioning (but not closing / fixing, unless it really does finish the issue) this issue, then check off the ones you've done.

Configuration

• Remove explicit references to FactoryBot (eg. FactoryBot.build(...))
• Replace --require spec_helper with --require rails_helper in /.rspec

Models

partner_request_spec.rb

• it disallows an item attribute if the quantity isn't set
• "make name required" is actually checking "email" field (tweak example title)
• it has a proof of partner status attachment
• it has a proof of form 990 attachment
• it can have one or more documents attached
• approve_me changes the partner_status
• approve_me posts to the target DiaperBank (will need to stub the request)

Services

diaper_bank_client_spec.rb

These need additional tests, but it will be hard to test them without the guard clause stopping non-Prod

• post_request prepares a Post object
• post_request sets the X-Api-Key

Controllers

The "requires authentication" specs can probably be a shared example.

partner_requests_controller_spec.rb

• :index is invalid without authentication
• :new is invalid without authentication
• :create is invalid without authentication
• :show is invalid without authentication

api_controller_spec.rb

Should this be marked as an abstract class?

partners_controller_spec.rb

• :index is invalid without authentication

• :new is invalid without authentication

• :create is invalid without authentication

• :show is invalid without authentication

• :edit is invalid without authentication

• :update is invalid without authentication

• :approve is invalid without authentication

• :destroy is invalid without authentication

• :index is successful

• :show is successful

• :new is successful

• :edit is successful

• :approve is successful (be sure to stub the post from DiaperBankClient)

• :create is successful via HTML

• :create is successful via JSON

• :update is successful via HTML

• :update is successful via JSON

static_controller_spec.rb

• :index is successful
• :page is successful (you'll have to get creative with this one)

API

partners_controller_spec.rb

• :create returns :forbidden if the API key is invalid
• :create is successful
• :update returns :forbidden if the API key is invalid
• :update is successful
• :show returns :forbidden if the API key is invalid
• :show is successful

Features

TBA

Agency Type should be a drop-down menu that reflects NDBN (National Diaper Bank Network) standards. @armahillo Do you still have the list that Lynn from NDBN gave you? If not, let me know. Thanks!

I was working on some specs, and noticed an index spec commented out (in partners requests), which then led me to a comment in a file saying something like "maybe we should add admins".

Adding active admin would be a quick and easy way to handle admin tasks, at least in the beginning.

This is the confirmation email that partner agencies receive when they have submitted their diaper requests. The header should be changed; maybe to the first sentence of the email body: "Your diaper request has been approved."

Thank you, volunteers!

[LOYOLA]
This issue is to follow the VCR setup guide at https://relishapp.com/vcr/vcr/docs and commit all cassettes recorded by the current test suite.

Steps:

• Install VCR

• Run the test suite using bundle exec rspec

• Commit the relevant files

We spiked out a lot of features to get the app (as basic as it is) ready for the national diaper conference and probably didn't follow best practices. We'd love any PR's that clean things up, make them more reusable and so on.

referencing rubyforgood/human-essentials#630 where we added a new cannonical item for X-Small/Small Adult Briefs we just need to update the hash of POSSIBLE_ITEMS here too.

https://github.com/rubyforgood/partner/blob/master/config/initializers/01_constants.rb#L1

Pulled from a TODO in /app/services/partner_service.rb:

# TODO: Validation should not be skipped. Password should not be required when first creating a user

This may require adjustment of the Partner creation process, or a default secure password created that is emailed to the user.

With the great work done creating a page for partners to edit their details, we need a show page for them to review those details before submitting them for approval.

• Populate the app/views/partners/show.html.erb with the data entered in the edit/update form.
• Make the submit for approval button disabled if the partner_status is unequal to Pending

From a diaperbank:

The ability for partners to report demographics of who received diapers. I am including a link to the form of what our agencies submit now. They do one per person receiving diapers. Not at all ideal but this is the best I have had time to come up with. Feel free to enter one and choose Learning Connections as you agency so I know it is fake (they are no longer a partner I just haven't removed it)
Report form https://goo.gl/forms/r4SSEKaZmuKxzuJF2

For approving partners, we would like to share information about the them to the diaper app. This is done so that PII can be saved in the partner app and only fetched when necessary to approve the partner in the diaper app.

Once the partner has requested to be approved, A diaper app admin will see the request and can approve it. This api call will be made by the diaper app on that GET request (https://github.com/rubyforgood/diaper/blob/master/app/views/partners/approve_partner.html.erb)

Given the partner has filled out the partner details
When a request comes in at api/v1/partners/:diaper_partner_id
Then the api will respond with the partner details with the following information

Agency Information

• Name:
• Distributor Type
• Agency Type:
• Proof of Agency Status (Link)
• Agency Mission:
• Address
• Address
• City:
• State:
• Zip Code:

Media Information

• Website:
• Facebook:
• Twitter:

Agency Stability

• Founded
• Form 990:
• Form 990 Link
• Program Name
• Program Description
• Program Age
• Case Management:
• Evidence Based:
• Evidence Based Description:
• Program Client Improvement:
• Diaper Use:
• Other Diaper Use:
• Currently Provide Diapers:
• Turn Away Child Care:

Program Address

• Program Address:
• Program Address:
• Program City:
• Program State:
• Program Zip Code:

Organizational Capacity

• Max Serve
• Incorporate Plan:
• Responsible Staff Position:
• Storage Space:
• Storage Space Description:
• Trusted Pickup:

Population Served

• Income Requirement Description:
• Serve Income Circumstances:
• Income Verification:
• Internal DB:
• MAAC:

Ethnic Composition of Those Served

• African American:
• Caucasian:
• Hispanic:
• Asian:
• American Indian:
• Pacific Island:
• Multi-Racial:
• Other:

Zip Codes Served

• Zips:

Poverty Information of Those Served

• At FPL or Below:
• Above 1-2 times FPL:
• Greater 2 times FPL:
• Poverty Unknown:

Ages Served

• Ages:

Executive Director

• Executive Director Name:
• Executive Director Phone:
• Executive Director Email:

Program Contact Person

• Program Contact Name:
• Program Contact Phone:
• Program Contact Mobile:
• Program Contact Email:

Diaper Pick Up Person

• Pick Up Method:
• Pick Up Name:
• Pick Up Phone:
• Pick Up Email:

Agency Distribution Information

• Distribution Times:
• New Client Times:
• More Docs Required:

Sources of Funding

• Sources of Funding:
• Sources of Diapers:
• Diaper Budget:
• Diaper Funding Source:

I know Rails has some good security out-of-the-box, but there is a possibility of URL injection on the static#page action. For example /static/../../etc/passwd

This can be easiliy remedied enough -- vet that the requested parameter matches: /^[A-Za-z0-9_\-]+$/ (I think Rails / Rubocop prefers \A ... \z instead of ^ ... $ )

Some tests will be necessary.

• :page returns a 404 status if the file requested doesn't exist
• :page disallows any requested page that does not match ^[A-Za-z0-9_\-]+$

@pdxdiaperbank sez:

...the email itself: This is the view from the inbox. Can we remove: "This is a preheader text. Some clients will show this as a preview..." and change it to be something else? Maybe the first sentence in the body of the email?

There is some placeholder (preheader) text that is showing up in the e-mail preview:

@pdxdiaperbank sez:

This is the body of the email. I circled a couple spelling errors. The yellow highlighted portion is my question: Can the partner organization ALREADY submit their diaper requests through PartnerBase? If not, maybe it shouldn't state this yet?

The text in both cases is found in:

• /app/views/mailer/invitation_instructions.html.erb
• /app/views/mailer/invitation_instructions.text.erb

Criteria for Completion

• Preview text either removed or changed to a short notice about the contents of the email
• Spelling errors corrected

Until a partner has their partner_status set to Verified they should be restricted to partner routes (show/edit/update/etc.)

• Prevent unverified partners from accessing non-partner routes pages.
• Remove index action/route/page from partners.

In our partner.rb model we have an export_json method for sending information to the diaper app. This method was created before we had implemented active storage and the uploading of proof_of_partner_status, proof_of_form_990, and documents.

We need to add links to those files in the payload we are sending to the diaper app so the diaper banks can view them.

For bonus points, create a PR in the Diaper app that adds view links to these files they will now be receiving.

This issue is work remaining from #51.

Services

diaper_bank_client_spec.rb

These need additional tests, but it will be hard to test them without the guard clause stopping non-Prod

• post_request sets the X-Api-Key

Related to #75 and #90

We now restrict the user's selection of agency types to a defined list, but we need to also capture some description from the user when they select the "other" agency type.

Add an input that's hidden by default and displayed on "other" selection in the agency type dropdown menu.

A diaperbank requested the ability to specify "boy/girl" options for all base item types (this is handled, optionally, by the Diaperbanks themselves via Diaperbase, but we're intentionally using the base-item common language). I indicated to them that they should specify these things in the comments field of the request.

That said -- it sounds like this is maybe not completely intuitive to the Partners, so perhaps we could add a line item comment field for each item added to let them provide a short message?

From a diaperbank:

A place for partners to submit impact stories with an option to upload images. Collecting stories is important to us so we give them a place to submit them on our "agency portal" page on our website.

(This may or may not be in-scope for this project, but I said I would pass it along!)

We need a second type of request.

We need to allow for the requests by children -- a user based request where, rather than selecting a bulk number of diapers, they select the children who they are requesting diapers for in a given month and the system auto completes the request. For example, they have 10 kids who wear size 1 diapers, then the system will automatically request 500 size 1 diapers in the request since the diaper bank gives 50 size 1 per child.

We should have an active flag on each child and on the checklist of children all the children who are active are automatically set to request for.

@armahillo and @seanmarcia,

I feel like a missing component of the PartnerBase system is not being able to log in as an admin to see/edit what our clients (partner agencies) see... Is this something in the works already?

Thanks,
Rachel

We already have a partner user setup. We are using devise for authentication. The partner should be able to login and be redirected to a profile page where they are shown the following fields with their own information:

1. name
2. address
3. website
4. diaper_bank_id
5. diaper_partner_id
6. partner_status

Given a partner exists in the system
And has activated their account
When the partner goes to the home page
Then the partner sees the login form
And the partner can fill in the username and the password

Given the partner has an activated account
When the partner clicks login
Then the partner will be redirected to the home page
And the partner can edit and update their profile

This deals with registering a partner (user) through the diaper app. The process of registration happens when the diaper app sends a POST request to the /register endpoint as described below.

When The app receive a registration request on the /api/v1/register route
Then the system will create a new partner
And the system will email the partner with the registration link

The /register POST request includes the following payload:

{
organization_id: string,
partner_id: string,
email: string
}

Tests should be included that makes sure the registration link is sent. Docs on how to add rspec tests for action mailer is found here

1. https://relishapp.com/rspec/rspec-rails/docs/mailer-specs
2. https://www.lucascaton.com.br/2010/10/25/how-to-test-mailers-in-rails-with-rspec/

We would like our partners to fill out a form upon clicking the link they've received in their email (see issue #5). Once they've filled out the form, they can click Request for Approval on the form to send a request to the diaper app. For this issue, save the form information to the database.

Because of the size of this issue, we're adding a bounty to this.
You can find the design for the form below.

Some things necessary for acceptance:

1. Please include capybara tests to fill out the form and verify it all works
2. Please have active storage setup for file attachments. The file attachment fields are labelled as document attachment below.

The form includes the following fields(found in the partners table):

Agency Information

• Name:

Distributor Type

• Agency Type:
• Proof of Agency Status: (Document attachment)
• Agency Mission:
• Address
• Address
• City:
• State:
• Zip Code:

Media Information

• Website:
• Facebook:
• Twitter:

Agency Stability

• Founded
• Form 990: (Document Attachment)
• Program Name
• Program Description
• Program Age
• Case Management:
• Evidence Based:
• Evidence Based Description:
• Program Client Improvement:
• Diaper Use:
• Other Diaper Use:
• Currently Provide Diapers:
• Turn Away Child Care:

Program Address

• Program Address:
• Program Address:
• Program City:
• Program State:
• Program Zip Code:

Organizational Capacity

• Max Serve
• Incorporate Plan:
• Responsible Staff Position:
• Storage Space:
• Storage Space Description:
• Trusted Pickup:

Population Served

• Income Requirement Description:
• Serve Income Circumstances:
• Income Verification:
• Internal DB:
• MAAC:

Ethnic Composition of Those Served

• African American:
• Caucasian:
• Hispanic:
• Asian:
• American Indian:
• Pacific Island:
• Multi-Racial:
• Other:

Zip Codes Served

• Zips:

Poverty Information of Those Served

• At FPL or Below:
• Above 1-2 times FPL:
• Greater 2 times FPL:
• Poverty Unknown:

Ages Served

• Ages:

Executive Director

• Executive Director Name:
• Executive Director Phone:
• Executive Director Email:

Program Contact Person

• Program Contact Name:
• Program Contact Phone:
• Program Contact Mobile:
• Program Contact Email:

Diaper Pick Up Person

• Pick Up Method:
• Pick Up Name:
• Pick Up Phone:
• Pick Up Email:

Agency Distribution Information

• Distribution Times:
• New Client Times:
• More Docs Required:

Sources of Funding

• Sources of Funding:
• Sources of Diapers:
• Diaper Budget:
• Diaper Funding Source:

Documents

• Attach document input field

When the user clicks the registration link from their email
Then the user is presented with the registration form
When the user fills out the registration form
Then they can submit their request for approval

Hi guys, as I was trying to run the capybara tests I realised that the information to do this was on the Diaper ReadMe, but not here on the Partner repo. Do you think we should add a link on the Partner repo to the Diaper ReadMe testing section? Great to learn your view on this.
Thank you so much 😃

I've attached a design mockup for this.

If you have any questions, Check our slack

From a diaperbank:

A resource section that we as an agency can upload items for them to use or docs like our agency handbook, surveys, other printables.

This sounds a lot more like asset management. I don't know how prevalent of a need this is among partners, or how they are currently addressing it.

This may or may not be in-scope for this project, but I said I would pass it along!

We're currently using pretty basic bootstrap and we'd love any styling help anyone might want to offer! Additionally if someone would like to implement a bootstrap theme let us know!

Currently the README.md file indicates that the default users are [email protected] and [email protected] but the defaults created by the seeds.rb file are [email protected] and [email protected].

I love Parks & Recreation, but it might be better to use a generic email (the rest of the Partner details are probably fine though). :)

ON HOLD

We had some requests come in for additional base item types. One is "X-Small/Small" size for Adult Briefs, and then also some base item types for Menstrual products.

We need to get clarification on a few of these before we commit -- will update this issue when they come in.

Currently when a partner makes a request is only shows the categories that the diaper bank carries not the specific items.
Partners should be able to request specific items not just categories.

• This will require work on both apps

I received the following feedback from one of our partner agencies when trying to submit a diaper request via PartnerBase:

"I tried to remove one line item it made my entire order disappear so I just entered it again. I clicked on wipes or something and it has an option to remove but it made everything go away."

Here is a link to the video he sent me demonstrating the issue:
https://www.dropbox.com/s/is9y7ypft9w3r22/IMG_0597.mov?dl=0

This issue is work remaining from #51.

Controllers

partners_controller_spec.rb

(Note: html specs seem implemented; but not Json?)

• :create is successful via HTML
• :create is successful via JSON
• :update is successful via HTML
• :update is successful via JSON

This issue is work remaining from #51.

API

partners_controller_spec.rb

(note: not sure if implemented.. perhaps in spec/requests/api/v1/partners_requests_spec.rb ???)

• :create returns :forbidden if the API key is invalid
• :create is successful
• :update returns :forbidden if the API key is invalid
• :update is successful
• :show returns :forbidden if the API key is invalid
• :show is successful

We will need to add the bootstrap gem to the Gemfile (https://github.com/twbs/bootstrap-rubygem)

We have a basic login form we would like to apply bootsrap styling (/partners/sign_in)

Please follow the USDS guidelines for the buttons, input fields, labels and colors.

https://designsystem.digital.gov/components/form-controls/

I've attached a design mockup for this.

Finally, If you're really interested in design, please look into atomic design. It's a great chance to apply these principles when creating reusable templates and styling. More information can be found here (http://bradfrost.com/blog/post/atomic-web-design/)

If you have any questions, Check our slack

Note - This requires work on both the diaper and partner apps. Each point below will require altering the api endpoint on each app as well as whatever is making the request to the endpoint.

Summary

In the 'partner.rbthere is a method:approve_methat instantly sets thestatustosubmitted. It should wait for the successful result of the DiaperBankClient.post` action before moving forward.

Criteria for Completion

• A passing test that confirms that the status is NOT set if the post fails
• A passing test that confirms the status is set if the post is successful
• Verification from the Partner app that any additional work on that end is working

Reference / History

This was originally part of rubyforgood/human-essentials#636

We need to create a new form for a partner to fill out so they can request for diapers from their diaper banks.

The form will have labels to show the current partner's name.
The form will have the following input fields:

comments: string,

# The partner can click `Add an item` which will create a new row with 
the following information:

request_item: select dropdown,
quantity: number

Given the partner has filled out the form
When the partner clicks Submit for Review
Then the system will submit the form information to the diaper app

This will send a post request to the diaper app at /api/v1/partner_requests. Here is an example payload:

{
    "request": {
        "partner_id":5,
        "organization_id":1,
        "comments":"Lots and lots of comments",
        "request_items":
            {
            "k_size1":100,
            "k_size2":200,
            "k_size3":200,
            "k_size4":200,
            "k_size5":222,
            "k_size6":444
            }
    }
}

Note - This requires work on both the diaper and partner apps. Each point below will require altering the api endpoint on each app as well as whatever is making the request to the endpoint.

Summary

In the partner.rb there is a method approve_me that instantly sets the status to submitted. It should wait for the successful result of the DiaperBankClient.post action before moving forward.

Criteria for Completion

• A passing test that confirms that the status is NOT set if the post fails
• A passing test that confirms the status is set if the post is successful
• Verification from the Partner app that any additional work on that end is working

Reference / History

This was originally part of rubyforgood/human-essentials#636

There appears to be replicated code in both the normal partners_controller.rb and the API path code. If this is indeed replicated, then the general namespace controller code can be removed.

SCDB Client Application-2017 update 2 (1).pdf

See above. We need to be able to collect family information and child information.
In addition to the information listed here we should also collect if the family is a veteran family.

Many diaper banks do not distribute all of the canonical items, and instead only distribute a subset. We should grab the the active items from the diaper bank and only allow the partner to make requests containing those items.

This issue requires modifying both the diaper and partner repos. A possible flow would be:

• Create an api endpoint on the diaper app to display the items that particular organization distributes.
• When making requests, pull in the items and only allow the partner to make requests from that list.

Something that may be helpful is that as of Ruby 2.5 hash now has the slice method. So you can slice out the values you want to keep. So if you have an array of valid items you could `POSSIBLE_ITEMS.slice(*valid_items)

I spent 20 minutes or so spiking this out a little on the valid_items branch (on both repos.) Feel free to use that as a starting point (or not.)

We're using devise invitable to invite new partners to our system. Unfortunately, these invites expire after two weeks and our stakeholders often take much longer to sign up.

Let's make our invites never expire. We can re-evaluate in the future on how long they should last.

Note - This requires work on both the diaper and partner apps. Each point below will require altering the api endpoint on each app as well as whatever is making the request to the endpoint.

Summary

In the partner_requests_controller.rb#create action it executes DiaperBankClient.request_submission_post and sets the status to :sent. This status change should be conditional on a successful response from the Diaper app, so that the user does not incorrectly think it worked, when it did not.

Criteria for Completion

• A passing test that confirms that the status is NOT set if the post fails
• A passing test that confirms the status is set if the post is successful
• Verification from the Partner app that any additional work on that end is working

Reference / History

This was originally part of rubyforgood/human-essentials#636