Drupal 7 port of Time Tracker

Hey mradcliffe,

That would be awesome. The co-maintainer of this module has been out of country for the last few months and I've been swamped with other duties so the issue queue and plans for D7 have languished. I'm actually hoping to start devoting more time in the next couple of weeks so timing is perfect.

The only change that we had touched on in conversations was abstracting the time entry handling into an API of sorts, but we didn't get that far.

Let me know when you get the sandbox setup!

I would love this for D7. I used it in a couple D6 projects on OA, but have since moved in another direction. I am especially interested in the timesheet functionality. I can help with the port, upgrade, and testing. Has anything been done yet, or is it still in the planning phase?

No worries. I am starting work on the initial port as we speak :)

So here is a start. So far i have only worked on the time_tracker module.I havent touched timer, sheet, or estimate.

1. Tracking time on nodes seems to work pretty well.
2. Tracking time on comments is kind of hosed.
3. CSS needs updating
4. There are plenty of coding standards issues, I'm aware...

This patch is against the current master.

I will continue to work on this... but i thought i would share the progress so far, so that anyone that wanted to help, would have a head start.

I've got the time sheet module ported except for the case tracker stuff. One of the things I loved about time tracker was the timesheet and the case tracker integration form. That way users could add time to cases from the timesheet. But judging by this article it looks like atrium may be abandoning case tracker in its current form. Although it looks like case tracker is being ported to D7, its being done so by the community and not the maintainers #678838: Case Tracker - Port to Drupal 7.

I think we could further extract the case tracker integration, and make some general assumptions based on the way case tracker (and most other project management systems) work.

For example:

1. Most PM systems assign "cases" or "tasks" to users.
2. Cases or tasks usually belong to a larger entity like a "Project."

So what if we had some settings where the we could pick which entity types are considered the "projects" and "tasks." We then have a settings that picks the user/entity reference field on said "task" type that indicates who the task is assigned to.

With this information we can replicate the environment that case tracker provided to time tracker.

Thoughts?

The way that i am planning on using this module, is with entities, and i have already turned time entres into entities. i have also fixed the views stuff, and gotten timesheet sort of up to snuff.

I will try rolling a patch later tonight.

Hey Guys,

Sorry, I wasn't following this issue for some reason so I had no idea this stuff was going on! Thanks for all your work on this project. Please roll the patch when you're ready and I'll give it a test.

Thanks!

1. Here you go. Its not the prettiest, but its mostly functional. This patch is against the current master. The entity stuff came from the Examples module. I'm still not quite up to snuff on all things entity, but getting there.
2. Some of the comment stuff needs work.
3. I moved timer into its own folder, like the other sub-modules. I havent yet started timer, as the project I'm working on doesnt need it, nor did i touch estimate.
4. The views api stuff is mostly working except for the total duration thing...
5. The css will need to be cleaned up, as field id's and classes have changed.
6. As for timesheet:
   • I outlined above what i think a way forward should be for the timesheet / casetracker stuff.
   • For the time being, i have hard coded the configuration for my project (just as an example) so i will detail what i am doing:
     1. I have 2 content types, Project and Task.
     2. Tasks have a node reference to Projects (field_task_project).
     3. Tasks have a user reference to pick the user who is assigned to the task(field_task_assigned).
     4. Users only have visibility to tasks they are assigned to via Node access user reference.
     5. Users then track time on Task nodes, not comments.
   • This is only an example usage of what i outlined above.
   • I have also reworked the week start / week end thing. I always had an issue with the way the week was defined. It used to be that if the week was scheduled to start on monday, but all days were shown on the timesheet, sunday would show up at the end of the timesheet, and be for the sunday that came before the monday that the week started.
     Now it work like this: if the week starts on monday, and all days are displayed, the sunday that is displayed at the end of the timesheet would be the sunday after the monday that started the week, not the sunday before the week start.

Here is a zip file of the project. It should be easier to view and understand seeing as i re-arranged the file structure a little.

Nice one @chertzog! Thanks for the zip. Definitely easier. =P

I'll give this a test this weekend and report back!

Hi,

I got a chance to test this out yesterday. It's a great start! However, I can't seem to save time entries. Should I be able to? I'm getting a Fatal Error: "Fatal error: Function name must be a string in /home/chris/www/tt7/public/includes/form.inc on line 1443". I looked at the code but didn't have enough time to troubleshoot. Also, the time sheet doesn't work for me at all. Getting a few different php errors (although I think you mentioned you had some things hardcoded for your setup...)

