-
Notifications
You must be signed in to change notification settings - Fork 1
Starting points (Development)
See Issues tab to the left
See Testing
The naming of the Owner table now is confusing because it should have been more aptly named the 'Person' table, as it contains both (General) Owners, Subscribers, AND Subscriber Owners. A good starter task could be renaming the table and rewriting the code to work with the new table. This is a simple but very involved change, as it would entail the renaming of all helper methods (due to the way these methods are now being generated by the Airtable Schema Generator and might either be simple or potentially breaking.
Problem
When choosing a project group, we want the functionality of ordering project group based on closeness and being able to view the project groups on a map based on the user's current location.
What we have
Currently, we have a map view component partially implemented but not used in the project. In ProjectGroupStep.js, you would need to implement handleViewChange() and that should allow for the map view to be a viable option. Then, in ProjectGroupMapView.js, you will see a partially implemented map view. The initial center of the map is hardcoded and the markers are implemented assuming markers are correctly passed in as props.
What's missing
There are 4 main parts that need to be implemented:
-
User Location
- Need to find the latitude and longitude of the current user
-
Project Group Location
- Need to find the latitude and longitude for each of the project group
- Convert project group list to markers where each marker object looks like
- marker = { name: [project group name], position: {lat: [project group latitude], lng: [project group longitude]} }
-
List View
- Need to order project groups in order of closeness from the users location
- Display the distance from the user for each project group in the project group card
-
Map View
- rewrite initialCenter of to the user's longitude and latitude
- make sure markers are being correctly passed in
Problem
In early 2020, Lora Jo Foo took on both meters in her building when the other tenant moved out. This meant that she effectively had two PG&E bills. Currently our Bill Generation flow only supports one meter per subscriber.
Potential Solution
One way we could go about solving this is by simply adding support for multiple meter IDs. Currently the bill generation flow looks like:
Pull PG&E data for meter → Double-check meter hasn't been pulled before → Pull Enphase data for start/end date in PG&E bill → Compute
We could instead change it to:
Pull PG&E data for all meters → Combine the data for any bills that haven't been processed → Pull Enphase Data for combined start/end dates → Compute
Concerns
The main difficulty and trickiness here is making sure bills don't get processed twice. Right now, bill generation is super tolerant against someone sending multiple requests. It can easily ensure that it doesn't process the same bill twice using the start/end date. But if there are multiple meters that each potentially run on a different billing schedule, it's much harder to know when it's safe to create a new bill.
It could still be done, we would just have to make some more decisions about what limitations are in the process, and we might want to make the frontend for the bill generation process a little more formal so it's easier not to mess up.
Regardless, supporting this would require some significant changes, so if it truly is an edge case, I'd recommend using a workaround for now.
Workarounds
- Since PDFs can be regenerated, one solution would be to maintain separate accounts for both meters, generate bills separately, combine their values after the fact, and regenerate the PDF
- This could work well, but would require some extra work on the admin's part (especially for recalculating trickier values like Would-Be-Costs. Might not be sustainable for long term use cases
- Maintain two separate subscriber accounts and generate bills separately, but then switch the second bill (for the unused meter) to be under the first subscriber's account manually in Airtable. Then, the subscriber would see two separate bills appear, though their balance would be combined and they would only have to pay off the latest one.
- This is likely the easiest way to go about it, but it still requires extra work and it also has the issue of having weird results for the charts displayed on the subscriber dashboard since there would be two data points for each month. We would have to rectify that somehow.
Currently, trying to divest simply pops up a modal to contact an admin. If we wanted, we could set up a flow where clicking the divest button will send an email to an admin. To do this, we'd have to set up a new endpoint on peoplepower-node that could receive a divest request and trigger an email. The frontend would then send a request to this endpoint along with notifying the user. We could also consider having a flag in airtable so they can't send a request multiple times.
This would be very similar to the invite endpoint, except the recipient would be an admin.
No logging is currently used. Solutions like Sentry or Fullstory can be considered to log errors