Timesheet approval workflow design

Discussion forum about Anuko Time Tracker
Post Reply
Posts: 493
Joined: Wed May 26, 2010 5:55 pm

Timesheet approval workflow design

Post by Nik » Tue Feb 12, 2019 1:23 pm


I am trying to figure out if I can add a Timesheet approval feature to Time Tracker, with a simple workflow that would allow users to create timesheets, submit them for approval, and allow supervisors / managers to approve of disapprove them.

This thread is to collect your feedback on how to design it in a flexible manner, and also keep it simple to be realistic with regards to development and maintenance cost.

I am thinking of the following:
  • Create a Timesheet plugin, which can be individually turned on / off for each group or subgroup.
  • To keep timesheets flexible with ranges, allow any range to be used in a timesheet, and also allow for filtering by any attribute we allow in reports.
  • Although I call it Timesheet plugin, it should allow inclusion of expenses for approval as well.
  • User shall be able to create a new timesheet on the report display page, alongside with the Send by email feature.
  • All timesheets to be displayed on the timesheets.php page as a list with their status (not submitted, submitted, approved, disapproved).
  • A timesheet from the list could be clicked upon for display, and provide buttons to: delete, submit for users; approve, disapprove for supervisors. A supervisor should be able also to put a comment along with their action, for example, when explaining the disapproval situation.
  • Entries belonging to a submitted timesheet are locked and cannot be edited. Disapproved or not acted upon timesheet can be deleted, then time and expense entries can be edited as necessary, and a new timesheet created with new or modified entries,
  • Time and expense items should be added a timesheet_id field to identify them as belonging to a specific timesheet.
  • Integration with a client role: A config option (or a right) to be added to the client role, which determines whether or not a client is allowed to see unapproved entries. This needs some further research with regards to how to do it nicely. Question 1: does a client ever need to see unapproved entries? Question 2: client role is an awkward role implementation-wise. Research whether it needs a refactoring to keep complexities down. Question 3: apparently, a client has reports tab and timesheets tab now, correct? No workflow for client, right? Question 4: perhaps we only allow clients to see their approved timesheets?
OUT OF SCOPE THINGS: The following things were considered, but are currently out of scope to keep this iteration realistic. I understand that in some environments signatures are pretty important. If there is any commitment to this, we can probably do it as another iteration and a separate fundraiser, specifically for the task.

- Timesheet signatures, either digital, or physical (as fields in printouts or attachment uploads).

Timesheet database table layout:

Code: Select all

# Structure for table tt_timesheets. This table keeps timesheet related information.
CREATE TABLE `tt_timesheets` (
  `id` int(11) NOT NULL auto_increment,            # timesheet id
  `user_id` int(11) NOT NULL,                      # user id
  `group_id` int(11) default NULL,                 # group id
  `org_id` int(11) default NULL,                   # organization id
  `client_id` int(11) default NULL,                # client id
  `name` varchar(80) COLLATE utf8mb4_bin NOT NULL, # timesheet name
  `submit_status` tinyint(4) default NULL,         # submit status
  `submitter_comment` text,                        # submitter comment
  `approval_status` tinyint(4) default NULL,       # approval status
  `manager_comment` text,                          # manager comment
  `created` datetime default NULL,                 # creation timestamp
  `created_ip` varchar(45) default NULL,           # creator ip
  `created_by` int(11) default NULL,               # creator user_id
  `modified` datetime default NULL,                # modification timestamp
  `modified_ip` varchar(45) default NULL,          # modifier ip
  `modified_by` int(11) default NULL,              # modifier user_id  
  `status` tinyint(4) default 1,                   # timesheet status
  PRIMARY KEY (`id`)
Access right adjustments required for this feature to work properly:

User needs: view_own_timesheets, manage_own_timesheets.
Client needs: view_own_timesheets. In context of a client it means viewing timesheets generated for this client.
Supervisor needs: view_timesheets and manage_timesheets (on behalf of users with lesser roles) and approve_timesheets (for users with lesser roles).
Last edited by Nik on Fri Mar 08, 2019 2:59 am, edited 5 times in total.

Posts: 493
Joined: Wed May 26, 2010 5:55 pm

Re: Timesheet approval workflow design

Post by Nik » Wed Feb 13, 2019 3:03 pm

I have now finished (mostly) working on this feature, so Timesheets are actually ready for use (as a Timesheets plugin).

I had to make some significant design changes though. Below are most important things:

1) Only time log entries get to timesheets. No expenses. At first I though, what the hell, let's do expenses, too, but there is a reason these things are called TIME sheets, not EXPENSE sheets, right? Also keeping scope smaller.

2) After playing with access rights for a while, I downsized rights set and piggy-backed on track_own_time and track_time rights, reusing them for timesheet access too. Thinking that when user can track time, they can compile a timesheet, too. This allowed me to keep a rights list reasonably small. However, to approve manager timesheets, I had to also introduce approve_own_timesheets right, by default assigned to managers.

3) Clients and timesheets do not belong together, so I excluded clients from any access to user timesheets. This simplified things significantly, specifically allowed me to use the "on behalf" mechanism for timesheet display, which did not fit with clients at all.

4) Most importantly, I implemented an additional (and completely independent from timesheets) report approval mechanism as a separate plugin, Some info on this plugin is here.

5) Email workflow works like this. After creating a timesheet, user can "submit" it. This changes timesheet status in database. If there are superior users with defined emails, and with a capability to approve (approvers), user is also presented a dropdown to select ONE approver to send an email to along with a submit operation. An approver can approve / disapprove on timesheet view, using controls underneath. If a submitter user has email defined, then an email is sent to them with a message indicating the result and with an optional comment.

I should probably document the entire thing in detail on a more appropriate place. Will do so soon, hopefully.

Post Reply