Skip to content
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

Open
wants to merge 37 commits into
base: staging
Choose a base branch
from

Conversation

pachonjcl
Copy link
Collaborator

@pachonjcl pachonjcl commented Feb 24, 2025

Copy link

nx-cloud bot commented Feb 24, 2025

View your CI Pipeline Execution ↗ for commit 699eada.

Command Status Duration Result
nx test entity-service --coverage --runInBand ❌ Failed 25s View ↗
nx test unified-database-service --coverage ✅ Succeeded 23s View ↗
nx run-many -t lint build ✅ Succeeded 3s View ↗

☁️ Nx Cloud last updated this comment at 2025-02-26 14:00:06 UTC

@pachonjcl
Copy link
Collaborator Author

Will reduce coverage temporarily.

  coverageThreshold: {
    global: {
      branches: 85,
      functions: 95,
      lines: 95,
      statements: 95
    }
  },

import { FrameworkKey } from "@terramatch-microservices/database/constants/framework";
import { AdditionalProps, EntityDto } from "./entity.dto";

import { MediaDto } from "./media.dto";
// TODO: THIS IS A STUB!
Copy link
Collaborator

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.
Copy link
Collaborator

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;

Copy link
Collaborator

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;
Copy link
Collaborator

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" }] }
Copy link
Collaborator

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");
Copy link
Collaborator

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 }]
Copy link
Collaborator

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
Copy link
Collaborator

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")) {
Copy link
Collaborator

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)
Copy link
Collaborator

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;
Copy link
Collaborator

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.

Copy link
Collaborator Author

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

Copy link
Collaborator Author

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.

Comment on lines +41 to +46
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;
}
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants