# dewakoding-project-management puts ticket tracking on top of Filament 4

> SeptiawanAjiP/dewakoding-project-management is an MIT licensed PHP application built with Laravel 12 and Filament 4 that tracks tickets against projects, with ticket prefixes, custom statuses, epics, a Kanban board, a timeline, role based access through Filament Shield and a client portal. The README is unusually complete on installation, and unusually candid about the Filament 3 to 4 upgrade.

**SeptiawanAjiP/dewakoding-project-management** — Project management tool built with Laravel Filament 4 for simple and efficient task tracking.

- Repository: https://github.com/SeptiawanAjiP/dewakoding-project-management
- Stars: 645 · Forks: 210
- Language: PHP
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/septiawanajip-dewakoding-project-management

## Projects are the unit, and each one has its own ticket prefix

The application is a Laravel Filament 4 project for managing projects with ticket management and status tracking, and the feature list shows the shape of the domain. A project carries a ticket prefix configuration, so the identifiers in one project do not collide with those in another, and each project has its own team members with role assignments. Tickets carry assignees and due dates and unique identifiers, and their statuses are customizable with colour coding, which is what makes a board view meaningful. Around that core sit epics for grouping tickets into larger initiatives, a comment system for team discussion, a user contributions chart, a leaderboard for team member performance, CSV export of ticket data, and an external dashboard view called the Client Portal. The audience is a development team that wants its own instance rather than a hosted service, and the Filament 4 base means the admin interface is generated from the data model rather than hand built.

## The board, the timeline and epics are the three views that matter

Three of the main features are described at length, and they answer three different questions. The Board View offers a familiar kanban style interface for ticket management, with drag and drop of tickets between status columns, columns that you customise to match your team's process, and quick edit functionality for updating tickets directly from the board. The Timeline provides a chronological perspective, visualising the project roadmap with start and end dates, tracking milestone completion across time periods, and making it easy to identify scheduling conflicts or resource bottlenecks. Epics help organise related tickets into larger initiatives, grouping by feature, release or business objective, tracking progress across multiple tickets, setting start and end dates for planning purposes, and showing which tickets belong to which initiative. The comment system is the fourth piece: team members discuss tickets inside the application, all comments are timestamped and attributed to users, rich text formatting is supported, and the point is to keep context next to the work rather than in a separate chat.

## Filament Shield turns the permission model into generated policies

Role based access control is handled with Filament Shield, and the install steps show that it is a first class part of the setup rather than an optional extra. Three commands activate it:

```bash
   php artisan shield:setup
   php artisan shield:install
   php artisan shield:super-admin
```

The upgrade section is where the project is most useful to an evaluator, because it shows what a Filament version bump actually costs. The project has been upgraded to Filament 4, and the README asks you to back up your database before starting, then to read the official Filament Shield upgrade guide first. After updating dependencies and following that guide, you run a single command to regenerate the Shield policies and permissions:

```bash
php artisan shield:generate --all --option=policies
```

Some upgrade steps related to filament-shield have already been implemented in the codebase, and the README is explicit that the command is what ensures all policies and permissions are properly generated for Filament 4 compatibility. The post-upgrade verification is a short checklist: clear all caches with php artisan optimize:clear, test the role based permissions, verify that all resources, pages and widgets are accessible, and check that user roles and permissions are working correctly.

## Ten steps from a clone to a running admin panel

The installation section is the most complete part of the README, and it is a Laravel application being set up by hand. First you clone the repository:

```bash
   git clone https://github.com/SeptiawanAjiP/dewakoding-project-management
   cd dewakoding-project-management
```

Then the dependencies, both PHP and JavaScript:

```bash
   composer install
   npm install
```

Then the environment file and the application key:

```bash
   cp .env.example .env
   php artisan key:generate
```

The database is configured in the .env file, and the README gives the exact keys:

```env
   DB_CONNECTION=mysql
   DB_HOST=127.0.0.1
   DB_PORT=3306
   DB_DATABASE=dewakoding_project_management
   DB_USERNAME=root
   DB_PASSWORD=
```

After that come the migrations, the storage link for file uploads, and the creation of the first Filament user with php artisan make:filament-user, then the Shield commands, then npm run dev to compile the assets and php artisan serve to start the development server. The requirements are PHP greater than 8.2, Laravel 12, Composer, and Node.js with npm. Usage then starts at the admin panel on http://localhost:8000/admin, where you log in with the Filament user, create a project with a custom ticket prefix, add team members, create and customise ticket statuses, and add tickets assigned to those members.

## Google OAuth is configured by hand in the cloud console

The application supports Google OAuth login, and the README documents the setup as a numbered walkthrough through the Google Cloud Console. You create or select a project and make sure the project is active, enable the Google+ API from the APIs and Services library, and then create OAuth 2.0 credentials of type Web application. The redirect URIs are the part that has to match your deployment, and the README gives both the local and a production shape:

```bash
     http://localhost:8000/auth/google/callback
     https://yourdomain.com/auth/google/callback
```

The client ID and client secret are then copied into the environment file, where the .env.example file reserves two keys for them:

```env
GOOGLE_CLIENT_ID=your_google_client_id
GOOGLE_CLIENT_SECRET=your_google_client_secret
```

