Ticket #8314 (new enhancement)
Opened 3 years ago
Last modified 20 months ago
Dynamic Default Values
| Reported by: | anonymous | Owned by: | |
|---|---|---|---|
| Priority: | low | Milestone: | next-major-0.1X |
| Component: | ticket system | Version: | 0.11-stable |
| Severity: | normal | Keywords: | default, ticket, dynamic |
| Cc: | |||
| Release Notes: | |||
| API Changes: | |||
Description
In the config file, we have options to provide default values for multiple fields. It appears that these can only be string literals though.
Is it possible, or easy to implement, a dynamic default value.
More specific:
The way I have permissions set-up, there are several groups. Each user belongs to one of these groups, and has no other permissions set.
I want this group to be the default value for a field, so that we can later sort them by what group/company these tickets originated from.
thanks
Attachments
Change History
comment:1 Changed 3 years ago by cboos
- Component changed from general to ticket system
- Milestone set to experimental
comment:2 Changed 3 years ago by cboos
comment:3 Changed 3 years ago by anonymous
Well I've hacked together a plug-in to implement this specific request, but a more general (and elegant) solution would be nice for the future.
comment:4 Changed 2 years ago by Ryan Ollos <ryano@…>
I'm a little unclear about the request, but I believe that th:TracTicketChainedFieldsPlugin implements the desired functionality.
comment:5 Changed 22 months ago by cboos
- Milestone changed from experimental to next-major-0.1X
Milestone experimental deleted
comment:6 Changed 20 months ago by rikmer
I think I looked for a solution for this problem for at least 4 hours now and I cannot find any trac-hack nor anything else how to realise this functionality.
TracTicketChainedPlugin? doesnt have the functionality to have default field values based on username or group or permission.
Please ... this feature is needed badly.
@anonymous: Could you provide me with this plugin of yours? I hope its compatible to 0.11.



Somehow related to #474 and #4549. Though in this case, I'd rather see something like a custom Property and reimplementation of render_selector (see FieldRefactoring#Proposal).