Edgewall Software
Modify

Opened 15 years ago

Closed 4 months ago

#3281 closed enhancement (duplicate)

make Keywords field optional

Reported by: wkornew Owned by:
Priority: normal Milestone:
Component: ticket system Version: 0.9.5
Severity: normal Keywords: tracobject conditional fields
Cc: wkornewald, ilias@…, leho@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description

It is very annoying that the Keywords field takes up screen space even if it's not needed. I know that it has been requested by many people, but I'm sure that there are even more people who don't use it, at all. Please make it optional.

Why is it not possible to make the Keywords field one of those [TracTicketsCustomFields]?

Attachments (3)

ticket-api.keywords.diff (847 bytes ) - added by wkornew 15 years ago.
please patch ticket/api.py
optional-keywords.patch (821 bytes ) - added by wkornew 15 years ago.
cleaned up. includes documentation for show_keywords. patch against trunk
ticket_3281.patch (1.0 KB ) - added by Cinc-th 6 months ago.
Patch to hide the ticket field keywords from the ticket page.

Download all attachments as: .zip

Change History (32)

comment:1 by Emmanuel Blot, 15 years ago

Milestone: 0.9.6
Severity: majornormal

by wkornew, 15 years ago

Attachment: ticket-api.keywords.diff added

please patch ticket/api.py

comment:2 by wkornew, 15 years ago

BTW, the patch is for V0.9.5. ;)

by wkornew, 15 years ago

Attachment: optional-keywords.patch added

cleaned up. includes documentation for show_keywords. patch against trunk

comment:3 by wkornew, 15 years ago

Cc: wkornew added

comment:4 by wkornewald <wkornewald>, 15 years ago

Cc: wkornewald added; wkornew removed

So, will nothing happen with this? Will it be fixed with the workflow branch?

comment:5 by Noah Kantrowitz <coderanger@…>, 15 years ago

The SimpleTicket plugin already fixes this. You can hide whatever fields you want.

comment:6 by Waldemar Kornewald <wkornewald>, 15 years ago

Actually, I wanted a less hacky solution (SimpleTicket requires having a new permission policy, etc.). Keywords could be implemented with custom fields or is there special code for them somewhere?

in reply to:  6 comment:7 by Noah Kantrowitz <coderanger@…>, 15 years ago

Replying to Waldemar Kornewald <wkornewald>:

Actually, I wanted a less hacky solution (SimpleTicket requires having a new permission policy, etc.). Keywords could be implemented with custom fields or is there special code for them somewhere?

SimpleTicket does not require anything related to the security branch, it runs on plain ol' 0.10.x.

comment:8 by Waldemar Kornewald <wkornewald>, 15 years ago

No, I meant that you must give people a new permission (SIMPLE_TICKET or something like that).

comment:9 by ilias@…, 15 years ago

Cc: ilias@… added

you can verify this issue from the tracx plugin (on top of 0.11dev), which goes a step further to provide different ticket-fields for different ticket-types.

Once implemented, this should cover your needs.

sidenot: stable versions get only 'bugfixes'. So, your patch (functionality) provided for 0.9.5 will most possibly not be applied (= 'wontfix').

To team: this issue should be generalized ('make ticket fields optional', for 0.11dev) or alternatively closed as 'wontfix', as it affects an old release.

comment:10 by Waldemar Kornewald <wkornewald>, 15 years ago

Just to clarify. This has the problem that TRAC_ADMIN and TICKET_ADMIN still have access to the keywords field. I can provide a new patch (for 0.10 or 0.11), of course, but the real solution would probably be to remove the field completely. It's not needed everywhere, anyway. This should probably be implemented with a generic "tag" plugin which also allows for showing tag clouds. At least, this field isn't used by everyone and Trac should only provide the greatest common denominator. The rest should be done with modules or custom fields. IMHO, of course.

comment:11 by Christian Boos, 15 years ago

Keywords: tracobject conditional fields added
Milestone: 1.0

Thinking about #2464 and its generalization to conditional custom fields, I wonder if that could not be extended to regular fields as well (and anyway, the difference is blurred in the GenericTrac proposal).

In this view, the precondition for the Keyword: field could simply be false, so that it'll never apply.

In a similar way, the th:SimpleTicketPlugin effects could be obtained by having tests for the permissions in the precondition.

comment:12 by Christian Boos, 14 years ago

#5078 was another request for the same feature.

comment:13 by asloan12@…, 14 years ago

