Hours by everhour project and Clients CTA #45
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Integrated budget management for projects by adding a Budget model with hours and period properties. Updated schema and API to reflect new budget fields, ensuring budget information can be tracked and retrieved appropriately within project data.
Extracted Tracking Projects into a dedicated component for better readability and maintainability. Updated GraphQL query to fetch budget details for tracking projects, and added relevant budget data display in the new component.
Included budget details (hours and period) for tracking projects in the CasesTable component. Also updated GraphQL queries to fetch the budget information.
Introduce 'kind' field to TrackerProject schema and its resolver in cases.py to distinguish project types. Implement 'kind' property in timetracker.py with logic to determine project type based on boolean flags.
Added "kind" field to tracker query and utilized STAT_COLORS to dynamically set text color based on tracker type. This enhances the visual differentiation of trackers in the tracking projects table.
Introduced color coding based on the tracker's kind in CasesTable. Updated GraphQL queries to fetch the new 'kind' field to support the color coding functionality.
Previously, the worker's name and slug were being assigned incorrectly from undefined variables 'name' and 'slug'. This change ensures that the worker's name and slug are correctly assigned from 'tracker_worker.name' and 'tracker_worker.slug'.
Introduced `WeekWorkingHours` and `OneWeekPerformanceSummary` to handle weekly performance calculations. Methods were added for computing various summaries, filtering cases, and aggregating data for clients, sponsors, and account managers. Simplified `compute_performance_analysis` to leverage these new structures for clarity and maintainability.
Introduce a new `period_type` field to categorize weeks as "past", "current", or "future". This enhancement is reflected in both the model and GraphQL schema to improve performance analysis granularity.
Streamline the RegularCasesTable and PreContractedCasesTable components by accessing nested data directly from the `data` prop. This removes the need for `getClientsForManager` and `getSponsorsForClient` helper functions, enhancing readability and maintainability.
Replace sets with sorted lists for sponsors, clients, and account managers in compute_list_from_cases methods. This ensures a consistent order for elements, which can improve readability and facilitate easier debugging.
Implemented helper functions to filter out cases, clients, sponsors, and managers with zero hours across different performance analysis tables. This refactor helps in displaying only relevant data, enhancing performance and user experience.
Reworked the rendering logic of nested tables to enhance readability and efficiency. The new implementation maps cases directly within the nested structure, reducing unnecessary filtering and improving overall clarity. This change ensures that only relevant cases with actual or approved work hours are displayed correctly.
Updated helper functions to streamline case and totals filtering across components. Added deeper null checks and consolidated redundant code, improving readability and maintainability. Expanded non-zero hour checks to support nested elements and ensure consistency.
Updated `date_of_interest` to `dateOfInterest` in both backend schema and frontend query files for consistency. This change ensures uniform parameter naming across different parts of the codebase.
Renamed OneWeekRegularCasePerformanceSummary and OneWeekPreContractedCasePerformanceSummary to RegularCasePerformanceSummary and PreContractedCasePerformanceSummary respectively. Introduced the PastPerformanceAnalysis class to aggregate past performance data for regular and pre-contracted cases.
Renamed two performance summary fragments for consistency. Added analytics for past account managers, clients, and sponsors with detailed performance data.
Return `None` for `compute_from_cases` functions when case lists are empty to avoid unexpected errors. Updated GraphQL schema to make `TotalsRegular` and `TotalsPreContracted` nullable, aligning with the potential `None` return values. Verified logging to aid in debugging period type calculations.
Implemented `resolve_performance_analysis_pivoted` to aggregate weekly performance data by account manager. This function creates a sorted list of unique account managers and compiles their weekly totals, improving data accessibility and analysis efficiency.
Refactor variable naming for query setup to improve readability. Extend the PerformanceAnalysis GraphQL type with a new pivoted field and its associated resolver to support more detailed performance analysis.
This commit introduces a new data point "past" for each account manager in the performance analysis. The schema.graphql file was updated to include the "past" field, and the performance_analysis.py script now includes logic to fetch and append past performance data to each account manager's record.
Refactor to include detailed client performance data by week for each account manager. Updated schema to support new nested client performance structure.
Streamlined the mapping and aggregation of client data for account managers. This involves reducing nested loops and redundant checks, ensuring clearer and more efficient handling of weekly and client-specific performance data.
Enhanced the performance analysis by integrating past data for each account manager's client. This involves adding a new "past" field in the schema and updating the logic to fetch and append past data for individual clients.
This update introduces the inclusion of sponsor data alongside client data in performance analysis reports. Each client now includes sponsor-specific weekly data and past data in the response schema. The schema has been updated accordingly to support this new structure.
Enhanced tracking to include detailed case-level metrics for each sponsor, with weekly and historical data. Updated schema to support case details, ensuring comprehensive performance analysis.
Implemented functionality to compute and resolve pre-contracted performance analysis. Updated GraphQL schema to include fields for pre-contracted performance data, ensuring comprehensive performance metrics are available.
Refactor frontend components to use pivoted data for performance analysis tables. Simplified backend code to handle past data conditionally and centralized totals rendering logic for clarity and maintainability.
Changed the date variable in the useQuery hook to directly use the formatted current date instead of the first day of the month. This ensures that the query accurately reflects the current date when fetching performance analysis data.
Added functionality to display the date range for the "Past" column in all relevant tables. Additionally, updated the column background to yellow for better visual distinction.
This update introduces logic to map Everhour project IDs to cases and identify duplicates. If duplicate IDs are found, the relevant details are added to the inconsistency report, highlighting which cases share the same Everhour project ID.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.