That is a fairly standard OAuth setup, and the two entries to check are the redirect URI list in the console and the pair of keys in the environment, since a mismatch between them is the usual cause of a login that redirects and never returns.

## Docker brings up the app, nginx, MySQL and phpMyAdmin

The repository ships a compose file and a Dockerfile, so the alternative to the manual install is a four service stack. The application service builds from the local Dockerfile and mounts the working tree into the container along with a local PHP ini file, the nginx service publishes port 8000 and takes its configuration from the nginx/ directory in the repository, the database service is MySQL 8.0 with a persistent volume, and a phpMyAdmin service is published on port 8080 for looking at the data. The Dockerfile is a PHP 8.3 FPM image with the extensions the application needs installed by hand, including pdo_mysql, mbstring, exif, pcntl, bcmath, gd, intl and zip, and it copies Composer in from the composer image before the application code. The compose file also names the environment variables it expects, DB_DATABASE, DB_PASSWORD, DB_USERNAME and DB_PORT, which is the same set the .env file carries.

## The environment file shows the defaults you will inherit

Reading the .env.example is a fast way to understand what the application assumes. The application name is Project Management, the environment is local, debugging is on and the timezone is Asia/Jakarta, with English as the locale and fallback locale. Sessions are stored in the database with a lifetime of 120 and encryption off by default, the cache store is the database and the queue connection is the database as well, which means a MySQL instance is not optional in practice. Mail is configured to log rather than send, so a local install does not need a mail server. There is also an AWS block with access key, secret, region, bucket and a path style endpoint flag, which suggests object storage is a supported place for file uploads alongside the local disk, and the Filament application name is passed to the front end through a VITE_APP_NAME variable. The front end itself is a Vite build with Tailwind 4, and the package manifest has only two scripts, vite build and vite dev.

## The alternative is a hosted tracker, or Filament on your own model

There are two other ways to solve the same problem, and the difference in approach is instructive. The first is a hosted service, which gives you support, mobile clients and notifications for nothing in engineering time, at the cost of your data living on someone else's server and the workflow being whatever they decided. The second is to start from Filament itself and define only the resources you need, which gives you a generated admin interface with none of the domain decisions in this repository, such as the ticket prefix scheme, epics, the client portal or the leaderboard. This application sits between the two. It is a complete, opinionated implementation of a development tracker built on Filament, with the domain model already decided, which is exactly what you want if your process resembles the one described and exactly what you do not want if it does not, because you would be reshaping the data model and the panel at the same time. The README gives no sign of a public roadmap or a release cadence, and the repository has no GitHub releases, so the version you get is the version in the repository.

## Conclusion

Adopt dewakoding-project-management if you want a self-hosted ticket tracker that already speaks the Filament idiom, with projects, epics, custom statuses, a Kanban board and a timeline built in, and if you are starting a new deployment rather than migrating one. Do not adopt it to replace an existing tracker without reading the upgrade notes, because the jump from Filament 3 to Filament 4 requires regenerating the Shield policies and permissions, and the README asks for a database backup first. Before you deploy, decide whether the default MySQL and session configuration suits you, check the Google OAuth redirect URIs you need to register, and read the privileges the client portal is meant to expose.

## FAQ

### What does dewakoding-project-management do?

It is a Laravel Filament 4 application for managing projects with ticket management and status tracking, with ticket prefix configuration per project, customizable ticket statuses with colour coding, epics for grouping tickets, assignees and due dates, a Kanban board view, a timeline view, CSV export and an external client portal view.

### How do I install dewakoding-project-management?

Clone the repository, run composer install and npm install, copy .env.example to .env and run php artisan key:generate, point the database keys at your MySQL instance, then run php artisan migrate, php artisan storage:link, php artisan make:filament-user, the three shield commands, npm run dev and php artisan serve. The requirements are PHP above 8.2, Laravel 12, Composer and Node.js with npm.

### What do I have to do to upgrade from Filament 3 to Filament 4?

Back up your database, update your dependencies, follow the official Filament Shield upgrade guide, and then run php artisan shield:generate --all --option=policies to regenerate the policies and permissions. Afterwards clear the caches with php artisan optimize:clear and verify that resources, pages and widgets are still accessible.

### How is Google login configured in dewakoding-project-management?

You create OAuth 2.0 credentials of type Web application in the Google Cloud Console, enable the Google+ API, and register the redirect URIs, for example http://localhost:8000/auth/google/callback and the https equivalent for your domain. The client ID and secret then go into the GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET keys in the environment file.

### Does dewakoding-project-management run with Docker?

Yes. The compose file defines an application service built from the local Dockerfile on php:8.3-fpm, an nginx service published on port 8000, a MySQL 8.0 service with a persistent volume, and a phpMyAdmin service on port 8080, all on a shared bridge network.

## Sources

- [Issues](https://github.com/SeptiawanAjiP/dewakoding-project-management/issues)
- [License: MIT](https://github.com/SeptiawanAjiP/dewakoding-project-management/blob/main/LICENSE)
- [README](https://github.com/SeptiawanAjiP/dewakoding-project-management/blob/main/README.md)
- [SeptiawanAjiP/dewakoding-project-management on GitHub](https://github.com/SeptiawanAjiP/dewakoding-project-management)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/septiawanajip-dewakoding-project-management