-
Notifications
You must be signed in to change notification settings - Fork 1
fix: #453 include customer and project id in reports #472
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
Conversation
@@ -9,6 +9,8 @@ export interface Entry { | |||
project_id?: string; | |||
owner_email?: string; | |||
description?: string; | |||
customer_id?: string; |
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 are these fields going to be null or undefined (since you are defining them as optional
?
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 you are creating an entry.
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.
This is the type used when creating time entries 👉 https://github.com/ioet/time-tracker-ui/pull/472/files#diff-bd34e3ddb205e30a185a58e351ccd04eL14 , so I think these new fields might not be optional
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.
The time_entry table has the project id information, the customer info is not saved as part of it.
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.
True fact. However, from my perspective, the time_entry table is encapsulated into the API. The frontend does not ( and should not ) know about the database data structures. The frontend does ( and should ) know only about the data structures the endpoints are using ( which might be different from the database structures). In this case, the Entry model/data structure/DTO represents the payload received from the /time-entries
endpoint. Therefore, the customer and project information is not going to be empty since there is no way to create an entry without specifying the project ( and thus the customer).
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.
In addition, I think we can improve this data structure using compound objects. Something like this:
interface Entry {
id: string;
running: boolean;
start_date: Date;
end_date?: Date;
activity_id?: string;
technologies: string[];
uri?: string;
project :{
id: String
name: String
customer:{
id: String
name: String
},
......
}
This might be done on a different issue since it should involve the backend as well.
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.
Yup, good idea
Please don't merge this PR before this PR is merged and deployed ioet/time-tracker-backend#197