Admin Manage Components table does not hide when there are no components

[Ryan J Ollos]

Here is a screen capture of the Manage Milestones view with all of the milestones deleted:

Here is a screen capture of the Manage Components view with all of the components deleted:

The message As long as you don't add any items to the list, this field will remain completely hidden from the user interface. should be displayed and the table header should be hidden when all of the Components are deleted.

The problem is that Component.select returns a generator, and it's not expanded to a list in _render_admin_panel. For all of the other cases of Ticket System fields, select either returns a list or the generator is expanded to a list in _render_admin_panel (e.g. enums).

[Ryan J Ollos <ryan.j.ollos@…>]

Should I just expand the generator to a list before passing to the template, or is there something else that should be done here?

[Christian Boos]

It's just "by luck" that some other select return a list and not a generator. It would look suspicious to have a 'components': list(model.Component.select(self.env)), line but then a 'versions': model.Version.select(self.env) a bit later. As we already have the list(...) for the abstract enums, I think we should better add it everywhere, to be consistent and better express that the templates actually expect a list.

Btw, I just saw we still have the ticket related admin templates still below admin/templates. It would be better to have them below the ticket/templates.

[Ryan J Ollos <ryan.j.ollos@…>]

Replying to cboos:

Btw, I just saw we still have the ticket related admin templates still below admin/templates. It would be better to have them below the ticket/templates.

Cool, I've been meaning to bring that up. I'll make that change in the Git branch for this ticket.

[Ryan J Ollos]

The Manage Repositories panel has the same issue as the Manage Components panel.

[Ryan J Ollos]

Replying to cboos:

Btw, I just saw we still have the ticket related admin templates still below admin/templates. It would be better to have them below the ticket/templates.

Initially I had some concerns about making this change on 1.0-stable, and how it might affect the translations, but after regenerating the catalog template and string catalogs, it seems the result is that no manual changes to the catalogs are required to accommodate the templates being moved. Does making the change on 1.0-stable sound okay?

All of the proposed changes for this ticket can be found in rjollos.git:t11103.

[Christian Boos]

Series looks good to me and 1.0 seems to be fine for the move of templates.

[Ryan J Ollos]

Thanks for reviewing. I'll go ahead and push the changes to 1.0-stable this evening.

[Jun Omae]

I notice that [11923] breaks RegressionTestTicket11194 test case. The sorted_repos variable is not used in trac/versioncontrol/admin.py in default repository and repos:rjollos.git:t11103.

======================================================================
FAIL: Test for regression of http://trac.edgewall.org/ticket/11194
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/jun66j5/src/trac/edgewall/github/trac/versioncontrol/tests/functional.py", line 205, in runTest
    tc.follow('\\b' + names[1] + '\\b')
  File "/usr/lib/python2.5/site-packages/twill/commands.py", line 202, in follow
    raise TwillAssertionError("no links match to '%s'" % (what,))
TwillAssertionError: no links match to '\bshrewishly_1\b'

----------------------------------------------------------------------
Ran 140 tests in 734.110s

[Ryan J Ollos]

Thanks for catching the failure. I don't have the subversion bindings installed in the environment that I was running the tests, which is why I wasn't seeing this failure.

It's not obvious to me at the moment why it is failing since sorted_repos is defined on the body element​, and then used to populate the table​. I'll take a closer look in the morning.

Changes from repos:rjollos.git:t11103 committed to 1.0-stable in [11918:11924].

[Ryan J Ollos]

Oh, I think I made a stupid error here, due to looking at admin_components.html​ and not thinking about the differences in the templates. Do I just need a py:if instead of a py:when?

[Jun Omae]

Replying to rjollos:

Do I just need a py:if instead of a py:when?

Yeah, the test case passes! Please commit it.

[Ryan J Ollos]

Thanks, Jun! Committed to 1.0-stable in [11925].

[Ryan J Ollos]

Fixed another issue in [11929], which wasn't discovered until merging the changes to the trunk and running the test suite.

======================================================================
ERROR: runTest (trac.ticket.tests.functional.TestReportDynamicVariables)
Generate a report with dynamic variables in title, summary
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/user/Workspace/t11103/trac-trunk/trac/ticket/tests/functional.py", line 1173, in runTest
    ticket_id = self._tester.create_ticket(summary, fields)
  File "/home/user/Workspace/t11103/trac-trunk/trac/tests/functional/tester.py", line 87, in create_ticket
    tc.formvalue('propertyform', 'field_%s' % field, value)
  File "/home/user/Workspace/t11103/trac-trunk/trac/tests/functional/better_twill.py", line 160, in better_formvalue
    fv(form, field, value)
  File "/home/user/Workspace/t11103/local/lib/python2.7/site-packages/twill-0.9-py2.7.egg/twill/commands.py", line 435, in formvalue
    control = browser.get_form_field(form, fieldname)
  File "/home/user/Workspace/t11103/local/lib/python2.7/site-packages/twill-0.9-py2.7.egg/twill/browser.py", line 365, in get_form_field
    raise TwillException('no field matches "%s"' % (fieldname,))
TwillException: no field matches "field_component"

----------------------------------------------------------------------

[Ryan J Ollos]

Merged to trunk in [11930].