Tested with Redmine 2.3.x, 2.4.x, 2.5.x, 2.6.x compatible with 2.x.

Application dependent from the redmine_app__space plugin.

"True" timesheet application, handling time spent on Orders rather than on issues, but still being capable of integrating that spent effort in the timesheet.

Rationale¶

Timesheet tools are applications useful to track spent time over project activities, work orders ('Orders' in the following, assuming that a project has economics that depend from a contract or internal assignment), general management and other unproductive activities, such as vacations, leaves, training.

Existing timesheet plugins for Redmine are based on the core time tracking capability which is able to record time spent on issues or, alternatively, into a project. Nevertheless, this is not completely satisfying for accounting purposes because:

• not every team is willing to represent Orders as an issue. Many teams use Redmine just to track bugs, and don't want to handle general activities, features, and their economics melted and confused into the same workspace
• general management and unproductive activities are shared company-wide, and their costs have to be monitored as such, so a project context is not sufficient for this scope

The Redmine Timesheet Application plugin implements a global application which includes an administrative part for enabling Orders and defining their visibility (edit own time only, view all times, edit all times) with per-Order granularity.

It allows to define brand new Orders, but also to reuse data about time spent on issues. Orders can be created globally, in the administrative interface, or into projects. In the latter case, they are represented by Target Versions shared with other projects. Both types can then be enabled or disabled administratively.

Sharing a Target Version won't disclose the existence of such a Version to people not belonging to the source project (except for admins) if a dedicated setting is configured.

Timelogs can be reported against issues belonging to a Version for project management purposes, and to a different Order for accounting purposes (even though Versions can be used as Orders too). The timelog values will be proposed as the easy option for accounting into timesheets too.

Order activities are disjoint from project activities too. The enumeration is the same, but the Order admin interface allows for a more granular configuration. A timelog can therefore be also reported with different Activities for PM and accounting purposes.

Redmine's spent time statistics can split for Orders and Order Activities too, orthogonally to Versions and Activities.

Global Orders are stored into a dedicated administrative project that does not need to be visible to users filling data into the timesheet: the issue tracking module needs not to be enabled on it.

Features¶

• time tracked over Orders, order activities and (optionally) issues without interfering with Versions and project activities on the same timelogs
• allows to track time on Orders independently from projects and issues
• administrative interface for Orders
• enabling Orders
• assign Orders to groups and users
• configure order activity enumerations per Order (enhances visibility management of shared activity definitions)
• support both custom-defined global Orders and Orders defined in projects as shared Versions
• assign permissions to individual users over each global Order: edit own times only (default), view other users' times, edit other users' time
• visibility permissions on Orders defined as shared Target Versions in projects are under control of the project's managers (usage as Orders is enabled in administrative interface)
• using the global app space plugin, therefore both the administrative and user interfaces can be enabled to selected user groups, and then enabled by them to show in the applications menu
• additional Order and Order Activity criteria in spent time reports
• daily and weekly view (the time span can be easily changed to arbitrary period via URL only currently)
• daily view manages all time entries and related comments; weekly view aggregates timelogs per Order + activity + (opt.) issue
• copy row values to the next period and forward to it
• delete a full row
• flag/unflag time spent on issues to be included or not into the timesheet
• previous period's non-empty rows are displayed into the next period too, for easing the handling of continued activities
• option to completely hide shared Versions to users not having visibility into the source project
• hours reported on Orders for which the user is not enabled any more are displayed in read only mode

Screenshots¶

Plugin Configuration¶

Configure the backing project which is an administrative-only one, and will not be visible to users.

Standard Redmine lists shared Target Versions to everybody (although they cannot be used by not project members). Nevertheless, a company may not want to disclose the existence of every Order to anybody at all. Unflag the entry 'Shared versions visible to non members' in order to keep Orders privacy.

Order management¶

Both global Orders, and Target Versions shared from projects can be enabled or disabled. Global Orders can be further configured.

Global Orders can be shared to projects and used with project issues for accounting purposes. They are hidden to unprivileged users.

Activity selection¶

The left pane of an Order's configuration page allows to select the activities associated to each specific Order. The set of activities selected for a global Order assigned to a timelog over a project issue has no relation with the issue's project activities.

User and Group Visibility¶

The right pane of an Order's configuration page allows to select individual users and/or user groups who are able to use the Order, and assign readonly/readwrite permissions over other users' timesheets for the given Order.

Redmine administrators and Orders administrators (those who can access the interface) always have Edit permission on every Order (marked with an angel icon).

Weekly View¶

The weekly view reports aggregated timelogs over an Order/activity/issue triple (issue can be missing). This means that each cell may sum values of two or more time entries, related to a specific day, into the same row. Changing the value will create a new timelog entry (if the cell was empty), or will change values or delete entries starting from the last one.

Shared Target Versions, their project and (if any) the issues are linked in the display.

The week view starts from monday to sunday around the current day. It is also possible to have different period length by changing the 'view' parameter on the URL to a numeric one. For a more detailed view of each entries, refer to the daily view (which is different from setting view=1). Clicking on a day label will bring to the related day view, or you may use the link in the contextual menu.

Entries in a row can be:

• deleted in one shot
• copied to the next period, if the next period is empty
• removed from the timesheet in one shot
• changed activity (after saving)

Daily View¶

The daily view reports every single timelog (even when having the same Order/activity/issue), and allows for commenting.

New Rows and Available Entries over Issues¶

A new row can be added contextually. Hours reported on issues through standard Redmine views can also be added to the timesheet, in order to ease the daily reporting process when already using standard facilities.

Orders and Versions can be mixed and matched freely as they belong to different domains even if they are derived objects. Also the Order Activity can be changed once the entry is recorded in the timesheet, without affecting the original activity set for project management purposes.

Continued Reporting¶

Entries that have values in the previous period are listed as empty in the following period too, in order to ease reporting of hours across subsequent periods.

Readonly Reports¶

Users can be enabled to inspect other user's timesheets in edit or readonly mode, on a per-Order basis.

For Orders created as shared Target Versions, permissions over timelogs depend on roles defined in the source projects and can therefore be managed by the project's managers with no need of admin intervention.

Individual rows are reported readonly also when an Order is not enabled for the user any more, yet some hours have been reported previously.

Spent Time Reports¶

Spent time can be categorized differently for Target Versions (for project management purposes) and Orders (for accounting purposes).

Furthermore, it can be categorized differently for Activities (for project management purposes) and Order Activities (for accounting purposes.

Install the redmine_app__space plugin first, then follow the standard Redmine procedure for this plugin, including database migrations.

Configure the plugin as described in the homepage.