I'm a user of casetracker. To meet my own business needs, I have coded a timesheet/activity module called casetracker_work which I am developing to use specifically with casetracker.
What I've done so far is a node module. It allows date/time formats to make data-entry as quick as possible. Basically I've tried to build a solid foundation that I can start using right away.
My goals:
The main reason I've opened this ticket is just to say I'm doing this, and it's available as a starting point for casetracker (if it is deemed worthy). For those who are interested, there are also two requests in this queue for timesheet integration into casetracker worklog and timesheet. Note that casetracker_work is based more on worklog (originally I branched from worklog, but then I rewrote).
Simon
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | google_calendar.PNG | 18.04 KB | DaveNotik |
| #1 | casetracker_work2.png | 8.29 KB | sime |
| casetracker_work1.png | 8.92 KB | sime |
Comments
Comment #1
simeThis is the second screen shot. Some things to note in the screen shots:
Comment #2
DaveNotik commentedExciting stuff. Going to install it soon.
* I've always thought of having a separate module, Time Tracker...
* ...and the content type called "time entry".
* The idea of projects should be tied in somehow -- maybe Projects pre-populated from db instead of Main Activities.
* Will it work with OG (e.g. Worker populates only from OG subscribers)?
I want to understand it more, will have more comments. Let's find some time to speak directly about case and time tracking and some ideas I've formulated.
Thanks!
Comment #3
simeHi Dave
Yes, it sounds like time_entry is equivalent to casetracker_work. I didn't labour the name, and I don't mind changing it even.
I want to integrate this module with casetracker, so I'm using casetracker helper functions whenever they are available. Hence, the project list in the screenshot is loaded from casetracker, I even tried
casetracker_get_projects_options()first, but it didn't return the pid as the key, so for the moment I'm loading the projects directly.I'm using og as recommended by Morbus, so hopefully I'm developing with a similar setup to others. I like your idea about populating worker from subscribers. I'll do that.
The taxonomy in the screenshot is not hard-coded, it's just a normal linked vocab that's been shifted to where I want it in the theming.
Look forward to further talk. I have this going live with a couple of employees, so no doubt I'll be tweaking until I've got a bit of time to add the view capabilities. Until then.
As a worker: I *hate* filling in timesheets and the time they take.
As a business owner: I want good reports and quick summaries, and I want minimum time spent on HR management.
As a coder: I'm my own worst critic.
Comment #4
simeAdded a simple report.
Comment #5
morbus iffEh oh. I have not yet installed this - I'm still trying to get back into my regular development cycle after having moved into a new home, and then had game releases like Xenosaga III and Final Fantasy XII attack me. I'm tryin', I'm trying. So, take these comments with a grain of "uh, I think you only looked at the screenshots".
First, woot, you've got some nice stuff here. Secondly, I'm a bit worried about your design. I never envisioned time entry as being a node in and of itself: I just didn't think time entries were that complicated or powerful. Looking over your screenshots, however, I can see why you did make it a node - you're asking for a lot more information, in a much more unintegrated way, then I would have liked.
My design in my head for time entry (for the nonexisting "casetracker_time.module") was:
* A single box that'd appear on new Case creation OR on comment creation.
* Said box would accept duration worked in the form of 1:30, 1.50, 1h30m, etc.
The above design enforced a few things:
* Every time entry must be related to a Case (thus, you can't work on something without documenting it).
* Every time entry on a Case must have a comment (since you can't submit case/comment without explanation).
Comments on your first screenshot:
* You relate time worked to a project, but not to an actual case. My clients need per-case breakdown of times.
* "Main activity" seems closely related to the "Type" state that Case Tracker provides. Why duplicate?
* You use "Work summary" to enforce the same thing I've enforced above with a regular Drupal comment.
* I guess I do see the need for "Date" (to help those who forget to enter their time every day).
* I'm not excited with "Start" or "Finish". What was your rationale there?
And your second screenshot:
* Here's your "Duration" thing, which was the centralizing data input on my design.
* I don't see the need for "Duration only" - if that field has a value, use that instead, no checkbox.
* "Additional information" would be covered with my use of comments or Cases above.
My biggest problem with your design is that it's tied into Case Tracker projects, and not Case Tracker cases. I just don't see the rationale in that - time should be tied to the task/case you're working on (which itself is tied to the project), and I don't want to force my developers to retype in "Worked on case #12354" when they should just go to case #12354, type in "3h" or "3" and be done with it.
Comment #6
simeJust noting a conversation with Morbus in IRC.
-- agreed that work should attach to case, not project
-- workflow that has work/time created from the case
-- remove duration_only checkbox. but continue with the concept of allowing either/or/both of start-finish VS duration concepts.
Question 1
-- the main reason I chose a node is that I want to avoid any issues associated with it *not* being a node. This is caution on my behalf. So, should I convert this to be a non-node? It won't be hard at this early stage.
Question 2
-- so far I am storing everything as a timestamp (or "seconds" in the case of duration). So the interface shows date and start, but this is really just a UI decision and these share the same field. So how about:
» start
» finish
» duration
The valid data would be:
Start-Finish: start + finish
OR
Duration: start + duration
(In the case of duration, the start is necessary for storing the date.)
Question 3
Morbus mentioned a "node_builder wrapper" (?) on IRC. I closed down before copying his comment, can anyone point me to what this?
Comment #7
DaveNotik commentedI like where this is going.
A time entry should indeed be tied to a case. I think the way this is done needs to be thought out more: integrate it into the case form so that the user has to edit the case to associate time with it, or create a new "time entry" and look up the case to tie it to, or have an "add time entry" link on the case that spawns a new "time entry" form with the association made to that case...? This is an important decision.
I think both duration and start-finish make sense. Can we use jQuery to show/hide the controls depending on what's chosen?
Start-finish probably needs some work to make it solid. I'd take a page out of the Google book for that. See the attached screenshot. Maybe use jQuery to build same kind of thing.
Thinking aloud, what about calendar integration? If Drupal had a truly robust calendar component, user could click on date to enter hours for a particular case.
Maybe those interface elements not for now, but FWIW.
Overall, should be real easy to say I spent 2 hours on this case on this date.
I guess start small and this can grow... I'm really pushing and trying to build up the ability to be able to fund certain pieces and really make headway in Drupal as a distributed team collaboration environment.
Comment #8
simeThanks Dave, I can use all of these ideas.
Note, for the moment I'm purposefully avoiding jQuery, just to get the accessibility and design right.
Comment #9
simeHad a quick look at Google calendar. The drop-down time and date choosers will be cool, but yeah, my approach is to add this sort of stuff at the end.
Comment #10
DaveNotik commentedMakes sense, it's just critical to keep the overall usability in mind from the get-go.
I can likely help with these pieces when we get there. For now, needs to be real basic and usable.
Separately, what about tying a "time entry" into multiple cases? We obviously want to have a set amount of time for each case (so we know this case took 20 minutes), but what about scenarios where user enters 2 hours, for this and this and this case. Important to at least consider this scenario. Vice versa, tying a case to multiple time entries is more straight forward, and I assume supported.
Comment #11
sime@Dave, usability is possible without javascript, I hope :-)
I have refactored based on feedback. Haven't updated the theming, so don't look yet. Table structure has changed too.
http://drupal.org/cvs?commit=45491
A new time entry can be created by casetracker/work/add/#. When I generate the form, I'd like to show a select box of cases with the case ID (if provided in arg(3)) pre-selected. But getting a list of cases... how do I get all the open cases that belong to the user's group/projects. Gordon mentioned node_access... hmm. For this reason, the url casetracker/work/add, (without a specified case), redirects to the casetracker project list until I can determine a good way.
Comment #12
simeThis thread is closed, code has been reworked based on feedback. Please go here:
http://drupal.org/node/98345