Developer documentation - run, develop, extend and build for Kimai

This page is for all developers who want to contribute to Kimai. You rock!

Setting up your environment

All you need is:

  • PHP >= 7.2.9
  • PHP extensions: pdo-mysql, intl, zip, gd, mbstring, xml
  • a MariaDB or MySQL instance
  • Composer

Development installation

Clone the repository and install all dependencies:

git clone
cd kimai/
composer install

You need to change your environment to dev and configure your database connection in your .env file:


The next command will import demo data, to test the application in its full beauty - with different user accounts, customers, projects, activities and several thousand timesheet records. Let’s bootstrap your database (command only available in dev environment):

bin/console kimai:reset-dev

Almost there!

Now you need to start a web server and can access Kimai in your browser. Its totally up to you how to achieve that, I can recommend the Symfony local webserver (it is fast and supports local https setup):

symfony serve --port=8010

You can now login with these accounts:

Username Password API Key Role
clara_customer kitten api_kitten Customer
john_user kitten api_kitten User
chris_user kitten api_kitten User (deactivated)
tony_teamlead kitten api_kitten Teamlead
anna_admin kitten api_kitten Administrator
susan_super kitten api_kitten Super-Administrator

Demo data can always be deleted by dropping the schema and re-creating it. The kimai:reset-dev command will do that automatically and can always be executed later on to reset your dev database and cache.

If you want to test with an empty installation, erase the database and re-create an empty schema:

bin/console doctrine:schema:drop --force
bin/console doctrine:schema:create

Frontend dependencies

If you want to make changes to CSS / Javascript, you need:

Please install Yarn for your OS and then:

yarn install

To rebuild all assets you have to execute:

yarn run prod

You can find more information here and here.


Beware: if you use the local.yaml then don’t put it in config/packages/ as all configs in there are used when running the PHPUnit testsuite.

The (integration) tests are written to work with the default configuration of Kimai and locally changed configs might unexpectedly break the tests.

Therefor put your local.yaml into the dev/ folder: config/packages/dev/local.yaml.

Tests suites with PHPUnit

Kimai tries to adopt a high test and code coverage. Whenever changing code, you have to make sure that the tests are still running. New code needs additional tests, otherwise your pull request might be declined.

You can run the unit and integration tests with built-in commands:

composer kimai:tests-unit
composer kimai:tests-integration

Or you simply run all tests with one of:

  • composer kimai:tests
  • vendor/bin/phpunit

Static code analysis via PHPStan

Besides automated tests Kimai relies on PHPStan to detect code problems.

composer kimai:phpstan

Coding styles

You can run the code sniffer with the built-in command like that:

composer kimai:codestyle

And you can also automatically fix the violations by running:

composer kimai:codestyle-fix

Be aware that this command will modify all files with violations in the directories src/ and tests/, so its a good idea to commit first.

Kimai code-styles are configured in .php_cs.dist.


Read more about languages and translations.

Extending the navigation bar

If you want to add your own entries in the navigation bar, you can subscribe to these events:

  • App\Event\ConfigureMainMenuEvent::CONFIGURE
  • App\Event\ConfigureAdminMenuEvent::CONFIGURE

And that’s how to use it:

use App\Event\ConfigureMainMenuEvent;
use App\Event\ConfigureAdminMenuEvent;
use Avanzu\AdminThemeBundle\Model\MenuItemModel;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;