adding my request for this change, we don't need the Keywords field and would like to be able to make it disappear. Thanks

comment:14 by immanuel.scholz@…, 12 years ago

Two years passed and keyword is still there.

I found this through Google and can only support all the guys wanting it to be removed. For their very reasons (unused, drains up user attention.)

comment:15 by anatoly techtonik <techtonik@…>, 12 years ago

Keywords is the only default way to structure information in your own way. They should be present. There could be an option to turn them off, though.

comment:16 by Fabien COMBERNOUS, 12 years ago

I agree with the idea of being able to turn off the keyworks.

comment:17 by cmc, 12 years ago

We remove this in our ticket template file. Seems like an acceptable solution to me.

comment:18 by Carsten Klein <carsten.klein@…>, 11 years ago

Why not implement post_process_request on an request filter installed by a plugin of yours? That way, you could remove the field from the template prior to that it gets served to the client, without the need to have yet another configuration option.

comment:19 by Christian Boos, 11 years ago

Milestone: 1.0unscheduled

Milestone 1.0 deleted

comment:20 by Christian Boos, 11 years ago

Milestone: triagingnext-major-0.1X
Owner: Jonas Borgström removed

comment:21 by anonymous, 10 years ago

This keyword field annoys. Kindly remove this keyword from the main template or make it optional.If needed we can add it as a custom field.

comment:22 by lkraav <leho@…>, 7 years ago

Cc: leho@… added

comment:23 by Cinc-th, 6 months ago

Here is a quick patch for this ticket. Just hiding the field from the ticket page should be enough to satisfy the most urgent needs and those who don't want to install a plugin.

This will not remove the field from the Query page, though, but that is a minor caveat imho considering the minimal impact on the codebase.

Unit tests and functional tests are passing in the default configuration.

  • trac/ticket/web_ui.py

     
    100100            [TracQuery#UsingTracLinks Trac links].
    101101            """)
    102102
     103    hide_keywords_field = BoolOption('ticket', 'hide_keywords_field', 'false',
     104        """Hide the keywords field from the ticket page.
     105        Note that the field is still visible when doing a ticket query.
     106        """)
     107
    103108    ticket_path_re = re.compile(r'/ticket/([0-9]+)$')
    104109
    105110    def __init__(self):
     
    15841589                        del field_changes['cc']
    15851590                    else:
    15861591                        field_changes['cc']['new'] = ', '.join(new_cc_list)
     1592            elif name == 'keywords':
     1593                if self.hide_keywords_field:
     1594                    field['skip'] = True
    15871595
    15881596            # per type settings
    15891597            if type_ in ('radio', 'select'):

by Cinc-th, 6 months ago

Attachment: ticket_3281.patch added

Patch to hide the ticket field keywords from the ticket page.

comment:24 by Cinc-th, 6 months ago

I considered skipping the field in TicketSystem.fields or TicketSystem.get_ticket_fields() but wasn't sure about any side effects.

Doing it there would also remove the field from the query page and any other place it can be seen. Such a thing is done for the select fields (milestone, component, …), see trunk/trac/ticket/api.py@17500:364-389#L360

I'll change the patch if it is found that removing the field completely has no ill effects.

comment:25 by Ryan J Ollos, 6 months ago

If we add a hide_keywords_field option we'll likely need to remove it later. We should consider solving this issue in combination with other ticket field options in a section:

[ticket-custom]
priority.order = 1
milestone.order = 2
...
keywords.hide = 1

There are many related tickets on the ticket field option topic.

comment:26 by Cinc-th, 6 months ago

While I may agree in general the section [ticket-custom] isn't the right one imho because the keywords field is no custom field. That would be rather confusing for the user…

The options for the other default fields (for example the select fields milestone, component, …) are all to be found in section [ticket].

comment:27 by Ryan J Ollos, 6 months ago

Yeah, it was just an example. The section naming could be discussed in the implementation, but the main point is we need to consider this ticket in the context of all ticket customization features.

comment:28 by anonymous, 6 months ago

So I'd suggest to go with:

[ticket]
keywords.hide = True

That's in line with how things are done for ticket custom fields.

While at it the same could be done for the cc field, too.

comment:29 by Ryan J Ollos, 4 months ago

Milestone: next-major-releases
Resolution: duplicate
Status: newclosed

Closing since this needs to be addressed in the context of ticket field customization. A complete proposal will need to be written. We can address in #2464.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none) to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.