heliosCreation/Helios-bug-tracker

Helios Bug Tracker is a .NET-based application for managing software defects, projects, and user teams. It provides role-based capabilities for creating and updating tickets, assigning team members, and tracking project details. The system also maintains a comprehensive audit log of database changes and supports user account management with email notifications.

Users can now delete projects. This change introduces the command and handler logic that locates a project by its ID and removes it from the system, returning a not-found response if the project does not exist.

src/BugTracker.Application/Features/Projects/Commands/Delete · high confidence

Users can now create new projects by providing a name (up to 30 characters), a description (up to 100 characters), and a list of team members. The system validates that the project name is unique and that all specified team member IDs exist in the identity service before saving the project.

src/BugTracker.Application/Features/Projects/Commands/Create · high confidence

Users can now retrieve tickets associated with a specific project, with results filtered by the user's role (e.g., Developers see only their assigned tickets, while other roles see all project tickets) and paginated for large datasets. Access is restricted to users who belong to the project team or have Admin privileges.

src/BugTracker.Application/Features/Tickets/Queries/GetProjectTickets · high confidence

Users can now update existing projects via a new command that validates input constraints (name max 30 chars, description max 100 chars, unique name) and verifies that all team member IDs exist before saving. The update logic maps the request to the project entity and passes the team list and admin status to the repository for persistence.

src/BugTracker.Application/Features/Projects/Commands/Update · high confidence

Users can now retrieve details for a specific project by ID. This change introduces the GetProjectQuery and its corresponding handler, which fetches the project from the repository, maps it to a view model, and returns it via an API response (including a not-found status if the project does not exist).

src/BugTracker.Application/Features/Projects/Queries/Get · high confidence

Users can now request specific ticket information including its associated team members and configuration settings. This change introduces a new query handler that fetches a ticket by ID, maps it to a view model containing type, status, priority, estimated hours, and team member list, and returns it via a standard API response structure.

src/BugTracker.Application/Features/Tickets/Queries, src/BugTracker.Application/Features/Tickets/Queries/GetTicket · high confidence

Users can now retrieve all available ticket statuses, types, and priorities through a new query endpoint. This change introduces the necessary DTOs (PriorityDto, StatusDto, TypeDto) and a MediatR handler that fetches these configuration entities from the repository and maps them for the client.

src/BugTracker.Application/Dto/TicketConfiguration, src/BugTracker.Application/Features/TicketConfigurations · high confidence

Introduced three new Data Transfer Objects (TicketByPriorityDto, TicketByStatusDto, TicketByTypeDto) within the BugTracker.Application layer to structure ticket aggregation data. These classes define the specific counts (e.g., Low/Medium/High priority, New/Open/Resolved status, Bug/Feature/Doc/Training types) that will be used to populate ticket diagrams.

src/BugTracker.Application/Dto/Tickets/Diagram · high confidence

Introduced a new Pager class in the application model layer to calculate and expose pagination metadata, including total items, current page, page size, total pages, and the specific range of records displayed (StartRecord/EndRecord) for the current view.

src/BugTracker.Application/Model/Pagination · high confidence

Users can now add comments to bug tickets and view the full comment history associated with a specific ticket. The new feature includes validation to ensure comment messages are not empty and do not exceed 100 characters. Access to create comments is controlled by role-based permissions: administrators have unrestricted access, while project managers and submitters can only comment on tickets belonging to their assigned projects; all other users are restricted to commenting on tickets where they are part of the specific ticket team. The view feature retrieves all comments for a ticket and enriches them with the username of the author.

src/BugTracker.Application/Features/Comments · high confidence

Introduced the AuditLogDto class within the BugTracker.Application.Dto.Audits namespace to structure audit trail data. This DTO exposes properties for tracking the user, table name, type of change, affected columns, primary key details, and the specific old and new values associated with an audit event, along with a timestamp.

src/BugTracker.Application/Dto/Audits · high confidence

Introduced CommentDto and CreateCommentDto classes to support comment functionality within the application layer. These data transfer objects define the structure for comment messages, associated user information, ticket identifiers, and creation timestamps, enabling the representation and submission of comments on bug tickets.

src/BugTracker.Application/Dto/Comments · high confidence

The domain layer now includes an \Audit\ class to record database operations (capturing user, table, timestamps, and value changes) and an \AuditableEntity\ base class that provides standard tracking fields (ID, created/modified dates and users) for domain entities.

src/BugTracker.Domain/Common · high confidence

Introduced new domain entities to support core bug tracking functionality: Ticket, Project, Comment, Priority, Status, and Type. The Ticket entity now includes relationships to Project, Priority, Status, and Type, along with estimated hours and team member associations. Projects can have team members, and tickets can have comments with messages. These entities form the foundation for ticket creation, project management, and issue tracking features.

src/BugTracker.Domain/Entities · high confidence

The infrastructure layer now includes an email service that sends account-related notifications, specifically user registration confirmations and password reset links. This service reads HTML templates from the wwwroot/Templates/Account directory, replaces placeholders like {{ConfirmationLink}} and {{ResetLink}} with dynamic values, and delivers the emails via SendGrid using configured API keys.

src/BugTracker.Infrastructure · high confidence

The application now includes new enum definitions to support audit logging and role-based access control, specifically tailored for a demo environment. AuditType and AuditableType enums define the types of database operations (Create, Update, Delete) and the entities they apply to (Project, Ticket). A new Roles enum introduces specific demo user roles (Demo\_Admin, Demo\_Project\_Manager, etc.) alongside standard roles, and a static dictionary maps these demo users to their email addresses, enabling the system to recognize and handle demo user logins.

src/BugTracker.Application/Enums · high confidence

The application now includes a set of data models in the Identity namespace to support user account management. These models define the structure for login credentials (AuthenticationModel), a demo user selection mechanism (DemoAuthenticationModel), account registration (RegistrationModel), and password/email recovery flows including forgot password, reset password, and email confirmation (ForgotPasswordModel, ResetPasswordModel, EmailConfirmationModel). These classes provide the validation attributes and data contracts required for the identity services.

src/BugTracker.Application/Model/Identity · high confidence

A new query handler has been introduced to fetch audit logs for a specific entity identified by its ID and type. This feature allows users to view the detailed audit trail associated with a particular record, mapping the raw audit data into a user-friendly format via a helper service.

src/BugTracker.Application/Features/Audits/Queries/GetAuditLogs · high confidence

Introduced the TicketVm class to represent ticket data, including standard fields like name, description, status, and priority, along with specific fields for the associated Project (Name and ID). This model supports the application's ability to display ticket details and link them to their respective projects.

src/BugTracker.Application/Features/Tickets · high confidence

The application now includes a MediatR pipeline behavior that automatically validates incoming requests using FluentValidation. When a request is processed, this behavior checks for any registered validators; if validation fails, it immediately returns a 400 Bad Request response containing the specific error messages, preventing the request from reaching the handler logic.

src/BugTracker.Application/Behavior · high confidence

The application now supports paginated retrieval of audit logs via the GetAllLogs query. Users can filter logs using a search string and navigate through results using a pager, which displays the total count and current page. Additionally, the log entries now include the human-readable user names associated with each log entry, rather than just user IDs.

src/BugTracker.Application/Features/Audits/Queries/GetAllLogs · high confidence

Users can now retrieve and filter audit logs by specific dates, hours, and minutes, or search across table names, user names, and value changes. The new AuditRepository implementation supports paginated results for these queries, allowing efficient browsing of the audit history.

src/BugTracker.Persistence/Services/Audits · high confidence

A new AuditEntry model has been added to the application's auditing layer to capture and record database operations. This class tracks entity changes by storing the user ID, table name, primary key, and the specific old and new values for modified columns, enabling the system to maintain a historical record of data modifications.

src/BugTracker.Application/Model/Auditing · high confidence

Added the MappingProfile class to define object-to-object mappings for the application's core domain entities, including Projects, Tickets, Comments, Users, and Audits. This configuration enables automatic conversion between Domain models, Application DTOs (such as CreateProjectCommand, TicketVm, and AuditLogDto), and ViewModels, supporting the creation, update, and retrieval workflows for these resources.

src/BugTracker.Application/Profiles · high confidence

The persistence layer now includes the initial Entity Framework Core migrations that establish the core database schema, including tables for Users, Roles, Projects, Tickets, Comments, and their associated team memberships. Additionally, the system is configured to automatically seed demo users and roles (such as Demo Admin, Demo Developer, and Demo Submitter) into the database upon migration, allowing immediate access for testing and demonstration purposes.

src/BugTracker.Persistence/Migrations · high confidence

The application now includes a foundational data access layer using Entity Framework Core with SQL Server, featuring an \ApplicationDbContext\ that manages entities such as Projects, Tickets, and Audit logs. Identity services are registered to handle user authentication and authorization, introducing specific access policies including 'NoDemo' to restrict demo users and 'PriviledgedUser' for Admins and Project Managers. Additionally, the persistence service registration wires up repository interfaces for data operations and configures audit logging to track database changes.

src/BugTracker.Persistence · high confidence

The repository now contains the complete source code for the Helios Bug Tracker application, replacing the previous web app. This initial release includes the solution structure with Domain, Persistence, Infrastructure, Application, and WebApp projects, along with an MIT license and comprehensive documentation. The application is a .NET 5 backend with SQL Server and Entity Framework Core, featuring a Bootstrap/JQuery frontend. Key capabilities include role-based access control (Admin, Project Manager, Developer, Submitter), project and ticket management with history and comments, user management, and system statistics.

(repo-wide) · high confidence

Added a new IdentityService implementation that centralizes user registration, email confirmation, login, logout, and account lock/unlock operations. The service also enables administrative capabilities such as listing users with pagination and search filtering, assigning and removing roles, and deleting user accounts.

src/BugTracker.Persistence/Services/Identity · high confidence

The application now exposes two new interfaces in the identity layer: IIdentityService, which defines the contract for user authentication, registration, role management, and user administration (including locking, deletion, and search), and ILoggedInUserService, which provides access to the current user's ID and roles. These interfaces establish the abstraction for identity-related operations within the application layer.

src/BugTracker.Application/Contracts/Identity · high confidence

The application now includes data models for sending emails, specifically an Email class with properties for recipient, subject, and body, alongside an EmailSettings class to configure the sender's API key, address, and name.

src/BugTracker.Application/Model/Mail · high confidence

The application now uses a new set of response classes (\BaseResponse\, \ApiResponse\<T\>\, and \IdResponse\) to wrap request results. This provides a consistent structure for API responses, including success status, HTTP status codes, and error messages, and introduces specific methods to handle common scenarios like 404 Not Found, 400 Bad Request, 401 Unauthorized, and 500 Internal Server Error.

src/BugTracker.Application/Responses · high confidence

A new CQRS query handler has been added to retrieve ticket statistics tailored to the current user's role. The endpoint returns counts of tickets grouped by type (Bug, Feature, Training, Documentation), status (New, Open, In progress, Resolved), and priority (Low, Medium, High, Immediate). The data scope is determined by the user's role: Admins see all tickets, Project Managers see their project's tickets, and Submitters or other users see only their own assigned tickets.

src/BugTracker.Application/Features/Tickets/Queries/GetTicketDiagramDataByUser · high confidence

The application layer now exposes dedicated Data Transfer Objects for managing tickets: CreateTicketDto, UpdateTicketDto, DeleteTicketDto, and TicketDetailsDto. These DTOs encapsulate the necessary command objects (CreateTicketCommand, UpdateTicketCommand, CreateCommentCommand) and view models (UserViewModel, TicketConfigurationEntitiesViewModel) required to handle ticket lifecycle operations, including associating teams and retrieving ticket history and comments.

src/BugTracker.Application/Dto/Tickets · high confidence

Added RoleDto and UserWithRoleDto classes to the UserManagement application layer. RoleDto exposes role identifiers and names, while UserWithRoleDto aggregates user details with a list of associated roles and a field for selected roles, enabling the backend to handle role assignment and removal operations.

src/BugTracker.Application/Dto/UserManagement · high confidence

The WebApp has been replaced with a new implementation featuring a dedicated Identity area for user registration, login, demo access, and password management, alongside a Tracker area for managing projects and tickets. The application now uses a CQRS architecture with MediatR and FluentValidation for request handling, providing users with a dashboard displaying paginated projects and pie charts for ticket statistics, as well as full CRUD capabilities for tickets and projects with role-based access control.

src/WebApp · high confidence

This change introduces a set of new view models in the application layer to support the UI and API contracts for various features. Specifically, it adds DashboardViewModel and ProjectWithTicketVm to handle paged project and ticket data on the dashboard, UserManagementViewModel and ManageUserRoleViewModel for user administration and role assignment, and UserTicketsVm for retrieving tickets linked to a specific user. It also includes LogViewModel for paged audit logs, TicketConfigurationEntitiesViewModel for ticket status/priority/type configurations, TicketDiagramDataModel for reporting metrics, and ManageUserStateViewModel for user lockout management.

src/BugTracker.Application/ViewModel · high confidence

A new IEmailService interface has been introduced in the application's infrastructure contracts to define capabilities for sending user registration and forgot-password emails. This contract specifies methods for sending a registration mail with a code and a forgot-password mail with a URL, establishing the interface that implementations must follow to support these user account workflows.

src/BugTracker.Application/Contracts/Infrastructure · high confidence

