On Wed, Oct 23, 2013 at 1:22 AM, Apache Bloodhound <
[email protected]> wrote:
> #304: Default product is not the default option in the ticket quick create
> or
> newticket form
>
>
[...]
> {{{#!diff
> diff --git a/bloodhound_theme/bhtheme/theme.py
> b/bloodhound_theme/bhtheme/theme.
> index 3c5aa1a..7f15a15 100644
> --- a/bloodhound_theme/bhtheme/theme.py
> +++ b/bloodhound_theme/bhtheme/theme.py
> @@ -486,7 +486,8 @@ class QuickCreateTicketDialog(Component):
> if self.env.product:
> product_field['value'] = self.env.product.prefix
> else:
> - product_field['value'] = product_field['options'][0]
> + product_field['value'] = \
> + self.env.config.get('ticket', 'default_product')
>
Wasn't it [multiproduct] default_product_prefix ?
> product_field['options_desc'] = [
ProductEnvironment.lookup_env(self.env,
p).product.name
> for p in product_field['options']
> }}}
>
> However, we shouldn't have to set the default value, that should be
> handled by `trac.ticket.api:TicketSystem.fields`. The `default_product`
> doesn't get set because `default_product` is not defined in the
> `TicketSystem` class. It is not defined anywhere, so we also don't see
> documentation listed at !Guide/Ini#ticket-section.
>
[multiproduct] default_product_prefix is documented in guide docs
>
> We could fix this by just adding `default_product` to the
> `trac.ticket.api:TicketSystem` class, see
> [https://github.com/rjollos/bloodhound/commit/29cee781 29cee781] . It is
> not ideal to change `trac/ticket/api.py`, but we've already done that by
> introducing `ITicketFieldProvider`.
That's exactly the reason why I think it's better not to patch TicketSystem
in trunk/trac/ ... we already have introduced an extension point for that .
> It might be possible to subclass
`TicketSystem` and add `default_product` to
> `trac.ticket.api:ProductTicketSystem`, like was done for the
> `BatchModifyModule` in [1511771].
-
afaict so far , but maybe I'm wrong ...
>
> Related issue: One possible source of confusion for users is that
> `default_product` should be set to a product prefix. We can see from #568
> that users might even try to set an option that has "prefix" in the name
> to the product name rather than the prefix. The most user-friendly
> solution would probably be to accept either a product prefix or name for
> the option.
>
>
That's what GUI are for ... an admin panel for this might be added as well
;)
--
Regards,
Olemis - @olemislc
