RT version is 3.8.10 running on postgres 8.3.14 and debian 5.0.
I’m trying to set RT to use unit “days” in time fields in addition to
minutes and hours.
I found similar thread in list archives:
RT version in that thread was 3.8.2. It seems that things are changed a
little since then.
I have found, that some of necessary code is in the file
share/html/Elements/SelectTimeUnits.
I have now unit “days” in the right place, but there is no relation between
days and hours/minutes. I.e RT doesn’t know how much minutes/hours 1 day is.
Any idea where i can find that logic?
If anybody knows better way to do it, i would be greatful to hear it.
I did that. However, I wanted to maintain the concept of ‘hours’, so I
changed the DataBase to contain all time fields with 3 decimal positions
(.125 = 1 hour). I changed all the displays, etc. to show that.
Kenn
LBNLOn Tue, May 3, 2011 at 11:21 PM, Joosep joosepm@gmail.com wrote:
Hi list!
RT version is 3.8.10 running on postgres 8.3.14 and debian 5.0.
I’m trying to set RT to use unit “days” in time fields in addition to
minutes and hours.
I found similar thread in list archives: Carbon60: Managed Cloud Services
RT version in that thread was 3.8.2. It seems that things are changed a
little since then.
I have found, that some of necessary code is in the file
share/html/Elements/SelectTimeUnits.
I have now unit “days” in the right place, but there is no relation between
days and hours/minutes. I.e RT doesn’t know how much minutes/hours 1 day is.
Any idea where i can find that logic?
If anybody knows better way to do it, i would be greatful to hear it.
Is the database modification also necessary in order it to work, or should
it work with just the modifications in the file
local/html/Elements/SelectTimeUnits
?
Implementing the code from that thread so far only seem to give the
possibility to select days from the dropdown menu when using for example
“time estimated” field in the ticket basics, but seem to lack the math. At
least in RT 3.8.10. When inserting some value in hours, RT automatically
converts the inserted value into minutes(for example inserting 2 hours
results after save 120 minutes). When inserting for example 5 hours, after
the save, it results in 5 minutes.
I’m not very familiar with perl, but it seems that these rows should be
responsible for the math:
% my $selected = ‘minutes’;
% $selected = ‘hours’ if $minutes > 60;
% $selected = ‘days’ if $minutes > 480;
But they don’t seem to do it. Maybe the math has moved since then or i’m
doing something wrong.
I would be grateful for any pointers and hints where to look.
Thanks in advance
JoosepOn Wed, May 4, 2011 at 7:38 PM, Kenneth Crocker kfcrocker@lbl.gov wrote:
Joosep,
I did that. However, I wanted to maintain the concept of ‘hours’, so I
changed the DataBase to contain all time fields with 3 decimal positions
(.125 = 1 hour). I changed all the displays, etc. to show that.
RT version is 3.8.10 running on postgres 8.3.14 and debian 5.0.
I’m trying to set RT to use unit “days” in time fields in addition to
minutes and hours.
I found similar thread in list archives: Carbon60: Managed Cloud Services
RT version in that thread was 3.8.2. It seems that things are changed a
little since then.
I have found, that some of necessary code is in the file
share/html/Elements/SelectTimeUnits.
I have now unit “days” in the right place, but there is no relation
between days and hours/minutes. I.e RT doesn’t know how much minutes/hours 1
day is.
Any idea where i can find that logic?
If anybody knows better way to do it, i would be greatful to hear it.
I would think the DB changes ARE necessary. If you don’t define the field
with 3 decimal positions, then it would always round up or down and you’d
gain/lose a lot of time. We didn’t like the option of hours or minutes, so I
removed the top-down choice. Since we offered hours in the form of .125
days, we felt that should be sufficient. We didn’t know of ANYONE in our
organization that would project time estimates in hours or minutes. Most
projects involve many, many man-days.
Is the database modification also necessary in order it to work, or should
it work with just the modifications in the file local/html/Elements/SelectTimeUnits
?
Implementing the code from that thread so far only seem to give the
possibility to select days from the dropdown menu when using for example
“time estimated” field in the ticket basics, but seem to lack the math. At
least in RT 3.8.10. When inserting some value in hours, RT automatically
converts the inserted value into minutes(for example inserting 2 hours
results after save 120 minutes). When inserting for example 5 hours, after
the save, it results in 5 minutes.
I’m not very familiar with perl, but it seems that these rows should be
responsible for the math:
% my $selected = ‘minutes’;
% $selected = ‘hours’ if $minutes > 60;
% $selected = ‘days’ if $minutes > 480;
But they don’t seem to do it. Maybe the math has moved since then or i’m
doing something wrong.
I would be grateful for any pointers and hints where to look.
Thanks in advance
Joosep
On Wed, May 4, 2011 at 7:38 PM, Kenneth Crocker kfcrocker@lbl.gov wrote:
Joosep,
I did that. However, I wanted to maintain the concept of ‘hours’, so I
changed the DataBase to contain all time fields with 3 decimal positions
(.125 = 1 hour). I changed all the displays, etc. to show that.
RT version is 3.8.10 running on postgres 8.3.14 and debian 5.0.
I’m trying to set RT to use unit “days” in time fields in addition to
minutes and hours.
I found similar thread in list archives: Carbon60: Managed Cloud Services
RT version in that thread was 3.8.2. It seems that things are changed a
little since then.
I have found, that some of necessary code is in the file
share/html/Elements/SelectTimeUnits.
I have now unit “days” in the right place, but there is no relation
between days and hours/minutes. I.e RT doesn’t know how much minutes/hours 1
day is.
Any idea where i can find that logic?
If anybody knows better way to do it, i would be greatful to hear it.
Thanks for the info Kenneth i will look into it further.
JoosepOn Thu, May 5, 2011 at 5:43 PM, Kenneth Crocker kfcrocker@lbl.gov wrote:
Joosep,
I would think the DB changes ARE necessary. If you don’t define the field
with 3 decimal positions, then it would always round up or down and you’d
gain/lose a lot of time. We didn’t like the option of hours or minutes, so I
removed the top-down choice. Since we offered hours in the form of .125
days, we felt that should be sufficient. We didn’t know of ANYONE in our
organization that would project time estimates in hours or minutes. Most
projects involve many, many man-days.
Is the database modification also necessary in order it to work, or should
it work with just the modifications in the file local/html/Elements/SelectTimeUnits
?
Implementing the code from that thread so far only seem to give the
possibility to select days from the dropdown menu when using for example
“time estimated” field in the ticket basics, but seem to lack the math. At
least in RT 3.8.10. When inserting some value in hours, RT automatically
converts the inserted value into minutes(for example inserting 2 hours
results after save 120 minutes). When inserting for example 5 hours, after
the save, it results in 5 minutes.
I’m not very familiar with perl, but it seems that these rows should be
responsible for the math:
% my $selected = ‘minutes’;
% $selected = ‘hours’ if $minutes > 60;
% $selected = ‘days’ if $minutes > 480;
But they don’t seem to do it. Maybe the math has moved since then or i’m
doing something wrong.
I would be grateful for any pointers and hints where to look.