Tool Request Integration with Public Works (modeling)

[TangoYankee]

Models: 1 . Tools

• Each tool is its own object according to the Tool Model

2 . Cleanup_Tools

• Links Cleanups and Tools Models

3 . Cleanup

• Add method to sync all the tools associated with a cleanup to the googlespreadsheet

[mosdevly]

I can see why you'd suggested a Tool and Cleanup_Tool model. The thought process makes sense.

But unless tools are things we do something with in the app, they function as options. This would mean listing the tools as a choice field on a model.

The spreadsheet suggests that we're posting our Cleanup events there, along with a EquipmentOrder type of model (something that asks for equipment) for the tools it would take to clean it up.

But are we expecting users to fill out that information? Because those details sound like something an official or representative of the city would need to approve, not something our users could post on a cleanup event before then. Examples:

• The amount of equipment
• Paint
• any of the sharp objects (clippers, loppers, pickup sticks, etc)

If someone knows the answer to this, post it. I'll dig around on the public works site to see what their process is for these tools.

[mosdevly]

After Saturday's meeting here's where we are with Public Works:

• We will continue to add cleanups to the Public Works spreadsheet for now.
• We'll create a new model SupplyOrder. Tim is working out the user workflow on it.

As for modeling, the SupplyOrder will need:

• Cleanup relation, which contains all relevant event data such as host, date and location.
• pickup_date and dropoff_date
• tools as a JSONField

The JSONField will contain key/value pairs for example rake: 4. This makes it easy for the frontend client. The form data would go directly into the database and sending it to google Sheets would be equally simple without a lot of overhead. See Google Docs for info about how the read/write works: https://developers.google.com/sheets/api/guides/values

[mosdevly]

Mapping Oakland

[mosdevly]

I'll post an example based on discussion here: https://github.com/openoakland/TrashTalk/pull/156

[TangoYankee]

Public Works V. Trashtalk process: @Protosac I'm not sure whether you still have questions about the process of requesting tools. My understanding is that residents can make tool requests to the city, regardless of whether they're part of an organization. We are simply creating a process that integrates with TrashTalk and can be built out better than the current process. The city then decides whether to approve the request.

From my brief introduction of JSONFields, it appears to require: 1 . Each cleanup to have the JSON data written to it 2 . An alternative way to store quantity information, as the basic JSON will requires manipulation to store quantity data.

[TangoYankee]

My Suggestion: Modeled on internet-order

1. ToolOrder a . One to One relationship with Cleanup b . Summarizies all of the tools and their quantities for each Cleanup
2. ToolOrderDetails a . Many to One Relationship with ToolOrder c . Summarizes the quantity of a required Tool
3. Tool a . One to Many Relationship with ToolOrderDetails b . Properties of individual tools (i.e image location, description)
4. Downgrade Tool Category from Model to Property of Tool Model

[mosdevly]

Based on tonights conversation here's what I recommend (in addition to any other fields you'll need to add):

class SupplyOrder(TimestampedModel):
    cleanup = models.ForeignKey('cleanup', on_delete=models.CASCADE)
    tools = models.ManyToManyField('Tool')

class Tool(models.Model):
    quantity = models.IntegerField()

If you require categories, that's best done as a choice field, not a model. See the Location model for example.

[thinhngo]

Given that this is presently already working, would you be opposed to us just leaving it as it is?

If we change to a choice field we would have to:

• Refactor Django models and update serializers, test.
• Refactor the frontend to get choices from tools, test.
• Regenerate the fixtures, test.

We would be losing out on:

• Editing of tool categories from Django Admin. As developers, I'd assert that we're not the best source for what the tool categories should be, so I'd rather not codify these options.
• We wouldn't have the option of regularly pulling category updates from Public Works in an automated fashion. With categories living in a database, we just automate the updating database rows, there's no manual updates to code.
• Tuples aren't expressive enough for additional metadata... unless we develop new data structures to accommodate. As it is, it would be trivial to add additional category metadata to the model if we have to. Some metadata possibilities for the future might include: display ordering, description, category image...

[mosdevly]

2 models is good, we lose none of the benefits you listed. Categories are just fixed, broad descriptors at this point. Any necessary details should go on the tool description.

Add a management command to populate data, and avoid fixtures. This eliminates the need to maintain them every time the database changes.