No need to say Zammad is brilliant. But I lack a bit of functionality.
In usecase parlance: as a user I sometimes have the need to enter driving distance with a ticket article so I can generate a bill each month that accounts for both time and distance driven.
I can extend ticket objects, but not ticket article objects so adding an attribute to a ticket article is not an option.
I finally figured out a possible workaround for this so I can administrate driving distance per ticket article if I happen to spend time outside the office. The time_unit field in ticket_time_accountings is numeric(6,2). I could enter the distance as the part after the decimal separator for distance up to 99 units (Km, miles).
Of course later I have to split the field and sum separately.
My request would be to change the field to a float. I think the performance impact is nil but it allows for distances larger than 99 (meters, Km, miles) to store.
Looking forward to what the Zammad devs think about this one
Personally I wouldn’t like a distance value being coupled with a comma seperated value.
This is anything but intuitive and proberbly will cause more harm then use for existing users.
If you’d really need a distance to be documented during the time accounting dialogue, I’d prefer a second text field which allows you to do so. But that’s my thought.
Currently you could workaround this stuff with a custom object. Yes, this forces you to add values together on your own, but would allow you to ge tthose information from objects. If that’s no option, you may fiddle a plugin that extends your stuff if needed.
I’m not yet sure if this is a development question or a feature request. If it’s the second option, feel free to change the category to custom development.
Yes, I am not happy with my solution either. It is more of a dirty workaround than anything else.
If I could program in Ruby I could maybe try to copy the functionality of adding attributes to objects to the ticket_article objects. But I can’t (yet. Oh, if only there was more time ).