Users can now retrieve project details that include associated team information and, in the detailed view, the project's tickets. This change introduces new view models (ProjectVm, ProjectWithTeamIdsVm, ProjectWithTicketsAndTeamVm) and corresponding MediatR queries/handlers to fetch a project's ID, name, description, team names/IDs, and ticket list, enabling richer project context in the UI.

src/BugTracker.Application/Features/Projects · high confidence

Added application-layer queries (GetAllAccessibleTicketMembersQuery and GetCurrentTeamQuery) and their handlers to fetch team members associated with a project or specific ticket. These queries return a list of users along with their assigned roles, enabling the UI to display who has access to a ticket and what their specific permissions are within that context.

src/BugTracker.Application/Features/TicketTeam · high confidence

A new query and handler have been added to fetch all project members accessible to the current user, filtering and sorting them by their assigned role. This backend capability supports the UI requirement to restrict ticket creation to project members and provides the data source for the team selection interface.

src/BugTracker.Application/Features/ProjectTeam · high confidence

Administrators can now delete users, lock and unlock accounts, and assign roles through new application-layer commands and queries. The system supports paginated user listing with filters for locked status and missing roles, retrieves available roles, and fetches individual user details including their assigned roles.

src/BugTracker.Application/Features/UserManagement · high confidence

The application now supports paginated retrieval of projects via the GetAllProjectQuery. Non-admin users will only see projects they belong to, while admins can view all projects. The response includes a pager object to support pagination in the UI.

src/BugTracker.Application/Features/Projects/Queries/GetAll · high confidence

The application now includes pre-configured database seeds for both standard sample users (Admin, Developer, Project Manager, Submitter) and specific demo accounts (Demo Admin, Demo Developer, etc.). These configurations, located in the persistence layer's identity configurations, ensure that these users and their corresponding roles are automatically created in the database, allowing users to log in immediately without manual account creation.

src/BugTracker.Persistence/Configurations/Identity · high confidence

Users can now create new tickets by providing a name, description, estimated hours, priority, type, status, and an optional team. The system enforces strict input validation, ensuring the name is unique and under 30 characters, the description is under 100 characters, and estimated hours are between 1 and 100. Access is controlled by role: administrators can create tickets for any project, while submitters must belong to the target project's team. The implementation uses CQRS with MediatR, mapping the command to a domain entity and persisting it via the ticket repository.

src/BugTracker.Application/Features/Tickets/Commands/Create · high confidence

The application layer now defines a set of repository interfaces (IAsyncRepository, ITicketRepository, IProjectRepository, ICommentRepository, and ITicketConfigurationRepository) within the Contracts/Data namespace. These interfaces establish the contract for data persistence operations, including role-specific ticket retrieval (for admins, project managers, and developers), project team membership checks, and configuration lookups for statuses, priorities, and types. This change abstracts the underlying data storage mechanism, allowing the application services to interact with data through these defined contracts rather than direct database calls.

src/BugTracker.Application/Contracts/Data · high confidence

The application introduces a new repository interface for audit logs that includes a \ListAll\ method accepting page and search parameters. This change enables the backend to retrieve audit logs in paginated chunks rather than loading all records at once, which improves performance and usability when viewing large volumes of audit history.

src/BugTracker.Application/Contracts/Audits · high confidence

The audit logging system has been updated to resolve foreign key IDs into their corresponding display names (such as Project, Ticket, Status, Priority, Type, User, and Role) within the audit entries. Additionally, specific entity types like Tickets and Comments now include their associated Project and Ticket names in the log output, and user-related logs (password updates, email confirmations) are streamlined to show only relevant action types or usernames rather than full entity dumps.

src/BugTracker.Persistence/LogHelpers · high confidence

The persistence layer now includes explicit Entity Framework Core configurations for core lookup entities and many-to-many relationships. Default seed data is applied for Ticket Priorities (Low, Medium, High, Immediate), Statuses (New, Open, In progress, Resolved), and Types (Bug - Error, Feature request, Training, Documentation), ensuring these options are available immediately upon database initialization. Additionally, the configurations define the structural relationships for ProjectTeamMember and TicketsTeamMembers, establishing the necessary keys and foreign keys to support assigning users to projects and tickets.

src/BugTracker.Persistence/Configurations/Data · high confidence

The application now exposes dedicated Data Transfer Objects for project operations: CreateProjectDto and UpdateProjectDto carry the respective commands along with a list of team members, while ProjectTeamManagementDto and ProjectWithTeamDto provide structured access to project identifiers and associated user teams. These changes enable the UI and backend to handle project setup and team assignment with explicit team data in the request/response contracts.