So far though, based on what you've told me, it seems like it's on the right track. I think starting with just time tracker and time sheet is fine. The time estimate and the timer should be easy enough to upgrade once time tracker itself is working properly. The next steps, for me, would be to start pulling some of the fields out of time tracker and adding them as entity fields. Ultimately I think every time tracker field should be an entity field, just some of them wouldn't be configurable (duration, timestamp etc). Also, we should discuss the idea of how to handle duration vs. time interval based time tracking. @mradcliffe mentioned using different bundles. It might be a good idea, but we should discuss it a bit more.

Yes, I had hard coded a few things in timesheet because of my immediate needs (custom field names are hard coded into some queries, so yeah there would ne no way it would work). Though you should be able to track time. I dont think i hard coded anything in time tracker. Were you tracking time on nodes or in comments? The comments thing is still broken, as i wasnt planning on using it for my project at the moment.

As for fields, I had set up a psuedo field to show on the field configuration form for the time tracking form itself. But if we want to break them into their own fields that can be done.

The different bundles thing could work. We would just have a couple different fields on the different bundles.

I was tracking time on nodes... Hmm... I'll give it another go sometime in the near future.

Anyway, I've added you as a maintainer of time tracker so you can push changes now to the 7.x-1.x branch as you move forward. =)

So I have gotten a little free time to work on this again. As @mradcliffe state in #2 we have a couple options for D7.

He proposes "activity" bundles and time configuration by bundle. As well as turning most of the other fields into Field API fields or entity references.

As for the bundles by activity, I'm not so sure. I would think that the way that an organization tracks time would either be a set way for the entire organization, or configurable by user (the organization doesn't care). I dont think that most organizations (web development for example) would track time via duration for coding and via start/stop for design. My vote on this would be a global option as it is now, with a setting to allow user configurable option(we could add the option on their account edit form).

I think the Field API fields and entity reference path is a great one! This means we could in theory track time on ANY entity, taxonomy terms, nodes, comments, users... Plus with EntityFieldQuery(not having to worry about joins/tables) we could turn almost every field into a Field API field.

Entity reference fields:

• User - User ref
• Entity (where we are tracking time)
• Comment - Comment ref

Boolean:

• Billable
• Billed
• Locked

Date module fields:

• Start
• End
• Timestamp

Longtext:

• Notes

Integer:

• Duration
• Deductions

We could almost eliminate the schema. I know this may be a little overboard, but we are still in the planning phase. Thoughts?

I agree about the bundles by activity. Let's forget that for the time being.

I'm divided on using Entity Reference fields... Sure it would be great to log time on any entity, but how do we get the time tracking form "on" that entity? Right now it's easy to know where to put the time tracker form because it's only on nodes or comments... Maybe it will just work though. In my head it seems like it's going to be a headache but I don't know for sure.

I think turning as many fields as possible into Field API fields is good. The only thing is, if we're going to turn them all into Field API fields, we may as well just make it a custom node type and bundle it as a Feature with some views and custom code... Hmm... that's not a bad idea actually... Consider what you described above. Every field is essentially an existing field type already. There's no reason you couldn't just make a time_entry content type with all those fields. Then all you need is a little custom code to handle where to put/embed the form... It's at least worth discussing. What does our time tracking entity bring to the table that makes it any different than a custom node type with some views (and maybe views calc)?

The feature thing is interesting and at least worth a discussion. In my project i described above, i have already removed most of the default time tracking list tables (on nodes/comments), and just replaced them with views... Though with the rest of the time tracker project (time sheet, timer, estimate), not sure those are feature material.

I like the idea of turning it into a "custom content type" with all fields being Field API, cause then you could utilize things like field permissions, conditional fields, out of the box views support, rules, and features...

As for how to get the form "on" an entity, what about hook_entity_view. We were already using hook_node_view in D6, and in my D7 port above.

I agree that turning entries into node or entities is less efficient, but the drop in efficiency is coupled with a huge increase in flexibility. Turning all of the fields into Field API fields and using a couple default views, would let us eliminate a LOT of code. We wouldn't need to manage most of the views includes or handlers anymore. We could strip out all of the theme functions that create the tables of of entries to be displayed on nodes/comments. and just include a couple default views (Plus you may have heard, Views is headed for Core).

I think that we should define our own entity, and populate it with Field API fields, leveraging an entity reference field to store the ID of what we are tracking time on.

I think @mradcliffe was specifically talking about all the overhead that comes with nodes, and I have to agree a little bit. While turning the time tracker records into entities is definitely the way to go, turning them into nodes is probably not the best idea (even though I suggested it first =P). I think we're all on board with the new entity idea anyway, so we're definitely good to go ahead on that.