class MyMenuSubscriber implements EventSubscriberInterface
    public static function getSubscribedEvents(): array
        return [
            ConfigureMainMenuEvent::CONFIGURE => ['onMainMenuConfigure', 100],
            ConfigureAdminMenuEvent::CONFIGURE => ['onAdminMenuConfigure', 100],

    public function onMainMenuConfigure(ConfigureMainMenuEvent $event)
            new MenuItemModel('timesheet', 'menu.timesheet', 'timesheet', [], 'fa fa-clock-o')

    public function onAdminMenuConfigure(ConfigureAdminMenuEvent $event)
            new MenuItemModel('timesheet_admin', 'menu.admin_timesheet', 'admin_timesheet', [], 'fa fa-clock-o')

For more details check the official menu subscriber.

Extending the dashboard with widgets

If you want to add your own widget rows to the dashboard, you can subscribe to the event:

  • App\Event\DashboardEvent::DASHBOARD

And that’s how to use it:

use App\Event\DashboardEvent;
use App\Model\Widget;
use App\Widget\Type\CompoundRow;
use KimaiPlugin\YourCustomBundle\Widget\Type\CustomWidget;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;

class MyDashboardSubscriber implements EventSubscriberInterface
    public static function getSubscribedEvents(): array
        return [DashboardEvent::DASHBOARD => ['onDashboardEvent', 200]];

    public function onDashboardEvent(DashboardEvent $event)
        $section = new CompoundRow();
        $section->setTitle('Section title');

            (new CustomWidget())
                ->setTitle('Custom widget title')
                ->setData(['foo' => 'bar'])


For more details check this dashboard subscriber.

Adding new widget types

You can add your own widgets via plugin by adding two classes:

  • a widget implementing \App\Widget\WidgetInterface
    • or for the lazy folks extending \App\Widget\Type\AbstractWidgetType
  • a widget renderer implementing \App\Widget\WidgetRendererInterface
    • if you want to use twig to render your widget, extend \App\Widget\Renderer\AbstractTwigRenderer

These widgets can now be injected to the Dashboard as explained above with the MyDashboardSubscriber.

Display widgets in your template

You can also use widgets in your twig templates like this:

{{ render_widget('DailyWorkingTimeChart', {'type': 'line', 'begin': 'monday this week 00:00:00', 'end': 'friday this week 23:59:59'}) }}
{{ render_widget('userAmountMonth', {'color': 'blue', 'icon': 'user'}) }}

Widgets are referenced by their ID.


Adding documents for invoice rendering

In the config kimai.invoice.documents, you can add a list of directories with the locations of your invoice document templates (read more).

Adding invoice calculator

An invoice calculator is a class implementing App\Invoice\CalculatorInterface and it is responsible for calculating invoice rates, taxes and taking care to aggregate all timesheet entries that should be displayed.

Every invoice calculator class will be automatically available, after refreshing the application cache with bin/console cache:clear. This “magic” happens in the InvoiceServiceCompilerPass, which finds the classes by the interface CalculatorInterface.

The ID of the calculator must be unique, please prefix it with your vendor or bundle name and make sure it only contains alpha-numeric characters, as it will be stored in a database column.

Translations are stored in the invoice-calculator.xx.xlf.

Adding invoice-number generator

An invoice-number generator is a class implementing App\Invoice\NumberGeneratorInterface and its only task is to generate a number for the invoice. In most cases you do not want to mix multiple invoice-number generators throughout your invoices.

Every invoice number-generator class will be automatically available, after refreshing the application cache with bin/console cache:clear. This “magic” happens in the InvoiceServiceCompilerPass, which finds the classes by the interface NumberGeneratorInterface.

The ID of the number generator must be unique, please prefix it with your vendor or bundle name and make sure it only contains alpha-numeric characters, as it will be stored in a database column.

Translations are stored in the invoice-numbergenerator.xx.xlf.

Adding invoice renderer

An invoice renderer is a class implementing App\Invoice\RendererInterface and it is responsible to convert an InvoiceModel (the actual data) with the use of an InvoiceDocument (the template file) into a downloadable/printable document.

Every invoice renderer class will be automatically available, after refreshing the application cache with bin/console cache:clear. This “magic” happens in the InvoiceServiceCompilerPass, which finds the classes by the interface RendererInterface.

Adding export renderer

An export renderer is a class implementing App\Export\RendererInterface and it is responsible to convert an array of Timesheet objects into a downloadable/printable document.

Every export renderer class will be automatically available when refreshing the application cache, thanks to the

Each renderer is represented by a “button” below the datatable on the export screen.

A simple example, which only shows the IDs of the included timesheet records could look like this:

use App\Entity\Timesheet;
use App\Export\RendererInterface;
use App\Repository\Query\TimesheetQuery;
use Symfony\Component\HttpFoundation\Response;

final class TimesheetIdRenderer implements RendererInterface
    public function render(array $timesheets, TimesheetQuery $query): Response
        $ids = array_map(function(Timesheet $timesheet) {
            return $timesheet->getId();
        }, $timesheets);

        $response = new Response();
        $response->setContent(sprintf('Included IDs: %s', implode(', ', $ids)));

        return $response;

    public function getId(): string
        return 'ext_array_dump';

    public function getIcon(): string
        return 'fas fa-file-code';

    public function getTitle(): string
        return 'Show IDs';

All you need to do is to register it as a service in the Symfony DI container.

Adding timesheet export renderer

Timesheet exporter (implementing the interface App\Export\TimesheetExportInterface) are almost the same as export renderer, except that they don’t have the methods getIcon() and getTitle().

If you already wrote an export renderer, all you need to add is the second interface and you can export the filtered data from the user and admin timesheet screen.

Be aware, that you should add more permission (eg. view_rate_own_timesheet) checks to these renderer, as they are available for every user!

Adding timesheet calculator

A timesheet calculator will be called on stopped timesheet records. It can rewrite all values but will normally take care of the columns begin, end, duration and rate but could also be used to apply a default description.

Timesheet calculator need to implement the interface App\Timesheet\CalculatorInterface and will be automatically tagged as timesheet.calculator in the service container. They will be found and used only if you add them to the service container.

The configuration for “rounding rules” can be fetched from the container parameter kimai.timesheet.rounding.

The configuration for “hourly-rates multiplication factors” can be fetched from the container parameter kimai.timesheet.rates.

Adding custom fields (meta fields)

See meta fields documentation.

Adding UserPreference

See user preferences documentation.

Adding custom meta tags, stylesheets or javascript

There are three available events which can be used to add your custom output to the rendered HTML:

  • App\Event\ThemeEvent::HTML_HEAD
  • App\Event\ThemeEvent::STYLESHEET
  • App\Event\ThemeEvent::JAVASCRIPT
class ThemeEventSubscriber implements EventSubscriberInterface
    public static function getSubscribedEvents(): array
        return [
            ThemeEvent::STYLESHEET => ['renderStylesheet', 100],

    public function renderStylesheet(ThemeEvent $event)
        $css = '<style type="text/css">body.login-page h3 { color:red !important; }</style>';

These events are trigger on all pages, including the security layout.

Adding permissions

New plugins usually ship with a set of own permissions. You should always assign these permissions at least to the ROLE_SUPER_ADMIN. By doing so, you register the permission in the system and they become available in the permission admin screen.

You register new permission through your plugins extension class, by using the PrependExtensionInterface:

namespace KimaiPlugin\YourBundle\DependencyInjection;

use Symfony\Component\DependencyInjection\ContainerBuilder;
use Symfony\Component\DependencyInjection\Extension\PrependExtensionInterface;
use Symfony\Component\HttpKernel\DependencyInjection\Extension;

class YourExtension extends Extension implements PrependExtensionInterface
    // ... other methods .... 

    public function prepend(ContainerBuilder $container)
        $container->prependExtensionConfig('kimai', [
            'permissions' => [
                'roles' => [
                    'ROLE_SUPER_ADMIN' => [

If you don’t register your permissions, your users will not be able to change them via the UI.

Adding system configuration

As plugin developer you can add your own sections to the system configuration screen by using a code like this:

namespace KimaiPlugin\YourBundle\EventSubscriber;

use App\Event\SystemConfigurationEvent;
use App\Form\Model\Configuration;
use App\Form\Model\SystemConfiguration as SystemConfigurationModel;
use Symfony\Component\Form\Extension\Core\Type\TextType;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;

class MySubscriber implements EventSubscriberInterface
    public static function getSubscribedEvents()
        return [
            SystemConfigurationEvent::class => ['onSystemConfiguration', 100],

    public function onSystemConfiguration(SystemConfigurationEvent $event)
        $event->addConfiguration((new SystemConfigurationModel())
                (new Configuration())

This assumes that your bundle uses its own Configuration (class) and registers its configs with \App\Plugin\AbstractPluginExtension::registerBundleConfiguration():

namespace KimaiPlugin\YourBundle\DependencyInjection;

use App\Plugin\AbstractPluginExtension;
use Symfony\Component\DependencyInjection\ContainerBuilder;

class YourExtension extends AbstractPluginExtension
    public function load(array $configs, ContainerBuilder $container)
        $configuration = new Configuration();
        $config = $this->processConfiguration($configuration, $configs);
        $this->registerBundleConfiguration($container, $config);

And your configuration class looking like this:

namespace KimaiPlugin\YourBundle\DependencyInjection;

use Symfony\Component\Config\Definition\Builder\ArrayNodeDefinition;
use Symfony\Component\Config\Definition\Builder\TreeBuilder;
use Symfony\Component\Config\Definition\ConfigurationInterface;

class Configuration implements ConfigurationInterface
    public function getConfigTreeBuilder()
        $treeBuilder = new TreeBuilder('your');
        /** @var ArrayNodeDefinition $rootNode */
        $rootNode = $treeBuilder->getRootNode();


        return $treeBuilder;

Adding API methods

Please have a look at the DemoBundle, it includes examples for an API controller with serialization.

There is also a (german) blog post that discuss the basics of adding a FOSRestBundle controller to your bundle: