Skip to content

Commit

Permalink
Quicker sign feature (#418)
Browse files Browse the repository at this point in the history
* Admin site updates

* update SDD documentation

* add test suite for QuickerSignModalBtn
  • Loading branch information
dpgraham4401 authored Apr 1, 2023
1 parent 3297f48 commit 4f18526
Show file tree
Hide file tree
Showing 6 changed files with 209 additions and 63 deletions.
87 changes: 87 additions & 0 deletions client/src/components/QuickerSign/QuickerSignModalBtn.spec.tsx
Original file line number Diff line number Diff line change
@@ -0,0 +1,87 @@
import '@testing-library/jest-dom';
import { QuickerSignModalBtn } from 'components/QuickerSign/index';
import React from 'react';
import { cleanup, renderWithProviders, screen } from 'test-utils';
import { createMockMTNHandler } from 'test-utils/fixtures';

afterEach(() => {
cleanup();
jest.resetAllMocks();
});

describe('QuickerSignModalBtn', () => {
test('renders', () => {
const handler = createMockMTNHandler();
renderWithProviders(
<QuickerSignModalBtn
siteType={'Generator'}
mtnHandler={handler}
handleClick={() => console.log('hello')}
/>
);
expect(screen.getByRole('button')).toBeInTheDocument();
});
test('is disabled when already signed', () => {
const signed_handler = createMockMTNHandler({
signed: true,
});
renderWithProviders(
<QuickerSignModalBtn
siteType={'Generator'}
mtnHandler={signed_handler}
handleClick={() => console.log('hello')}
/>
);
expect(screen.getByRole('button')).toBeDisabled();
});
test('is not disabled when not signed and user is API user', () => {
// A handler that has not signed the manifest to be rendered
const unsigned_handler = createMockMTNHandler({
signed: false,
paperSignatureInfo: undefined,
electronicSignaturesInfo: undefined,
});
renderWithProviders(
<QuickerSignModalBtn
siteType={'Generator'}
mtnHandler={unsigned_handler}
handleClick={() => console.log('hello')}
/>,
{
// Redux store state with an API user is required for this button to be active
preloadedState: {
rcraProfile: {
user: 'username',
phoneNumber: '1231231234',
apiUser: true,
},
},
}
);
expect(screen.getByRole('button')).not.toBeDisabled();
});
test('is disabled when API user but already signed', () => {
// A handler that has not signed the manifest to be rendered
const unsigned_handler = createMockMTNHandler({
signed: true,
});
renderWithProviders(
<QuickerSignModalBtn
siteType={'Generator'}
mtnHandler={unsigned_handler}
handleClick={() => console.log('hello')}
/>,
{
// Redux store state with an API user is required for this button to be active
preloadedState: {
rcraProfile: {
user: 'username',
phoneNumber: '1231231234',
apiUser: false,
},
},
}
);
expect(screen.getByRole('button')).toBeDisabled();
});
});
86 changes: 59 additions & 27 deletions docs/haztrak_book/src/design/sdd.md
Original file line number Diff line number Diff line change
Expand Up @@ -33,15 +33,15 @@ is time, and our entire budget is our what we can give in our spare time.

## Scope

The scope of this project is to develop a single page web application (SPA) that demonstrates
The scope of this project is to develop a web application that demonstrates
how hazardous waste management software can interface with the Environmental
Protection Agency's (EPA) [e-manifest system](../e-Manifest.md) to electronically track hazardous
waste and leverage resources exposed by the [e-Manifest web services](https://github.com/USEPA/e-manifest)
waste and leverage resources exposed by the [RCRAInfo](https://rcrainfo.epa.gov/rcrainfoprod/action/secured/login)
to properly manage hazardous waste.

The web application consists of a [user interface](#front-end) that allows users to input
The web application consists of a series of services such as a [single page application (SPA)](#front-end) and [HTTP server](#back-end) that allows users to input
information related to hazardous waste management, including information about
the waste generators, transporters, and disposal facilities. The application
the waste generators, transporters, and disposal facilities. The web application
will then utilize the e-Manifest system's web services to electronically track
the hazardous waste throughout its lifecycle, from cradle-to-grave.

Expand All @@ -54,9 +54,9 @@ authorized users can access and modify the data.

The web application will be designed to be scalable.
The project will be developed using modern web development technologies and best
practices to ensure that the application is maintainable and efficient.
practices to ensure that the application is maintainable and provides a realistic working example.

Overall, this project aims to demonstrate the benefits of integrating hazardous
Overall, the Haztrak project will demonstrate the benefits of integrating hazardous
waste management software with the e-Manifest system to properly manage hazardous
waste and reduce the risk of environmental harm. The web application developed in
this project will serve as a proof of concept that can be used to convince
Expand All @@ -67,27 +67,22 @@ Haztrak does not offer a comprehensive suite of hazardous waste management
functionality but, instead, focuses on executing the electronic manifest
workflow. As such, we expect to support the following functionality.

- [ ] Draft new electronic manifests.
- [x] Draft new electronic manifests.
- [ ] Upload draft manifests to RCRAInfo to create electronic manifests.
- [ ] Edit electronic manifests (when appropriate) and upload changes to RCRAInfo.
- [ ] Use EPA's Quicker Sign functionality to sign electronic manifests.
- [ ] Control access to resources based on user's permissions from RCRAInfo.
- [x] Use EPA's Quicker Sign functionality to sign electronic manifests.
- [x] Control access to resources based on user's permissions from RCRAInfo.

## Architecture

This section provides a high-level overview of how responsibilities of the system
are partitioned between subsystems/services.
are partitioned between system components/services.

The Haztrak system can be described as a series of services.

Throughout our documentation, you'll frequently see us place these services into
two categories, 'front end', and 'back end'.

#### Back End

At this phase in the developments lifecycle we don't employ a logging service,
however this could be added in the near future.

### Front End

The Front End consist of two user interfaces.
Expand All @@ -99,15 +94,20 @@ The Front End consist of two user interfaces.

The client is, fundamentally, responsible for rendering the user interface and
presenting the user with Haztrak's available functionality. Haztrak comes
pre-equipped with a client that can be accessed via the user's browser,
specifically a single page application (SPA).
pre-equipped with a client for the browser, specifically a single page application (SPA).

The browser client makes extensive use of the [React library and ecosystem](https://react.dev/).

For more information, see our [chapter on the browser client](./browser-client.md)

#### Admin Site

The admin interface is an out-of-the-box feature of the [Django framework](https://docs.djangoproject.com/en/4.1/ref/contrib/admin/)
It provides a quick, model-centric interface where trusted users can manage content.
It's not intended to provide a process centric interface, although we will try to provide some
customization to make it easier to do admin centric work related to the manifesting process.
The Admin site provides a quick, model-centric interface where trusted
users can manage content. It's not intended to provide a process centric interface,
admin user's should not be, for example, signing manifests through the admin site.

The admin interface is an out-of-the-box feature of the [Django framework](https://docs.djangoproject.com/en/4.1/ref/contrib/admin/).
It can be found by appending `/admin` to the URL of the host and port of HTTP server, for example `http://localhost:8000/admin`

### Back End

Expand All @@ -122,21 +122,34 @@ The back end contains the following components:
#### Relational Database

Haztrak depends on a relational database to persist its user data as well as
information synced with (pulled from) RCRAInfo.
information synced with (pulled from) RCRAInfo. RCRAInfo/e-Manifest should
always be treated as the source of truth, however, the database provides users
the means to, for example, draft or update electronic manifests without submitting
the changes to RCRAInfo immediately.

The database schema is maintained in version control via a series of 'migration'
scripts. This enables us to initiate a new database and scaffold the expected
schema quickly and consistently for local development, testing, and backup.

The Haztrak project currently utilizes [PostgreSQL](https://www.postgresql.org/),
a widely used open-source object-relational database system known for reliability and performance.

For more information, see our [chapter on database design](./db-design.md)

#### In-memory Database

The in memory database acts as a broker for Haztrak's [task queue](#task-queue)
as well as a cache for the [http server](#http-server) to help cut down on
latency for recently requested resources.
The in-memory data store serves a couple purposes,

- As a message broker for Haztrak's [task queue](#task-queue)
- A cache for the [http server](#http-server)

As a cache, the in-memory data store is utilized to increase performance by allowing Haztrak to cut down on latency for recently used resources including recent database queries, and computed values. As a message broker, the data store provides a reliable way for the back end service to communicate which each other (e.g., launch background tasks).

The Haztrak project currently uses [Redis](https://redis.io/) as both the message broker and in-memory data store.

#### Task Queue

The task queue is responsible for jobs/scripts/tasks that should occur outside
The task queue is responsible for jobs/scripts/tasks/batch processing that should occur outside
the [http request-response cycle](https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol).
For Haztrak, a large part of this is communicating with RCRAInfo via
its [web services](https://github.com/USEPA/e-manifest), a well documented
Expand All @@ -147,6 +160,10 @@ errors cause by downtime in external systems.
The task queue can be scaled horizontally to include additional workers as needed.
We also deploy [task schedulers](#task-scheduler) for periodic tasks.

The Haztrak project uses the distributed task queue, [Celery](https://docs.celeryq.dev/en/stable/)

For more information, see our [chapter on the task queue](./task-queue.md)

#### Task Scheduler

The scheduler kicks off tasks at regular intervals, that are then executed by available
Expand All @@ -157,13 +174,23 @@ duplicating tasks. Periodic tasks can be scheduled by:
- Solar events (e.g., every day at sundown)
- Periodically (e.g., every 10 minutes)

The Haztrak project uses Celery's
[beat module](https://docs.celeryq.dev/en/stable/userguide/periodic-tasks.html) to schedule periodic tasks.

For more information, see our [chapter on the task queue](./task-queue.md)

#### HTTP server

The RESTful API serves data to hydrate the client and handles user authentication.
It is client agnostic, so it's not tied to any specific client, whether it be a
browser or mobile application. The API does not directly communicate with RCRAInfo,
but instead manages tasks provided by the task queue and passes on any necessary parameters.

The Haztrak Project makes extensive use of the
[Django framework,](https://www.djangoproject.com/) and it's ecosystem.

For more information, see our [chapter on the HTTP server](./http-server.md)

## Testing

Haztrak employs a suite of automated tests for the HTTP server, the http client
Expand All @@ -174,6 +201,11 @@ base branch (often called 'main' or 'master').
We intentionally do not aim for 100% code coverage with our test suite because,
what inevitably happens, is the test suite contains a bunch of low quality tests.

The Haztrak project uses the [pytest framework](https://docs.pytest.org/en/7.2.x/)
for testing the backend python services to write readable, [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) tests.

For more information, see our [chapter on testing](./testing.md)

## Requirements

What dependencies and things needed to be able to deploy/build Haztrak.
Expand All @@ -193,5 +225,5 @@ released for that version. Since the Git tag and image tag correspond,
the source for a given container tag can always be easily found. Containers built
from non-release commits should use

Haztrak is stored in a monorepo, as a result, the front-end and back-end
Haztrak is stored in a monorepo, the front-end and back-end
containers are built and released simultaneously with the same version number.
2 changes: 1 addition & 1 deletion docs/haztrak_book/src/design/testing.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ thoroughly tested.
- End-to-end tests simulate user behavior and ensure that the application works
as expected from the user's perspective.

Contributors are encouraged to practice [test driven development (TDD)](), we
Contributors are encouraged to practice [test driven development (TDD)](https://en.wikipedia.org/wiki/Test-driven_development), we
often ask that contributors provide tests to prove their PR are acting as intended.
However, we do not aim for 100% code coverage in our test suite. The Haztrak project
believes that doing so more often results in lengthy run times,
Expand Down
Loading

0 comments on commit 4f18526

Please sign in to comment.