First of all, I’d like to thank the community — I’m really happy with how well the platform is working for us.
However, in our case it makes much more sense to log time in minutes, since we record daily entries. The issue is that the total time displayed per ticket is being severely limited by the 166.6665 minutes cap caused by the numeric(6,2) field definition being used for minutes.
My question is: has anyone already increased this limit?
In our case, changing it to numeric(7,2) would completely solve the problem, but our environment is running so smoothly that I’m hesitant to make this modification.
You shouldn‘t change default columbs of Zammad, as a database migration might touch those columns at some point and might cause trouble that‘s just not worth it.
Is it realistig that you have time units of up to 999999 minutes? That‘s over 600 days. That doesn‘t sound like a problem to me, unless you account time to tickets that are used for several years.
You make a good point, but actually the maximum would be 99999.99, which equals about 69 days — I agree it’s quite unlikely to be reached.
However, in some cases we have improvement tickets that can reach 200 hours, totaling around 12,000.00 minutes.
If I were to switch everything to hours now, it would require a massive rollback of all records currently stored in minutes — that’s why I’m concerned.
I imagine this change would have to be done in Ruby, and it would carry some risks.
@YetAnotherGerrit What do you think, enhancement issue, bug report or neither?
The database migration should be an extremely low hanging fruit. I could provide the PR for that as well…
This would be a feature request, as tiny as the implementation would be. Please write it as such and I will discuss it with some devs. MR would be nice, but only after I did some consultation with them.