Open fosterlynn opened 6 years ago
My inclination is a contact per location. but yes, let's clarify.
I can see that having a contact for material for #3 (material at Bradley tech) may be too broad, since different people may control access to different material within the building (metal vs wood shop vs engineering lab, for example) I can see that it would be useful to assign a contact for #4 (materials in Room C), but assigning a contact for #5, every bin in Room C is over kill.
Do any of the other uses of "location" above get in the way of that?
@pdreyn thanks! This makes sense to me. So I think the question is: is 4. an agent or a location? Let's think if it has any agency or organization-ness - which it might if someone is in charge of it, there are some rules around it, it is part of a group like wood shop, but I don't know. If so, we can use the existing structure for agent relationships and create one for Room C and the contact person.
If it is just a location (which it might be), we can create a new contact thing for locations.
One way to think about 4. is: is it Bradley Tech Room C, or is it Bradley Tech Wood Shop?
The agent option is definitely easier in terms of code because it is basically already there, even the api.
There is a requirement to show resource contact information on the new inventory page(s).
I would like to understand better at what level the contact person should be. Will it be one contact person per location? Or one contact person per organization? Or should it be at the actual resource level?
If at the resource level, adding the contact will be needed when every resource comes in through a donation.
If at the location or organization level, let's make sure we are clear how we are handling locations vs organizations in the data.
@pdreyn I think this requires some feedback from you. Thanks!