I'm okay with using the entity reference field, except for one thing... Right now, you can install time tracker and be tracking time on a node with one simple checkbox on the content type configuration page. After that, the form is added to the node and you're good to go. I would like the D7 version to be as easy, if possible. I don't want it to be one of those modules that gets installed, then you have to configure 10 different things before you can start using it (views, contexts, reference fields etc.). As much as I want flexibility, I would also like some out of the box functionality. Thoughts?

Lastly, I think a few fields need to be mandatory 'core' time tracker fields (kind of like 'title' on nodes): timestamp, start,end/duration. Speaking of which.... what will we do about the start/end vs. duration debate? Different bundles? Configurable custom field type?

Well, for configuration currently we have the one checkbox in the content type settings form.

As for entity reference, a single instance of the field can only reference a single entity type (which i didnt know before doing a little more research before writing this(see http://drupal.org/node/1360230)). I think that we may have to re-think the use of this module. I see 2 options for generic "track time on any entity" functionality:

1. We force users to create separate time tracker bundles for each entity type they want to track time on, and edit the entity reference field on that bundle to point to the specific entity.
2. We drop entity reference, create another column in the time_tracker_entries table which stores the entity type and bundle key. All of the entity hooks require a "type".

#2 looks to be the preferred route. This would also allow us to just have a settings page, where we list all available entities and bundle types. The user then justs selects which entity/bundle they want to track time.

#2 sounds good to me. What if a user wants to create two separate time tracker bundles that tracks time on two different entities? Can they still do that?

Are we having multiple "time tracker" bundles? or are we just having one time tracker entity?

I would think that all we need is a time tracker entity. This way when we store an entry, we store the teid, entity type and bundle, and entity ID. This way the settings form would allow us to list all of the available entities and bundles, and the user could select which ones they want to track time on.

We would have to figure out a way to deal with tracking time on comments, because i think core only allows comments on nodes...

What if we allowed individual users the option of how they wanted to track time (duration vs start/stop)? Couldnt we include a setting on the users account allowing them to indicate which method they would like to use?

Because it doesnt matter which way a users wants to track time, we can still calculate total time...

Here is what looks like the best way forward to me:

1. We define our own entity and bundle with the following fields:
   • Date Module:
     • Start
     • Stop
     • Timestamp
   • Boolean
     • Billed
     • Billable
     • Locked
   • Float
     • Duration
     • Deductions
   • Longtext
     • Notes
   • Custom Fields
     • teid
     • entity type
     • entity bundle
     • entity id
     • uid
2. We create a settings page where the admin can select what entity/bundle types they want to track time on.
3. We add a setting on the user profile form, where the individual user can select the way the want to track time (duration vs start/stop).

Doing it this way would move the "Track time on nodes" and "Track time on comments" settings from each content type, to the main settings form. One place to administer all time tracker tracking methods. And would allow each user to track time however they want.

I didnt say that it wouldnt have any performance implications, I agree that Field API stuff would decrease performance. But i think for flexibility it would be a benefit.

Hey guys,

@chertzog: I think your proposal for how to move forward is good. I'm not sure if giving the option to the users about how they want to track time is necessarily the way to go... or at least not by default. I feel like the time entry method shouldn't be left up to the individual doing the work. A decision like that usually comes from higher up. What about making it role based? Or maybe role based by default with the option to override on a user by user basis?

@mradcliffe Right now, I feel like the flexibilty outweighs the performance, but perhaps we should talk about cases where the performance hit would be a significant issue?

As for user configurable, we could have it globally configured by default, then have a admin controlled setting that would allow user configurable tracking...

Cool. I still think having the global setting be role based wouldn't be a bad thing. =)

I agree. Before i start coding this up, can we get a consensus on the road ahead?

I submit #28 with global option/role based time tracking configuration.

I consent.

All, sorry it has taken so long. But client work, family issues, etc, etc, the list goes on. Any how, attached you will find an archive with a almost completely rewritten time_tracker module. I have also committed the code to the 7.x dev branch.

New features:
1. Activities are now fieldable entities.
2. Time entries are fieldable entities.
3. You can now track time on ANY entity/bundle.
4. Seeing as core only supports comments on nodes, tracking time on comments is limited to node bundles.
5. There is a new settings page where the admin configures what entities/bundles time tracking is enabled for.

Things left to do:
1. Let users pick the way they want to track time (duration vs interval)
2. Time Sheet / Timer / Time Estimate sub modules
3. CSS needs work

That's awesome, chertzog! I'll give this a try this weekend.

Nice work!

Well seeing as the module is almost completely ported, and the only issues left are up for discussion, i think we can close this issue, and open separate issues for anything that pops up.

Agreed.