-
Notifications
You must be signed in to change notification settings - Fork 0
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
[TM-1766] add initial changes for supporting entity get #64
base: staging
Are you sure you want to change the base?
Conversation
View your CI Pipeline Execution ↗ for commit 699eada.
☁️ Nx Cloud last updated this comment at |
Will reduce coverage temporarily.
|
import { FrameworkKey } from "@terramatch-microservices/database/constants/framework"; | ||
import { AdditionalProps, EntityDto } from "./entity.dto"; | ||
|
||
import { MediaDto } from "./media.dto"; | ||
// TODO: THIS IS A STUB! |
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.
Please remove this comment.
@@ -21,7 +21,6 @@ export class SiteLightDto extends EntityDto { | |||
this.populate(SiteLightDto, { | |||
...pickApiProperties(site, SiteLightDto), | |||
lightResource: true, | |||
// these two are untyped and marked optional in the base model. |
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.
Not a huge deal that this is removed, but it is kind of a useful comment 🤷🏻
description: "The associated project name" | ||
}) | ||
projectName: string | null; | ||
|
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.
There are lots of fields on the spreadsheet that aren't represented in this lite DTO, and projectName I didn't think was needed except in the full DTO. Is it actually needed here?
@@ -85,5 +90,134 @@ export class SiteFullDto extends SiteLightDto { | |||
lightResource = false; | |||
|
|||
@ApiProperty() | |||
totalSiteReports: number; | |||
siteReportsTotal: number; |
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.
Please review the spreadsheet. In the usage notes for this column I requested that it be renamed to totalSiteReports
to be consistent with projects. I'm going to skip over the rest of the DTO fields for now; please check what's on the spreadsheet against what you have here and I'll review again when that's done.
where: { uuid }, | ||
include: [ | ||
{ association: "framework" }, | ||
{ association: "project", attributes: ["name"], include: [{ association: "organisation" }] } |
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.
unless projectName / organisationName are needed in the LIght DTO, these associations should be removed. If organisationName is needed, please add the attributes: ["name"]
bit so the whole org record isn't fetched.
.sites([siteId]) | ||
.findAll({ attributes: ["id", "siteId", "numTreesRegenerating"] }); | ||
|
||
const regeneratedTreesCount = sumBy(hasBeenSubmittedSiteReports, "numTreesRegenerating"); |
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.
Another spot where the audit I did in the spreadsheet will help you. This field is not used in the FE. I would rename the approvedRegeneratedTreesCount
to just regeneratedTreesCount
, and remove this submitted reports field entirely.
A general guidance from product that I forgot to put on the tickets is that all aggregated fields on these entities should be based only on approved entities. The fact that some of them in PHP are using the submitted entities instead is a mistake.
(await DemographicEntry.gender().sum("amount", { | ||
where: { | ||
demographicId: { | ||
[Op.or]: [{ [Op.in]: siteReportWorkdays }] |
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.
When there's only one, there's no reason to wrap it in an or
. This can be simply
demographicId: { [Op.in]: siteReportWorkdays }
jest.preset.js
Outdated
branches: 50, | ||
functions: 50, | ||
lines: 50, | ||
statements: 50 |
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'll want this back to normal before the final merge.
this.builder.can("read", Site, { frameworkKey: { $in: frameworks } }); | ||
} | ||
|
||
if (this.permissions.includes("manage-own")) { |
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.
For manage-own
, we should also be checking projects in the org, per the current PHP policy. I did this recently for project-report.policy.ts
, and you can probably just copy that code over.
@@ -96,6 +108,102 @@ export class Site extends Model<Site> { | |||
@Column(TEXT) | |||
descriptionSitingStrategy: string | null; | |||
|
|||
@AllowNull | |||
@Column(INTEGER.UNSIGNED) |
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.
According to the current DB schema, this should be a DECIMAL(15, 1)
. Please carefully audit these fields against the current DB schema to make sure they all match. Once you've done that, I'll take another look over these new fields.
@ApiProperty() | ||
createdAt: Date; | ||
|
||
@ApiProperty() | ||
updatedAt: Date; | ||
|
||
@ApiProperty({ type: Project }) | ||
project: Project; |
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.
Lots of problems here:
- We'd never want to include the full project on another entity's DTO; that's a pattern from PHP we're ditching in v3. Fetching a couple of fields (like UUID and name) is OK, but if an element on the page needs the full project, it can use the project GET connection to pull it.
- A model cannot itself be an ApiProperty - it has to be a DTO
- I still think the project information isn't needed on the light DTO. Did you find a case where that's incorrect? Also applies to
projectUuid
below.
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.
Agree, we are removing project as a entity from the dto
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.
Actually the list of sites in admin do require the projectName
property, so that one will stay on the light dto.
if (query.search != null) { | ||
// This is they way that sequelize supports for searching in a joined table | ||
projectAssociation.where = { name: { [Op.like]: `%${query.search}%` } }; | ||
// This is to ensure that the project is not required to be joined (simulating an OR) | ||
projectAssociation.required = false; | ||
} |
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.
Please take a look to this comments, if you feel this is an anti pattern o there is a better way to handle this.
Happy to change it.
Task Link
FE PR
BE PR