src/BugTracker.Application/Dto/Projects · high confidence

The data access layer has been replaced with a new set of repositories (BaseRepository, TicketRepository, ProjectRepository, CommentRepository, and TicketConfigurationsRepository) that implement role-based filtering and search. Users now see only tickets and projects they are associated with, with search functionality filtering by ticket name, priority, status, type, project name, and assigned user. Project membership changes automatically update related ticket team memberships, and configuration data (priorities, statuses, types) is retrieved in a defined order.

src/BugTracker.Persistence/Services/Data · high confidence

The ticket overview now filters results based on the logged-in user's role: submitters see only tickets they created, admins see all tickets, project managers see tickets for their projects, and other users see tickets assigned to them. This change introduces a new query and handler that apply these role-specific filters while preserving search and pagination functionality.

src/BugTracker.Application/Features/Tickets/Queries/GetTicketsByUser · high confidence

The ticket deletion feature now checks user permissions before allowing a ticket to be removed. Administrators can delete any ticket, while Project Managers and Submitters can only delete tickets if they belong to the same project team. Other users can only delete tickets if they are part of the specific ticket's team.

src/BugTracker.Application/Features/Tickets/Commands/Delete · high confidence

Users can now update existing tickets through a new CQRS command handler that enforces specific business rules. Access is controlled by role: admins have unrestricted access, while project managers and submitters must belong to the ticket's project team, and other users must belong to the ticket's team. Additionally, developers are restricted from modifying the ticket name and description during an update, as these fields are locked to their current values. The update process also validates that the ticket name is unique and that all team member IDs provided are valid.

src/BugTracker.Application/Features/Tickets/Commands/Update · high confidence

The application's user identity model (ApplicationUser) has been updated to include FirstName and LastName properties, allowing for more detailed user profiles. Additionally, navigation collections for Tickets, ProjectTeamMembers, and TicketsTeamMembers have been added, enabling direct access to a user's associated bug reports and team memberships within the domain layer.

src/BugTracker.Domain/Identity · high confidence

The audit log query now correctly resolves user names and roles when displaying team membership changes. A new helper class processes audit entries to fetch user details via the identity service and correctly identifies user roles, ensuring that logs for ticket team assignments and removals display accurate user information and role context.

src/BugTracker.Application/Features/Audits/Queries · high confidence

The application is initialized with a multi-layer architecture (Domain, Application, Infrastructure, Persistence, and WebApp) targeting .NET 5.0. Key dependencies are configured, including Entity Framework Core for SQL Server persistence, AutoMapper and MediatR for CQRS patterns, FluentValidation for input validation, SendGrid for email services, and Azure Identity/Secrets for cloud integration.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• First survey — no prior run to compare against. CAI 31.

• Code Health 67
• Architecture 83
• Maturity 46
• Readiness 15
• Security 75
• Accessibility 28

• 264 commits — 222 feature/other, 42 fixes

• src/WebApp — 104 commits
• src/BugTracker.Application — 67 commits
• (repo) — 40 commits
• src/BugTracker.Persistence — 36 commits
• (root) — 11 commits
• src/BugTracker.Domain — 4 commits
• src/BugTracker.Identity — 1 commit
• src/BugTracker.Infrastructure — 1 commit

• fix: Fix display of ticket details modal when re-opened after closed in comment section.
• fix: Fix users pagination on delete.
• fix: Fixed "user" key bug in log dictionnary.
• fix: Fixed Database schema error.
• fix: Fixed a behavior preventing submitter to post tickets.
• fix: Fixed a bug were all modal were docked to the right after opening ticket detail modal.
• fix: Fixed a bug where demo project manager could not be added on project update.
• fix: Fixed a bug where project team members would not have access to project when creating log.
• fix: Fixed a bug where ticket team update weren't working as expexted.
• fix: Fixed a bug where updating project removed the PM when posted as a PM.
• fix: Fixed a bug with comments.
• fix: Fixed a display in the navigation.
• fix: Fixed a dupplication bug in log dictonnary.
• fix: Fixed admin and project manager tickets actions.
• fix: Fixed bug retrieving user role.
• fix: Fixed collapsed sidebar display.
• fix: Fixed features in user management preventing interaction from ui to controller.
• fix: Fixed last crud modal operations.
• fix: Fixed log display bug preventing to access data.
• fix: Fixed merging problem with audit branch.
• …and 244 more

• 2 HTTP endpoints (baseline)

• 2 containers · 0 bounded contexts · 0 dependency edges (baseline)

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

heliosCreation/Helios-bug-tracker was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.