> Sounds good. Is there a document describing these changes in the upcoming
> 1.3 release?
No, but we could possibly write something down about what we want
accomplished before the 2.0 release.
> 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.
Good, so no changes are needed.
> 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
That's fine. There's nothing in Eventum stopping a user that is not
currently set as the assignee for a particular issue from entering time on
it. That is, you could ask all of the member of your project to enter time
into issue #123 and that would work just fine.
> 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.
Right, and an extra page is exactly that -- even more things that he doesn't
And yes, we can make it yet another configurable option in Eventum, which
makes it more complex to maintain and more difficult to set it up. However,
I'm trying more and more to avoid that and keep Eventum as simple to use and
maintain as possible.
Seriously, if you really need this extra page for something that can be done
pretty easily as it is, I think your best bet is to create it as an add-on
in your own installation.
> 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.
I don't think I agree, and we do have tons of issues in our internal
installations of Eventum. Asking around for the issue number or even
searching for it, is not that big of a deal.
> 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?
I don't understand. What do you mean by "Saved Reports type functionality" ?
> 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.
Ah yes, we use sessions to keep a dummy language variable. It's a
placeholder code for whenever we really implement i18n in eventum, but right
now the variable is always set to 'en'.
> Any timeframe for a 1.3 release?
Tomorrow or friday. We're still testing the releasing and fixing last minute