@mfonism FTR I swapped this one with #2283

From #2656

• Improved and styled Django autocompletes.

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

@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 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!

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

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?

@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.

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.

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.