You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Pierre Smits <pi...@gmail.com> on 2012/07/18 12:58:46 UTC

Time entries in Project Mgt

Hi All,

When trying to do some backend corrections on time entries related to
projects I found that when doing a search in WebTools I could not do a
search for specific dates in the entity TimeEntry without adding the start
time of the date(s) (e.g. 2010-10-19 00:00:00.000) in the field fromDate. I
also found that a truDate field is specified, but that doesn't seem to be
used.

Shouldn't the fromDate field be of the type Date, in stead of date-time? As
time entries are supposed to be registered for the day and not for a
specific time slot of a given day? When having a large number of time
entries this would decrease the data footprint. It would also ease up on
code complexity and effort to create a specific search/find function, as
well as saving screen space when displaying time entries.

Is the truDate field not superfluous and shouldn't it be removed to create
a simpler entity and data footprint?

Please advise.

Regards,

Pierre

Re: Time entries in Project Mgt

Posted by Pierre Smits <pi...@gmail.com>.
Jacques,

Thanks for the insightful reply. I now know what to do.

Regards,

Pierre

Re: Time entries in Project Mgt

Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Pierre Smits" <pi...@gmail.com>
> Hi All,
>
> When trying to do some backend corrections on time entries related to
> projects I found that when doing a search in WebTools I could not do a
> search for specific dates in the entity TimeEntry without adding the start
> time of the date(s) (e.g. 2010-10-19 00:00:00.000) in the field fromDate. I
> also found that a truDate field is specified, but that doesn't seem to be
> used.
>
> Shouldn't the fromDate field be of the type Date, in stead of date-time? As
> time entries are supposed to be registered for the day and not for a
> specific time slot of a given day? When having a large number of time
> entries this would decrease the data footprint. It would also ease up on
> code complexity and effort to create a specific search/find function, as
> well as saving screen space when displaying time entries.

The name itself suggest it's related to time and not date.
Is it not used in other situations where the time is needed?

> Is the truDate field not superfluous and shouldn't it be removed to create
> a simpler entity and data footprint?

It's hard to answer this question without a description of the intended use of TimeEntry.
I don't think it's wise to change it w/out a thorough review of use cases
At 1st glance, from TimesheetAndTimeEntry and ProjectPhaseTaskActualHoursView comments, it's used

Now, when I think about it, this was not really a question for the dev ML but user ML.
I spent a small time on it, but still some time. Actually the way you did was to ask questions w/out having made enough review 
before

I know you are a not a committer, but asking such questions on dev ML implies some responsabilities. So let me refer to General
Responsibilities of Committers
https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities#OFBizCommittersRolesandResponsibilities-GeneralResponsibilitiesofCommitters
"Rule #2 for a committer is the same as for a scientist: read before you write. When you're getting started a good time ratio for
read to write is around 20 to 1. Once you're a total OFBiz pro who knows as much as any living person about the project, you can
probably reduce that to about 3 to 1. This relates to respecting precedent. It doesn't mean that existing things can't or shouldn't
be changed, but it does mean that things that already exist must be understood before they are changed. This also relates to
recognizing that whatever you are doing chances are there are best practices or patterns already established. So, this means you
should look for those and try to understand them and if necessary ask about them explaining what you are trying to do before you
seek to establish your own pattern."

HTH

Jacques

> Please advise.
>
> Regards,
>
> Pierre
>