1. Administration Checklist
- 1.1 General
- 1.2 People
- 1.3 Projects
- 1.4 Issue Tracking
- 1.5 Time Tracking
- 1.6 Dashboards
This manual refers to Easy Redmine and Easy Project version 14. The functionality of both products is almost identical, therefore the terms “Easy Redmine” and “Easy Project” are used synonymously throughout this manual.
Now that your application is installed and ready for use, it is time to prepare it for the structured management of your projects, issues, and other business processes.
With version 14, Easy Redmine / Easy Project has become even more flexible, modern, and powerful. The platform can be precisely adapted to any type of organization and working style — from small teams to complex enterprise environments.
Due to this high level of customizability, there are many corresponding settings and configuration options. This manual guides you step by step through the most important settings and helps you set up your system optimally.
In the following, logically structured checklist, we highlight the key configurations you should consider during setup. Additionally, we provide practical tips for fine-tuning to help you use all features effectively.
Whether you are just starting the setup or are already using a preconfigured Easy Redmine / Easy Project — we recommend going through this checklist completely. You may discover useful functions or optimizations that you previously missed.
1.1 General
1.1.1 Global Settings (General)
Go to: Administration > Settings > General
The user and time-tracking options are preconfigured and do not require adjustments.
- Application title – Name of the application. It appears in your browser and bookmarks as the site name, e.g., Easy Software Information System.
- Hostname and path – It is important that this address is correct. It is used in email notifications to generate links to your application. For example, a link to issue 123 will be generated as:
https://is.easysoftware.com/issues/123 - Start of fiscal year – This setting is used for date filtering (fiscal year, quarter). Very useful for reports and dashboards.
1.1.2 Global Settings (Display)
Go to: Administration > Settings > Display
Language – If all users speak the same language, we recommend enabling both language settings.
Date and time formats should be selected explicitly. If you keep “Based on user language,” you may receive “error” messages about inconsistencies.
1.1.3 Global Settings (API)
Go to: Administration > Settings > API
Enable JSON support – This checkbox must only be enabled if you intend to import or export JSON files.
1.1.4 Global Settings (Files)
Go to: Administration > Settings > Files
Define an appropriate maximum file size for uploads. Allowed extensions – whitelist: only these file types can be uploaded. Disallowed extensions – blacklist: all file types except these are allowed.
1.1.5 Global Settings (Email Notifications)
Go to: Administration > Settings > Email notifications
Notification email address (FROM) – We recommend using a general mailbox such as noreply@. This option is only relevant for Helpdesk projects with an integrated mailbox.
If you want users to be able to add comments to issues by replying to a notification email, you must enter an existing mailbox and connect it to the Helpdesk (if you have purchased a plan that includes this feature).
1.1.6 User Types
Go to: Administration > User types
Depending on the imported data, you will see one or more predefined user types. If multiple user types exist, first determine which ones you will actually use (less is more — only as many as needed and as few as possible). You should delete all unused user types so they do not appear as options when creating or editing user accounts.
During these initial steps, ensure that only relevant start menu items are enabled. There should not be too many entries, and only the most frequently used items should be included (because of smaller screen widths). When entering custom menu items, use relative paths, e.g., /issues, instead of https://is.easysoftware.com/issues
An important setting is the visibility of user types.
During initial configuration, you may allow each type to see all others.
If you do NOT mark a user type as internal, this results in:
- Non-internal users do not see buttons for issues, spent time, attendance, and resource management in their profile.
- Non-internal users do not see saved public filters — only their own private filters.
- Non-internal users do not see estimated hours on assigned issues nor in resource management.
- Non-internal users cannot see project activities, even if they have permission for the project.
- Non-internal users cannot log spent time and are not included in budget calculations.
- Administrators cannot be non-internal users, even if set in the profile.
Detailed technical documentation: https://www.easyredmine.com/documentation-of-easy-redmine/article/user-types
1.1.7 Export Templates
Go to: Administration > Export templates
This setting is initially negligible. However, if you work in a large company with a high level of corporate branding, it may be necessary to define branded export templates.
For list exports, you must use the dynamic token %query%, which is replaced in the export by the current list you are viewing (e.g., issues for invoicing, time tracking report, etc.).
Detailed technical documentation: https://www.easyredmine.com/documentation-of-easy-redmine/article/export-templates
1.2 People
1.2.1 Global Settings (Authentication)
Go to: Administration > Settings > Authentication
Authentication required – This is the default; users must log in to use the application.
Disabling authentication is intended for cases where your application serves as an open portal with public projects.
Through self-registration, you allow new visitors to create an account. The account must then be activated, either by clicking a link sent to their email or manually on the administration page (Users > filter by status Registered > Edit > Activate).
You can automatically assign self-registered users to a specific user group (Administration > Groups), which can be added as a project member with a specific role (more in chapter 1.2.3). This way, newly registered users receive defined permissions without needing to be manually added to projects.
Single Sign-On – If this option is available in your instance, please do not make any changes to its configuration. Single Sign-On is handled through the user management of the Cloudogu Ecosystem or the Bundescloud development platform.
Two-factor authentication (TOTP) requires external mobile apps (e.g., Authy, Google Authenticator) and can be configured easily. SMS authentication requires extended configuration of an SMS gateway connection to Easy Redmine / Easy Project.
Nevertheless, your users’ accounts are secure enough if you enforce strong passwords and an automatic session expiration. Two-factor authentication should only be used when required by official security policies.
Detailed technical documentation: https://www.easyredmine.com/documentation-of-easy-redmine/article/authentication
1.2.2 LDAP Authentication
Go to: Administration > LDAP Authentication
As with Single Sign-On: please do not change the configuration here.
Detailed technical documentation: https://www.easyredmine.com/documentation-of-easy-redmine/article/ldap-authentication
1.2.3 Users and Groups
Go to: Administration > Users > New User
Basic information for user creation:
- Login and email – must be unique.
- User type – determines the main menu and the visibility of other users.
- System group – checkbox for service accounts, e.g., for API integrations. Do not use this checkbox for regular user accounts.
- Administrator – sees and controls everything. Keep the number of administrators at a reasonable level.
- Sub-administrator – can access selected administration areas and perform all operations within that area.
- Authentication mode – select LDAP modes here if applicable.
- Time zone – if none is selected, the server’s time zone is used. If you use the cloud, you can find the server time at the bottom of the page /admin/info. We recommend setting an individual time zone for all users.
- Mail signature – especially important for helpdesk and sales staff who send messages from Easy Redmine / Easy Project to external customers.
Focus on user groups
Managing user groups is very simple: Administration > Groups > New Group. Name the group and add members after creation.
User groups simplify filtering tasks or spent time or any other entity – instead of selecting users one by one, you select the group. They also help with task assignment – assign a task to a group and allow its members to choose which specific user will take the task. Most importantly, groups offer quick/automatic assignment of members to projects. You only need to add the group to the respective projects under a specific role, and all users who are members of the group automatically become members of those projects. The same logic applies when removing members from groups. If you delete a group, all members of the group are removed from all projects where the group was assigned.
When setting up your application, you should create a few basic groups that will make future project member management easier.
1.2.4 Custom Fields
Go to: Administration > Custom fields > Users (or New custom field > Users)
In addition to system-defined attributes, you can add custom attributes (e.g., phone numbers, departments, job titles, etc.) that can take different types of values (boolean, text, number, etc.). These fields can then be used flexibly within projects (e.g., in tabs, sections, etc.). We recommend configuring only truly necessary attributes to keep project pages clear and organized.
Detailed technical documentation: https://www.easyredmine.com/documentation-of-easy-redmine/article/custom-fields
1.2.5 Page Templates
Go to: Administration > Dashboard customisation
All users have their own homepage – their personal dashboard/workspace. It is the first page you access when logging in and is always available in the main menu via the “Homepage” button. This page is customizable so that users see exactly what they need.
We recommend not allowing users to change their homepage during the first months (via roles and permissions – chapter 1.2.7). Users with the same position should have uniform homepages. Otherwise, they may make changes that disrupt their work (e.g., hiding tasks they should monitor). If you decide to create your own page templates, keep them simple. Set a reasonable limit for lists (between 10–15 items). Once you receive feedback, you can gradually optimize the pages.
1.2.6 Working Calendars
Go to: Administration > Working time – Templates > (New Calendar)
Working calendars allow you to define a work system for the entire company (Monday–Friday, 9 a.m.–5 p.m. with a 30-minute lunch break), specific calendars for part-time users, and even a fully custom calendar.
The assigned calendar determines time and attendance reports for each user.
Detailed technical documentation: https://www.easyredmine.com/documentation-of-easy-redmine/article/working-time-calendar
Notes:
- Work begins/ends at – the difference between these values is the total number of working hours per day (e.g., 8.5 hours). When using attendance features and half-day entries, the respective time blocks are pre-filled automatically.
- Number of working hours per day – how much time should be logged on tasks and projects per day. In our example, a 30-minute lunch break is included.
- Working days per week – here you define weekends.
- Default calendar – if this checkbox is enabled, this calendar is automatically assigned to all new users.
1.2.7 Roles and Permissions
Go to: Administration > Roles and permissions
If you have no roles yet, you must create a new one. This setting is quite complex because it affects many areas of the entire application. The most commonly used areas are: project, issue tracking, and time tracking.
Most permissions are self-explanatory. However, there are some general principles to highlight:
Global vs. Project Permissions
All special permissions fall into two main groups:
- Global permissions These permissions have no project context; they apply across the entire application. Example: Use issue list – this function is not tied to a specific project and can be used anywhere.
- Project permissions These apply only to the specific project in which the member holds the role. Example: Create issues – issues are always tied to a project. You cannot create an issue without a project.
For example: If you have the Management role in Project A and the Worker role in Project B, you can create issues only in Project A, because the Worker role does not allow issue creation.
Evergreen principle – Keep it simple
It is sufficient to start with three role levels: Top Manager, Team Leader, Team Member. Based on experience, you can later refine and create new roles for specific cases.
Special Roles – Non-member, Anonymous
In the list of roles and permissions, you will always see two roles that cannot be deleted: Anonymous and Non-member. As described in chapter 1.2.1 (Authentication settings), if authentication is disabled, the application becomes accessible without login. Users who are not logged in are considered “Anonymous”, and their permissions are defined by this role. If login is required, you can ignore this role.
Non-member – global permissions apply to all registered users. Project permissions apply to users who are not members of the project but are allowed to see it.
Both of the above roles can see public projects, and project permissions apply to them. Normal projects are not public, but you can choose to make certain projects public to make them accessible without adding users as project members.
What do the letters R, M and L stand for?
Next to certain permissions, you may see letters:
- R – Read only - You can view data but cannot create, edit or delete any data.
- M – Member - You must be a member of the project. This permission does not apply to the roles Non-member and Anonymous.
- L – Logged in - You must be logged into the application. This permission does not apply to the Anonymous role.
1.3 Projects
1.3.1 Global Settings (Projects)
Go to: Administration > Settings > Projects
- Default modules and issue types – Select only those that you are sure will be used for all projects. Otherwise, some simple projects may look more complex than they actually are. These settings do not affect projects created from a template.
- Activity is selected when creating an issue (or when editing an issue) – We recommend leaving this disabled, as otherwise problems may occur when creating/editing issues via Gantt, WBS or Quick Planner.
- Assign activities to roles – Useful in a very complex system. Leave this option disabled.
- Show custom project identifiers – Leave this option disabled; it is only used in very specific cases. If this option is active, the field serves as the unique identifier of the project and cannot be changed afterwards.
- Role assigned to the user who creates a project (subproject) – Make sure to select a role. Otherwise, the first role in the list is assigned. This defines which role the creating user will have within the newly created project.
- Calculate project start/due date from issues – This setting has advantages and disadvantages. If it is enabled, you do not need to worry about issue start and due dates;
you will not be warned if issue dates fall outside the project period, but you cannot filter and sort projects by date. If the option is disabled, you can filter and sort projects by date, but you will receive error messages if issue dates fall outside the project’s date range (e.g., when moving issues from another project).
1.3.2 Project Templates
Go to: Administration > Project templates
How can you integrate templates into your application?
From an existing project
Go to an existing project in your application: Settings > Edit > Create template from this project.
If the project contains subprojects, they will also become part of the template.
Import / export of templates
You can import or export a template under: Administration > Project templates
If you want to export a template from your system, click the gear icon of the respective template and then Export template.
If you want to import a project template you have as a file, click Import template in the top right corner of this administration section.
1.3.3 Project Priorities
Go to: Administration > Categories > Project priority
Assign priorities to maintain an overview of your project portfolio. The highest priority is 1. You can define an unlimited number of priority levels.
As a rule of thumb: a three- to four-level prioritization is sufficient for most portfolios.
1.3.4 Custom Project Fields
Go to: Administration > Custom fields > Projects (or New custom field > Projects)
Decide how you want to categorize your projects. Some commonly used examples are: Project phase (list), Shipping date (date), Project type (list)
Detailed technical documentation: https://www.easyredmine.com/documentation-of-easy-redmine/article/custom-fields
1.3.5 Project Overview Templates
Go to: Administration > Page customization > Project – Homepage
The project overview is the first page of a specific project. Below is an example of a project overview page.
The default page template is applied to new projects. Page templates can also be applied to existing projects.
From our experience, we recommend using the modules Project description and Project info on the overview page. Project members or subprojects can also be part of this page.
1.4 Issue Tracking
1.4.1 Global Settings (Issue Tracking)
Go to: Administration > Settings > Issue tracking
- Show issue ID – This is useful when working with smaller issues, as it allows faster and easier navigation and referencing of specific issues.
- Show subproject issues in parent projects by default – To keep the issue lists clear, we recommend disabling this. When you open an issue list for a project, only the issues of this project are displayed, no others. If necessary, you can always include issues from subprojects using a filter.
- Use color scheme for: – We recommend using Priority for color-coding issues.
- Allow setting the issue due date beyond the milestone date (milestone will be shifted accordingly) – This setting has an effect if you use milestones in your projects. If you enable this option, you will not be prevented from moving the due date of an issue beyond the date of its milestone. Instead, the milestone is shifted accordingly. If this option is disabled, users receive an error message if they set a due date for an issue that lies after the milestone date.
- Enable private issues – You can allow users to create issues that only they themselves can see. We recommend leaving this option disabled by default and discussing with the Project Management Office or experienced project managers or Scrum Masters whether this feature is really needed.
- Allow cross-project subtasks – To keep issue structures organized, you should leave this function disabled. To connect different issues across projects, you can use issue relations. The tree with parent and child issues should preferably remain within one project.
- Allow cross-project issue relations – A good alternative to the above setting.
- Allow issue assignment to groups – This only works if the group is added as a member of the project. If all group members are added individually, this will not work.
- Calculate percentage done using: Use issue field = Users manually enter the % done for the issue based on their qualified estimate. Use issue status = For each issue status, you define how much of the issue is considered done. For example: New = 0%, In progress = 50%, Review = 90%. With this setting, users cannot manually enter the % done.
- Ignore workflow for administrators – As you will soon see, workflow has a strong impact on how issues are handled. If you enable this setting, you risk administrators changing issues in ways that normal users can no longer work with them. We recommend leaving this setting disabled. Details on workflow can be found in chapter 1.4.4.
- Issue export limit – The limit applies to all exports, not only to issues. Keep this setting reasonable. Exporting complex lists from Easy Project with too many items can take a very long time. Additionally, the export process may affect the performance of the application for other users.
- Attributes of parent issues – To have more control over individual issues, these settings should remain independent. If you select attributes calculated from subtasks, users will not be able to set these attributes manually for the parent issue, which can lead to confusion.
1.4.2 Trackers
Go to: Administration > Trackers
If you are just starting with Easy Redmine / Easy Project to manage the regular work of a team of up to 25 members, you will not really need more than one tracker called Issue (or Task). Over time, you may find that you want to better differentiate the type of work your users perform.
A tracker can simply be understood as a type of work order, for example: Audit, Documentation, Architectural proposal, Construction, Workshop, Programming, etc. Trackers are fully customizable; you have complete control over them.
Attributes of a tracker
- Default status – When creating an issue of this tracker, this status is pre-filled.
- Icon – Used in Scrum/Kanban.
- Standard fields – Again, the rule “less is more” applies. A functional minimum is to enable: Assignee, Description, Start / Due date. Enable Parent task if you plan to create issue structures (e.g., parent–subtask hierarchies in the Work Breakdown Structure). Enable Estimated time if you plan work in resource management. % Done has a functional effect on Earned Value Management. For advanced project management, you will also use milestones, which are neatly managed in Gantt.
Trackers can be activated/deactivated per project and can have their own set of custom fields.
1.4.3 Issue Statuses
Go to: Administration > Issue statuses
Individually definable issue statuses make Easy Redmine / Easy Project such a powerful and flexible tool. Our experience from hundreds of customer implementations shows that an initial solution typically consists of four statuses:
New > In progress > Approved > Closed
We recommend starting with equivalents of these stages that you name according to your own practice. For the final stage, the option Issue closed should be checked.
1.4.4 Workflow
Go to: Administration > Workflow
Now that we are familiar with trackers and issue statuses, we can define the life cycle of an issue, i.e., how statuses can progress.
Workflow combines: the user’s role, the tracker and the current status of the issue and evaluates what project members are allowed to do with the issue.
Let us explain this using a simple user story:
Team members report to their team lead – their work must always be evaluated by the team lead.
This can be enforced through workflow, i.e., you forbid team members to close issues and allow them only to use the status Supervisor review to hand over their work. The team lead then has a queue of issues in this status from their team members, and only their role can close the issue.
In the workflow settings, this looks as follows: A team member has all options to close the issue disabled, while the team lead has this option available. Additionally, the team lead is allowed to reopen already closed issues.
1.4.5 Issue Priorities
Go to: Administration > Categories > Issue priorities
Priority is another mandatory attribute for each individual issue. The most common number of priorities is 3–5, for example: Urgent, High, Normal, Low. The most frequently used priority should be set as the default, in our example Normal.
To simplify matters, it is possible to allow only selected roles to assign or change issue priorities.
1.4.6 Custom Fields for Issues
Go to: Administration > Custom fields > Issues
Custom fields can be used in many places. Most commonly, they are found as additional attributes in issues and projects. Use them only where they are really needed to maintain clarity.
The following describes – as an example – the creation of a custom field for an issue.
- Required – If you choose this option, make sure to set a default value for this field. Otherwise, you make issue creation more difficult. Additionally, you would completely prevent issue creation via email (from the Helpdesk) or from an external system via the API.
- Use key/value list instead of regular list – The regular list is kept only for historical compatibility reasons. The key/value list works much better for adding, editing and deleting values.
- Used as filter – We recommend disabling this option. Too many available filters make working with issue lists more difficult and, in extreme cases, can slow down loading of issue lists.
- Show as additional attribute – This is useful for fields that are usually filled during issue creation (e.g., for categorization) but do not need to be changed during the life of the issue. With this option, the field is hidden under Edit more attributes when updating an issue, so that users can focus on the most important fields.
Detailed technical documentation: https://www.easyredmine.com/documentation-of-easy-redmine/article/custom-fields
1.4.7 Issue Filtering
Go to: Administration > Default filters > Issues
Here you configure the default filter – the default form of the issue list when opened by any user.
Be sure to set the filter Status – open, so that old, closed issues are not displayed.
Regarding the visible columns, you should consider the screen width of your project members. We recommend placing the issue name (Subject) in the first column, so project staff can access issue detail views as quickly and easily as possible.
Project members can then adjust the columns of the filter view ad hoc according to their own needs.
Go to: Administration > Manage saved filters > Issues
Here you can predefine other types of issue lists (including charts or pivot tables – reports). Saved filters are displayed in the right sidebar of the issue list or in the header.
There are many configuration options for issue sets so that you can adapt them to any possible use case. For a start, we recommend creating filters for: Overdue issues per user, or High priority issues per user.
1.5 Time Tracking
1.5.1 Global Settings (Time Tracking)
Go to: Administration > Settings > Spent time
First, we should clarify a few semantic questions. What are spent time, time tracking and time entry/entries?
- Spent time is a term for the entire concept/functionality of measuring the time that employees spend on projects.
- Time tracking refers to the act or process of measuring time. The first two terms can be used synonymously.
- A time entry is a single record with the following attributes, for example: Date: 2 August; User: Allison; Project: A; Issue: 123; Spent time: 2.5 h.
Approvals for spent time
Approvals mean that project members with sufficient permissions (chapter 1.2.7) can approve and reject time entries of project staff. When a time entry is approved, it gets the status “approved” and can no longer be changed (not even by an administrator). There are no email notifications for time entry approvals. This means that if you want to work with this feature, you should prepare some filters that show only not yet approved entries.
Limits
We recommend a reasonable limit for the past (around ~14 days), so that not too many values are shown. Logging time in the future should not be allowed at all (0). The daily limit is intended more for legal purposes, but a limit of 24 hours makes good sense.
Other settings
The most important settings are: Allow time tracking on closed issues (we recommend leaving this enabled), and An issue must be selected when logging time, which controls whether you are allowed to log time directly on the project or not.
1.5.2 Activities
Go to: Administration > Categories > Activities (Spent time)
Time activities are used as an additional dimension for categorization and for reporting.
Use exactly the category names that are understood by everyone in your organization. For example: Work and Meeting. Every time users do not have a meeting, they will log Work. This gives you an overview of how much of the day is spent in meetings.
We recommend creating as few categories as possible and as many as necessary – 4–5 categories is a good rule of thumb.
To force your users to select an activity, you can simply not set any activity as default – then no activity is preselected when time is logged.
1.5.3 Custom Fields for Spent Time
Go to: Administration > Custom fields > New (or New custom field > Spent time)
In the previous three chapters on custom fields, you learned everything essential about these fields. Here we only want to recommend that you do not make life harder for your users by marking custom fields as required.
Even better: try to avoid any custom fields for spent time altogether. There are already enough attributes you can use to filter/report on spent time: issue attributes, project attributes, user attributes, activities.
1.6 Dashboards
Go to: Administration > Page customization
In chapters 1.2.5 and 1.3.4, we already used this setting to manage the page templates My page and Project overview.
Now we will look at general dashboards that can be used for all types of cross-company overviews – in the following, we call them global dashboards.
You can create them completely from scratch by clicking the New page button.
Page properties
- Title – Name of the page.
- Identifier – Used as the URL (link) to the page. In the example in the screenshot, the URL would be:
https://is.easysoftware.com/easy_pages/hr-reports. - This is the link format for every global dashboard. Note that only users who know the URL can access the page. Apart from the global dashboard administration (which only administrators can access), there is no other place where these pages are listed automatically. Therefore, you must distribute the link to this page to the relevant users. One option is to add it as a custom menu item in the user type settings (chapter 1.1.6).
- Layout – The most flexible layout is Dashboard. Warning: once the page has been created, it is no longer possible to change the layout.
- Page scope – Leave this set to None. The other options can be used in a custom implementation but are not relevant at the moment. Once you have created this page, it is no longer possible to change the scope.
Most likely, when you are first setting up the application, you will not yet have a clear concept of the types of dashboards and reports you will be using.
This means that this configuration may only make sense after a few weeks of production use.
Do not spend too much time building dashboards with theoretical reports before you have sufficient data in the system.
