RFE: Show drop down w/ auto-complete for user selection in Test Run Page

[YouWhy]

Is your feature request related to a problem? Please describe.
When I try to assign someone to test cases in the test run view, I am expected to enter the username/email/userid and there is no shortlist provided as I type.

Describe the solution you'd like
As I type a username or email I would like the available entries in the DB to be provided as a short list.

Describe alternatives you've considered
I dont see any alternatives.

Additional context

[atodorov]

@mfonism FTR I swapped this one with #2283

[atodorov]

From #2656

• Improved and styled Django autocompletes.

Maybe we can find a suitable widget in the Grappelli library for this.

[pandafy]

@atodorov I propose the following solution for this issue

I added a sub-menu for "Default tester" item and added a select2 input for selecting the user. We can then use the AutocompleteView of Django to fetch the values from the select2 field. I used /admin/autocomplete/?app_label=management&model_name=build&field_name=version for the mock-up.

This solution will add dependency on select2

[atodorov]

@atodorov I propose the following solution for this issue

@pandafy not sure I unbderstand your proposal fully but here are some comments below.

I added a sub-menu for "Default tester" item and added a select2 input for selecting the user.

I'm not aware what select2 is but sounds like another JavaScript library. Ideally we don't add any more dependencies to the source tree but rather use the existing code base. For example the tags widget uses "typeahead" for the autocomplete functionality, see https://github.com/kiwitcms/Kiwi/blob/master/tcms/templates/include/tags_card.html and https://github.com/kiwitcms/Kiwi/blob/master/tcms/static/js/tags.js#L93. That's used everywhere else we've got this functionality.

If select2 is a superior implementation then we need to talk about refactoring, but that's a separate conversation.

We can then use the AutocompleteView of Django to fetch the values from the select2 field. I used /admin/autocomplete/?app_label=management&model_name=build&field_name=version for the mock-up.

I'm not aware of what Django's AutocompleteView does. The rest of the UI widgets are built using the existing JSON-RPC methods. Note: the existing User.filter RPC method and listing exiting user accounts is actually dependent on a permission label. This needs to be taken into account!

[atodorov]

@pandafy do you have a proof-of-concept which I can examine further ?

[pandafy]

I'm not aware what select2 is but sounds like another JavaScript library. Ideally we don't add any more dependencies to the source tree but rather use the existing code base. For example the tags widget uses "typeahead" for the autocomplete functionality, see https://github.com/kiwitcms/Kiwi/blob/master/tcms/templates/include/tags_card.html and https://github.com/kiwitcms/Kiwi/blob/master/tcms/static/js/tags.js#L93. That's used everywhere else we've got this functionality.

You are correct, select2 is a JavaScript library that provides functionality similar to typeahead.js. I was not aware that the project is already using typeahead.js. Since we can achieve similar results with typeahead.js, I agree with you for not bloating the project dependencies.

The rest of the UI widgets are built using the existing JSON-RPC methods.

Thanks for the heads-up. I will try to ensure that the solution to this issue is consistent with rest of the codebase.

Note: the existing User.filter RPC method and listing exiting user accounts is actually dependent on a permission label. This needs to be taken into account!

Are you referencing to auth.view_user permission?

Kiwi/tcms/rpc/api/user.py

Lines 33 to 51 in 0a179f7

	@permissions_required("auth.view_user")
	@rpc_method(name="User.filter")
	def filter(query=None, **kwargs): # pylint: disable=redefined-builtin
	"""
	.. function:: RPC User.filter(query)
	Search and return the resulting list of users.
	:param query: Field lookups for :class:`django.contrib.auth.models.User`
	:type query: dict
	:param \\**kwargs: Dict providing access to the current request, protocol,
	entry point name and handler instance from the rpc method
	:return: Serialized :class:`django.contrib.auth.models.User` object without
	the password field!
	:rtype: dict
	.. note::
	If query is ``None`` will return the user issuing the RPC request.

@pandafy do you have a proof-of-concept which I can examine further ?

@atodorov I did some quick and dirty changes to mock-up the UI. I didn't update any logic for changing the "Default tester". I will work on a PoC and open a draft PR ASAP.

From my observation, we have two similar use cases

1. Bulk updating "default tester" for test cases on /plan/<id>/
2. Bulk updating "assignee" for test executions on run/<id>/

I think we will need to implement a re-usable logic. Something similar to the tags functionality. What do you think?

---

I'm not aware of what Django's AutocompleteView does.

Going on a tangent here to share the reasoning for my earlier proposal. The Django admin allows to specify autocomplete fields. It uses select2 widget to provide autocomplete suggestion. The select2 widget uses the AutocompleteView (which is available for all registered ModelAdmin class). Hence, I proposed to use these existing functionalities here.

[atodorov]

Are you referencing to auth.view_user permission?

Yes.

I did some quick and dirty changes to mock-up the UI. I didn't update any logic for changing the "Default tester". I will work on a PoC and open a draft PR ASAP.

👍

From my observation, we have two similar use cases

1. Bulk updating "default tester" for test cases on /plan//
2. Bulk updating "assignee" for test executions on run//

Even more. Pretty much everywhere where you need a user, but these two places are a good start.

I think we will need to implement a re-usable logic. Something similar to the tags functionality. What do you think?

Agree. Implement one of them first, then packaging up the solution as a reusable template/function is much easier.

[pandafy]

Hello @atodorov! I have opened #3250. There are few UI quirks to solve in that PR, but I hope it will serve as a good PoC.