An open-source web app that illustrates how waste management software can interface with RCRAInfo to track hazardous waste electronically
Home Page: https://usepa.github.io/haztrak/
License: MIT License
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
Add a new file, or add to Handler.ts, with the Transporter model TypeScript interface definition in the /client/src/types directory.
The Transporter extends the Handler model with two fields, order (integer) and manifest (integer, also a foreign key to Manifest model). The model definition for transporters on the server can be found at /server/apps/trak/models/transporter.py.
Do this for fun, not because it absolutely needs it. Will take time, but I expect not a huge mental lift.
Migrate from the Bootstrap Framework version 4.6.1 to 5.x.x as the title says. This would be nice to get done before the front end becomes more than a placeholder. Right now (4/15/2022), I don't think migrating would be that difficult because we're not heavily using any bootstrap features or javascript.
There is a little JQuery being used but it's minimal, located in the static content directory.
haztrak's frontend starting point was SBadmin2
Bootstrap's documentation on migration to version 5
Setup a more robust test suite for the haztrak client and server.
I'm leaving this open ended for anyone interested in contributing, this is a good way to get better acquainted with the code base, and we'll accept PR with even a small number of (quality) tests.
Break down the (e-)Manifest form into components (already started), each component should have accompanying validation (see below)
These dependencies are already available in Haztrak
client side validation is handled with yup, react-hook-form has some basic validation built it, currently we're keeping that logic in yup validation schema. The entire manifest form can be broken down in to reusable components (e.g., address validation/form for all handlers should be the same).
Replicate the current Site Dashboard as a react component
per the well known guidance for 12 factor apps separate configurations from Code
If the goal of this project is to build something that others can (possibly) adopt or use as an example, this project's success will live or die by it's documentation
build out a basic suite of unit and integration test that should be run (at least!) before commits are merged into the main branch. May want to consider using git hooks for pre-commit test as well. See issue on building out a basic CI/CD pipeline
It would be great to create a quick CI/CD pipeline that should do a couple things
pretty self-explanatory title,
will require some work with the custom serializer create methods, this will likely not be a straightforward task but should be easier to implement and maintain than the janky way it's in there right now.
As the title suggest
May start off with a basic APIView, would be good to migrate to one of Django's generic views maybe sometime down the line
This is likely more difficult than I imagine. we either need to...
Something that pings a third party API seems like something that should use a messaging broker like Redis. I haven't decided if that makes sense for the scope of this project. I'm not sure what that would take to implement it since I' haven't research this.
Currently the Transporter model extends the Handler model instead of containing a reference to a Handler model in a ForeignKey field.
Should that be altered?
We'd like to be able to display more rows of manifest than what can be displayed with 3 tables in this view here.
instead of displaying 3 separate tables (The manifest affiliated with this site as a hazardous waste generator, transporter, and TSD), show 1 table with 3 views (that can be navigated via links/buttons at the top). Each view should have one of the three tables.
Default the view to Generator for now.
When loading a site's manifests, manifests should be paginated. This is probably a good first issue for someone looking to get experience with React. No dependencies should need to be pulled in, but a custom hook will likely need to be built.
freecodecamp.org has a blog that may be useful as a guide.
With regards to defaults, I would say we should display ~10 manifest on site's page. We may need to reorg a Site Manifest view so it only displays 1 table (on which the view can be switched from generator, transporter, TSD) instead of all three. when applicable, being displayed in three rows. See #132
When user is not found or error occurs at login, display the error (bonus points for looking good while doing it).
There is still a lot of prototype code in the login function and redux user slice in general. right now, when a user attempts to login and uses bad credentials or the haztrak server cannot be reached, an error is displayed by redux in the console but that's it.
This the login.rejected reducer function needs to be updated from
state.error = action.payload.error; // <-- The payload object is undefined when the promise is rejectedto
state.error = action.error.message; // <-- a stringhaztrak does not really have a logo, but for now, it would be good to add a label to the login screen.
We can dimply use the same 'logo' that's in the top left corner of the home screen (after login) found here
title says it all,
all logic containing the Axios dependency should be in https://github.com/USEPA/haztrak/tree/main/client/src/services
Add documentation on how to easily get haztrak up and running locally. including
We should also add a bullet point (it should be the first one) to the README's Getting started Section
When users add a Site to their profile, if that site corresponds to a Handler that exists/is a registered site with
When the user does not have a API ID and Key (or an admin that allows them to use their API credentials), it should notify them that they will not be using up-to-date site details.
Implement a simple profile view for the front end at https://domain.com/profile There is already an feature folder with a Bootstrap card at client/src/features/profile. Currently, it shows the users RCRAInfo API ID and Key (also need to remove that information from being accessible through the API, that's a separate issue). Remove the rcrainfo API ID and Key from the card, and add a simple dispay which shows the user their profile information, which is delivered from the server via this object...
{
"user": "string",
"epaSites": ["string"]
"phoneNumber": "string" | null
}We had a basic example before haztrak was converted to a SPA design pattern here in the pre-release in html.
This is dependent on many other things being implemented first.
This is a high level issue and may have many sub issues.
Remove RCRAInfo API ID and Key that is exposed on the profile.py view.
Migrate from the Bootstrap Framework version 4.6.1 to 5.x.x as the title says. This would be nice to get done before the front end becomes more than a placeholder. Right now (4/15/2022), I don't think migrating would be that difficult because we're not heavily using any bootstrap features or javascript.
There is a little JQuery being used but it's minimal, located in the static content directory.
I think the only views that remain as functional based views are those from the account django.app. It would be nice to have consistent approach (i.e., convert account views to class based view). This would be a good first issue.
Title says it all, low priority
Once logged in, implement a React-Redux slice that manages state for user profile and contain information such as
This could allow haztrak to do things such as
Alright, here we go, getting into the meat of things.
Create a series of endpoints that allow for users to request server side actions related to integrating with RCRAInfo (e.g., calling the RCRAInfo/e-Manifest API)
For a single manifest, UI link service for RCRAInfo
This Issue includes 2 main parts...
This is a relatively large change, It means that the haztrak api service has to be accompanied with a redis and celery service deployment as well.
While the added complexity is unfortunate for the scope of this project, using a task queue (along with the message broker) is necessary for an application that so heavily relies on an external service (RCRAinfo) to perform it's core functions (using e-Manifest).
Haztrak needs to be able to consume and store manifest data from rcrainfo. At a high level this includes
In addition, haztrak should be able to serve manifests as well
pulling is easy, that's already implemented by the emanfiest client library which pulls the manifests down as json.
Model and Serializer implementation:
A lot of the fields lower on this list are lower priority and we will continue to simply take the json from RCRAInfo and store it as text.
Transporter and waste will be tricky ones and are the last thing to really implement before we can move on to other things.
In the future, the ability to store PDFs will be required but for now we're not focused on that.
As the title suggest
Should be fine with just a basic APIView with GET as allowed method (these are part of the Site Model, not handler, Site is specific to sites that the user has access to)
Users need to be able to manage their basic profile info
Most of this is complete, django docs should be able to help implement "see which EPA ID i have access to" and django auth_views has generic views for resetting passwords but email users may be a heavier lift. have not looked into it.
Add an endpoint that will allow users to search for transporters that already exist in the haztrak back end. The new API endpoint should accept POST request only, and expect the body to include the following.
{
"epaId": string, // corresponding to the handler/transporter's EPA ID number
"name": string // corresponding to the handler/transporter name
}The endpoint should return an array of transporters who's EPA ID number AND name contain the strings queried for via the API. The endpoint does not need to know about all possible tranporters in RCRAInfo, just those stored in the haztrak database.
Right now the Handler and EpaSite model capture the same information. they are also now located in the same django app since the trak and site apps were consolidated.
Effort to remove duplication, we will reconfigure to create the following...
The Handler model is used to capture the generator, transporters, and TSD listed on a manifest.
The Site model has a one-to-one relationship with the handler model so with django, having access to a Site will give access to all information capture in the handler model and will and can also be extended to include information not needed by RCRAInfo such as
This is a 2 part questions. 1 how users can navigate to their manifests in haztrak? How do we organize the routing itself? Answering this may help wrap out noggins around the number of React features we're going to need.
It would be nice to be able to access a users manifest without having to drill down so many clicks from home -> site -> site manifests -> manifest view/edit.
Initial thoughts, handling all routing as a sub routing in the 'Manifest' feature directory. the Manifest component will be the top level component that will generally own manifest data and pass down data as props.
add docker compose file to bring up client and server services, users with docker should basically be able to go from download, configure, and deploy locally in a couple commands.
This will allow us to filter/display manifest by the site that owns it, instead of just looking for the handler. doesn't really make sense the way it is now, just haven't had time to fix.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.