Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Partner Groups: Classification Tags for Partners #2059

Closed
5 tasks
giacoelho opened this issue Dec 18, 2020 · 5 comments · Fixed by #2131 · May be fixed by rubyforgood/partner#531
Closed
5 tasks

Partner Groups: Classification Tags for Partners #2059

giacoelho opened this issue Dec 18, 2020 · 5 comments · Fixed by #2131 · May be fixed by rubyforgood/partner#531
Assignees
@albertchae
Labels
In Progress

Comments

@giacoelho
Copy link
Collaborator

giacoelho commented Dec 18, 2020 •
edited
Loading

Summary

Our stakeholders serve a number of different organizations and often distribute items based on the type of organization. So, for example, they may distribute both diapers and period supplies to a women's shelter, only newborn diapers to a neonatal clinic, adult incontinence supplies to a shelter, and everything to a food pantry. In the drop-down list of items, currently any kind of partner can view all items that a organization supplies and request any of them.

This often leads to challenges as users accidentally request items that they should not be requesting, which puts an unnecessary burden on our diaper bank users, and requires them to do additional work. Based on stakeholder input, we came up with the concept of partner groups. Partner groups are classifications that are meant to create groups that show which items a partner is able to request. So, for example, say an organization created 5 different partner groups - neonatal, basic diapers, period supplies, adult incontinence, and `sundries'. They would then go to their various partners and tag them with which group they belong to. Then they would tag items as belonging to different groups. Then when a partner makes a request they will only see which items have been tagged as available for them.

Things to Consider

This will likely involve some changes on the partnerbase application as well.

Criteria for Completion

  • Create partner groups on organizations. Each organization can have multiple partner groups and they should be able to create, deleted, and edit their groups.
  • Partner groups need to be assignable to partners. Partners can be tagged with multiple different partner groups.
  • Items are also able to be tagged with the partner groups they belong to. Items can be tagged with multiple partner groups. The partner groups might also be things like homeless shelters and women's shelters.
  • When a partner makes a request they only see the items tagged for them.
  • If the partner has nothing tagged they should see all items.
@giacoelho giacoelho added the Help Wanted Groomed + open to all! label Dec 18, 2020
@giacoelho giacoelho changed the title Partner Groups Partner Groups: Classification Tags for Partners Dec 18, 2020
@edwinthinks
Copy link
Collaborator

@designbygia thanks for creating this issue!

@albertchae I've assigned you to this issue.

Let's discuss the implementation details and the approach. I have some thoughts about how this might extend to more features in the future such as the idea of having 'tiers' to see how many items a partner should request per month or time period. Though that might be a feature creep, it might be good to see how it may fit into the future.

@seanmarcia seanmarcia added In Progress and removed Help Wanted Groomed + open to all! labels Jan 6, 2021
This was referenced Jan 21, 2021
Open
Merged
@armahillo
Copy link
Collaborator

@edwinthinks @albertchae
"PartnerGroup" feels like the wrong name here -- it's not a grouping of partners, it's a grouping of items. Partners are being subscribed to the individual groupings, but the group is defined by the items that are in it. ItemGroup might be a better name.

PartnerGroup is what we would want to use later if we were grouping partners by sector or region (ie. "Churches", "Food pantries", etc; or grouping them by zip code, etc), so it would be prudent to reserve that.

@edwinthinks
Copy link
Collaborator

@armahillo good catch! I do agree that PartnerGroup is probably not the right way to describe what is being built here. What we seem to be building here is a way to control the items that some partners could request or cannot request. To me, that sounds like a configuration or in the lines of permissions.

I propose maybe a name like RequestableItemsList (like ItemGroup) which can be a has_many relationship between this and Partner records. This way you can associate different lists of allowed items for partners.

I suggest we hold off jumping to PartnerGroup since that sounds like it implies many more things that we haven't yet researched yet (similiar to what @armahillo mentioned)

@albertchae
Copy link
Sponsor Collaborator

I agree about the name. It felt awkward while working with it to be honest.

It seems we might have 2 separate concepts here. One is for defining a set of items that some partner can request which we are all in agreement with. The other is how do we assign these sets of items to different (maybe multiple?) partners. Are we still thinking we'll allow diaper banks to assign a set of requestable items to multiple partners at once but not call it PartnerGroup for this immediate issue, or should we only allow them to assign these requestable item sets to one partner at a time? I'll discuss with @edwinthinks in the coding session and post a summary here after.

@SCDB
Copy link
Collaborator

SCDB commented Feb 9, 2021

This is really exciting functionality that's being added, and I'm wondering if it can be incorporated with #2121 that I put in about a month ago. If this categorization of products is happening, it will be a natural separation by "program", and it would be GREAT to be able to see totals/reports for each of those "requestable items lists".

@edwinthinks edwinthinks mentioned this issue Feb 15, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@albertchae albertchae

Labels
In Progress
Projects
None yet
Milestone
No milestone
6 participants
@albertchae @armahillo @seanmarcia @edwinthinks @SCDB @giacoelho