Users

Permissions

The permission system is configurable through user roles. Find further information in the permissions chapter.

Teams

A user can be part of a team, which can limit/extend the visibility of data. See the team documentation to find out more.

Avatars

There are three type of user avatars:

  • Self chosen: user configures an avatar URL in its profile (e.g. to Github, Google, Youtube, Dropbox, Gravatar and many other sources. Make sure to explain the privacy implications when using this method.)
  • Auto generated avatar: colored background + username initials (required dependencies: gd extension with freetype-support + write permission on avatar directory)
  • Fallback avatar: a static icon, which will be used if the user didnÄt choose a custom icon and the avatar generation failed

Roles

There are four pre-defined roles in Kimai, which define the ACLs/permissions.

Role name Description
ROLE_USER Normal user can track their working times, see basic reports and change their own preferences
ROLE_TEAMLEAD Manages teams with permissions for invoices and access to all team timesheets
ROLE_ADMIN Can manage all content and timesheet related data, but lack user administration and system privileges
ROLE_SUPER_ADMIN Has permissions to manage everything in Kimai, from content to timesheets to users, plugins and system configurations

The applied permissions of your Kimai installation can be seen via the user administration, e.g. https://demo.kimai.org/en/admin/permissions.

Creating new roles

If the pre-defined roles are not sufficient for your use-case and you need more roles, you can create new ones.

Kimai 1.6 and above

Every user with the permission role_permissions can create new user roles through the user administration. Navigate to the user role permission screen and check the pages action.

There is a button that will open a new modal, to enter a role name. This new role will show up in the table after saving.

By clicking the Yes and No labels, you can toggle all permissions.

If you created new roles through the local.yaml before, please remove them and use the admin screen exclusively.

Kimai 1.5 and below

Lets create the new role ROLE_SALES by editing your local.yaml:

kimai:
    permissions:
        sets:
            ROLE_SALES: ['@ROLE_USER', '@TAGS']
        maps:
            ROLE_SALES: ['ROLE_SALES']

security:
    role_hierarchy:
        ROLE_SALES:       ~

The search drop-down supports filtering by the fields:

  • role
  • state (active, deactivated, all)

Besides these filters, you can query for a free search term, which will be searched in the fields:

  • username
  • alias
  • title
  • email

Additionally you can filter for user preferences by using a search phrase like location:homeoffice. This would find all users with the custom field location matching the term homeoffice.

The search terms will be found within the full value, so searching for office would find:

  • I love working in my office
  • Office
  • This office is beautiful
  • Our offices are very noisy

You can mix the search term and use multiple meta-field queries:

  • location:homeoffice hello world - find all users matching the search term hello world with the user-preference location matching the term homeoffice
  • location:homeoffice contract:foo foo - find all users matching the search term foo with the user-preference combination: location matching the term homeoffice and contract matching the term foo
  • location:homeoffice contract:foo - find all users with the user-preference combination: location matching the term homeoffice and contract matching the term foo

User registration

User registration with instant approval is activated by default, so users can register and will be able to login and start time-tracking instantly.

If you want your new users to use email verification add this to your local.yaml:

fos_user:
    registration:
        confirmation:
            enabled: true

If you want to disable the user registration, add this your local.yaml:

kimai:
    user:
        registration: false

If you only want to hide the link from the login form but keep the functionality, add this your local.yaml:

admin_lte:
    routes:
        adminlte_registration: ~

Password reset

The reset password function is enabled by default, but you need to activate email support if you want to use it.

If you want to disable the password reset, add this your local.yaml:

kimai:
    user:
        password_reset: false

If you only want to hide the link from the login form but keep the functionality, add this your local.yaml:

admin_lte:
    routes:
        adminlte_password_reset: ~

If you want to configure the behaviour (like the allowed time between multiple retries) then configure the settings:

  • in config/packages/fos_user.yaml the key below fos_user.registration.resetting (see documentation)
  • the values retry_ttl and token_ttl are configured in seconds (7220 = 2 hours)

Login

  • User can login with username or email
  • If you activate the Remember me option, you can use use the most common functions within the next days without a new login

Kimai uses the FOSUserBundle for security related tasks like user management. Its configuration can be found in fos_user.yaml.

Remember me login

If you have chosen to login with the Remember me option, your login will be extended to one week (default value). After coming back and being remembered you have access to all the following features:

  • view your own timesheet
  • start and stop new records
  • edit existing records

If you are an administrator, you will see all your allowed options in the menu, but will be redirected to the login form when you try to access them. This is a security feature to prevent abuse in case you forgot to logout in public environments.

The default period for the Remember me option can be changed in the config file security.yaml.

Session lifetime

If you want to change the session lifetime, you have to configure the framework configuration in config/packages/framework.yaml and add the key framework.session.cookie_lifetime.

So something along the lines:

framework:
    session:
        handler_id:  session.handler.native_file
        save_path:   "%kernel.project_dir%/var/sessions/%kernel.environment%"
        cookie_lifetime: 60

See also: Symfony documentation