-
Notifications
You must be signed in to change notification settings - Fork 0
SSF-135 - admin order management changes #121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
2feb1c9
d2c8f74
62d20af
bb59975
93da783
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,20 @@ | ||
| import { MigrationInterface, QueryRunner } from 'typeorm'; | ||
|
|
||
| export class AddAssigneeToOrders1773009000618 implements MigrationInterface { | ||
| public async up(queryRunner: QueryRunner): Promise<void> { | ||
| await queryRunner.query(` | ||
| ALTER TABLE orders | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also here we can edit the dummy data to add ids for the asignee for each order |
||
| ADD COLUMN assignee_id INT NOT NULL, | ||
| ADD CONSTRAINT fk_assignee_id | ||
| FOREIGN KEY (assignee_id) REFERENCES users(user_id) ON DELETE SET NULL | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 'assignee_id INT NOT NULL' conflicts with 'ON DELETE SET NULL' so let's make it a 'ON DELETE RESTRICT' when assignee user is deleted, it will try to be set to null but column is not null so that will error |
||
| `); | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. when you add dummy data, we'd have to add the assignee column as nullable, backfill by populating existing row values, then set assignee_id as not null and add the fk here! |
||
| } | ||
|
|
||
| public async down(queryRunner: QueryRunner): Promise<void> { | ||
| await queryRunner.query(` | ||
| ALTER TABLE orders | ||
| DROP CONSTRAINT IF EXISTS fk_assignee_id, | ||
| DROP COLUMN assignee_id | ||
| `); | ||
| } | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -11,6 +11,7 @@ import { FoodRequest } from '../foodRequests/request.entity'; | |
| import { FoodManufacturer } from '../foodManufacturers/manufacturers.entity'; | ||
| import { OrderStatus } from './types'; | ||
| import { Allocation } from '../allocations/allocations.entity'; | ||
| import { User } from '../users/users.entity'; | ||
|
|
||
| @Entity('orders') | ||
| export class Order { | ||
|
|
@@ -95,4 +96,11 @@ export class Order { | |
| nullable: true, | ||
| }) | ||
| shippingCost!: number | null; | ||
|
|
||
swarkewalia marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| @ManyToOne(() => User, { nullable: false }) | ||
| @JoinColumn({ name: 'assignee_id', referencedColumnName: 'userId' }) | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 'userId' should just be 'id' to match the user entity field name |
||
| assignee!: User; | ||
|
|
||
| @Column({ name: 'assignee_id' }) | ||
Yurika-Kan marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| assigneeId!: number; | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -29,9 +29,9 @@ export class OrdersService { | |
| async getAll(filters?: { status?: string; pantryNames?: string[] }) { | ||
| const qb = this.repo | ||
| .createQueryBuilder('order') | ||
| .leftJoinAndSelect('order.request', 'request') | ||
| .leftJoinAndSelect('request.pantry', 'pantry') | ||
| .leftJoinAndSelect('pantry.volunteers', 'volunteers') | ||
| .leftJoin('order.request', 'request') | ||
| .leftJoin('request.pantry', 'pantry') | ||
| .leftJoin('order.assignee', 'assignee') | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. let's keep the leftJoinAndSelect for these since we want to populate the columns in the returned entity |
||
| .select([ | ||
| 'order.orderId', | ||
| 'order.status', | ||
|
|
@@ -40,9 +40,9 @@ export class OrdersService { | |
| 'order.deliveredAt', | ||
| 'request.pantryId', | ||
| 'pantry.pantryName', | ||
| 'volunteers.id', | ||
| 'volunteers.firstName', | ||
| 'volunteers.lastName', | ||
| 'assignee.id', | ||
| 'assignee.firstName', | ||
| 'assignee.lastName', | ||
| ]); | ||
|
|
||
| if (filters?.status) { | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -120,14 +120,6 @@ const AdminOrderManagement: React.FC = () => { | |
| const status = order.status; | ||
|
|
||
| const orderWithColor: OrderWithColor = { ...order }; | ||
| if ( | ||
| order.request.pantry.volunteers && | ||
| order.request.pantry.volunteers.length > 0 | ||
| ) { | ||
| orderWithColor.assigneeColor = | ||
| ASSIGNEE_COLORS[counters[status] % ASSIGNEE_COLORS.length]; | ||
| counters[status]++; | ||
| } | ||
| grouped[status].push(orderWithColor); | ||
| } | ||
|
|
||
|
|
@@ -613,7 +605,6 @@ const OrderStatusSection: React.FC<OrderStatusSectionProps> = ({ | |
| <Table.Body> | ||
| {orders.map((order, index) => { | ||
| const pantry = order.request.pantry; | ||
| const volunteers = pantry.volunteers || []; | ||
|
|
||
| return ( | ||
| <Table.Row | ||
|
|
@@ -670,26 +661,21 @@ const OrderStatusSection: React.FC<OrderStatusSectionProps> = ({ | |
| alignItems="center" | ||
| justifyContent="center" | ||
| > | ||
| {volunteers && volunteers.length > 0 ? ( | ||
| <Box | ||
| key={index} | ||
| borderRadius="full" | ||
| bg={order.assigneeColor || 'gray'} | ||
| width="33px" | ||
| height="33px" | ||
| display="flex" | ||
| alignItems="center" | ||
| justifyContent="center" | ||
| color="white" | ||
| p={2} | ||
| > | ||
| {/* TODO: Change logic later to only get one volunteer */} | ||
| {volunteers[0].firstName.charAt(0).toUpperCase()} | ||
| {volunteers[0].lastName.charAt(0).toUpperCase()} | ||
| </Box> | ||
| ) : ( | ||
| <Box>No Assignees</Box> | ||
| )} | ||
| <Box | ||
| key={index} | ||
| borderRadius="full" | ||
| bg={order.assigneeColor || 'gray'} | ||
| width="33px" | ||
| height="33px" | ||
| display="flex" | ||
| alignItems="center" | ||
| justifyContent="center" | ||
| color="white" | ||
| p={2} | ||
| > | ||
| {order.assignee?.firstName.charAt(0).toUpperCase()} | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. can remove the ? for first & last name since an order must have an assignee |
||
| {order.assignee?.lastName.charAt(0).toUpperCase()} | ||
| </Box> | ||
| </Box> | ||
| </Table.Cell> | ||
| <Table.Cell | ||
|
|
@@ -712,10 +698,8 @@ const OrderStatusSection: React.FC<OrderStatusSectionProps> = ({ | |
| <Table.Cell | ||
| {...tableCellStyles} | ||
| textAlign="left" | ||
| color="neutral.700" | ||
| > | ||
| {/* TODO: IMPLEMENT WHAT GOES HERE */} | ||
| </Table.Cell> | ||
| bg="#FAFAFA" | ||
| ></Table.Cell> | ||
| </Table.Row> | ||
| ); | ||
| })} | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should never be editing an existing migration checked into main, this should be done in your new migration.
As per Sam said: "Clarification on updating the dummy data for future database changes: this should be part of the new migration you are writing for the schema update! Existing migrations that are checked in to main should never be modified, and it would not be possible in a lot of cases to split out a database schema change and a data migration into two separate migrations even if you wanted to - e.g., if you were adding new required fields into a table, you wouldn't be able to wait until the next migration to add those fields to existing data - so any future database schema change should include dummy data updates as part of the same migration. This mirrors how migrations are often used in real apps - after the app is deployed to production, any database migration must not only update the database schema but also update all the existing user data that is already in the database to match the new schema!
(tldr: do not change the existing dummy data migration; update the data as part of the new migration you are writing :he_is_brighter:) (edited)"