List:Eventum Development« Previous MessageNext Message »
From:Jay.Graves Date:September 8 2004 7:15pm
Subject:RE: New developer/RFC on new feature
View as plain text  
>The medium term roadmap includes the 2.0 release which we want to improve
>the fitness of Eventum in different usage patterns, like bug handling,
tasks
>and etc. We also want to make some sort of inter-installation communication
>framework, so that you can have dependencies between different projects,
>whether they are local to this installation, or to some remote one.

Sounds good.  Is there a document describing these changes in the upcoming
1.3 release?

>> 1.  Add a boolean column to time_tracking_category indicating
>> that the work
>> is capitalizable.  For instance, design and development are capitalizable
>> but bug-fixes are not.
>I guess you mean a new field "ttc_is_billable" to flag those types of
>entries, right? Would it make more sense to add this field in the main time
>tracking table and let users specify at creation time which of the entries
>are billable or not? I'm not too sure if always making a category billable
>would fit all usages.

Capitalizable and Billable are different things.  (To us anyway.)  A
developer doesn't always know what he is doing is capitalizable and
therefore shouldn't have to make the decision everytime he enters his time.
Project managers _do_ know what is capitalizable by project and could
control it by adjusting the available categories by project.  And actually,
in argu^H^H^H^Htalking with a project manager here, I've amended my design.
'Issues' need to be Capitalizable or not and we can handle this easily with
a Custom field.  When the Manager of a project downloads the time entries
for his projects into Excel, he can sort on Category and rollup time based
on that. 

>> 2.  Add a new table tenatively named 'user_time_tracking'.
>> create table eventum_user_time_tracking(
>> utt_usr_id INT(10) unsigned NOT NULL,
>> utt_iss_id INT(10) unsigned NOT NULL,
>> primary key (utt_usr_id,utt_iss_id),
>> key utt_usr_id (utt_usr_id),
>> key utt_iss_id (utt_iss_id)
>> );
>>
>> This table will allow users to save their 'favorite' issues that they
post
>> time against but that isn't necessarily assigned to them.
>> Records would be
>> added to and deleted from this table based on a checkbox in the
>> "Record Time
>> Worked" section of view.php.
>I'm not sure I understand this. Why do you need to have a "favorite issues"
>table related to time tracking entries? You can already know if an issue is
>important to you by doing a search in the system (i.e. by the assignment
>field or by the notification list field).
>And even if you do need to use the time tracking information for this,
>surely you can get all of this information from the main time tracking
table
>(fields ttr_usr_id and ttr_iss_id).

Sorry I wasn't more clear about the use of this table.  We need the ability
to post time to generic issues that aren't necessarily assigned to any one
person.  We are just starting a new phase of a project to replace our ERP
software.  We would create a issue named, 'Design Meetings for G/L' and
anytime anyone attended a meeting on that subject, they would post the time
to the issue.  No one is really 'responsible' for the issue getting
resolved, it can't be resolved, but we need a place to put the time everyone
spent on it so we can get accurate accounting.  There are many such tasks.
The user_time_tracking table is intended to allow the user to 'save' an
issue that they enter time against often, but is not assigned to them.  I
thought about using the notification table but it would need a new type of
record and needs to be editable by the user themselves.



>> 3. Create a 'Enter Hours' page linked from the 'navigation.tpl.html'
>> template.  This will allow the user to enter hours for multiple issues at
>> one time.  (Even across projects).
>I understand that this may be an important feature for you, but I'm not at
>all convinced that this would also be needed by most users. I'm trying to
>get a balance of nice-to-have features and extra complexity. I mean, the
>extra feature that would be useful to you would make Eventum harder to use
>for most other users.

I disagree, it is just another page that the user can choose to use or not.
We could even configure, by installation, whether it shows up in the
navigation template or not and make it completely self-contained.

>What's the problem with entering the time in each issue, anyway?

See above.  It is a pain to find each generic issue just to post time.  By
the default the 'Enter Hours' page would show issues asssigned to you as
well as issues in your favorites list.  
We need to account for fixed amount of time every week.  There would likely
be 'Issues' for 'Vacation' and 'Sick'.  Maybe this is outside the scope of
Eventum but Eventum is the only open source Issue/Task system that allows
time tracking.  Most of them are really just bug-trackers and that won't do
for us.  We have a home grown system that maps about 90% to what Eventum
does right now (and Eventum does a lot more) and time tracking is the
biggest part of it.

>> 4.  Create a report that shows a time break down by week (or any date
>> period) across projects by project lead and is downloadable to Excel.
>>
>That sounds like a good idea. You just need to create a new report in the
>system and query the information from the existing tables.

That's the plan, but to really be useful to us, we need to break it out by
the capitalization flag as discussed above (meaning a custom field that
won't be available in all projects).  Is there eventually going to be a
'Saved Reports' type functionality that doesn't rely on php code?

>> 5. Soft code the phone call reasons  (adding new tables where necessary)
>If by the above you mean a way to dynamically customize the list of phone
>call reasons, that was already done for release 1.3.

Great!

>> 6. Save Login/Project cookie for longer than 'Session'
>Not sure what you mean here. The login cookie only expires 8 hours after
>your last pageview in Eventum, whether the browser is closed or not. So
this
>is already "longer than the browser session". Do you mean something else?

I just looked at my cookies in Firefox and zeroed in on the PHPSESSID for my
test server and saw that it expired at the end of the session.  I didn't
look at the code, sorry.  What made me wonder about this is that even though
I am checking the box to 'remember me' at login, I have to re-enter my email
address and default project every day.  I think 8 hours is a bit short but
we can work with it.

>> Lastly,  is anyone running Eventum on Win2K/IIS?  I would prefer Linux
but
>> we don't have a machine available, but we do have spare capacity on a
>> Windows box.  Thoughts or concerns?
>Yeah, Eventum should work fine under IIS.

Thanks.

Any timeframe for a 1.3 release?

...
Jay
Thread
New developer/RFC on new featureJay.Graves8 Sep
  • RE: New developer/RFC on new featureJoao Prado Maia8 Sep
RE: New developer/RFC on new featureJay.Graves8 Sep
  • RE: New developer/RFC on new featureJoao Prado Maia8 Sep
RE: New developer/RFC on new featureJay.Graves8 Sep
RE: New developer/RFC on new featureNeil Maitland9 Sep