This proposes a fix for 1774 #5998
Conversation
* Using the `get_autocomplete_suggestions` method from `api.py` * * This ensures that what is sent as 'to' is handled like entered text ** `api.py` returns confirmed User or Group in the right format ** We populate the field with the returned items Caveat : if a name is passed in 'to' that is both a User and a Group, both will be returned and populated (if the user has permissions). The end user can remove one if they'd like. This shouldn't be a problem as the bulk of this usage will be from people clicking "Private Message" on a profile page.
* Move bulk of code into utils.py as two functions ** `create_suggestion` which takes one instance object of type user or group and returns suggestion code needed by js ** `find_users_and_groups_by_search` will return either all users and groups that match search criteria OR exact match in the case of a `to` param -- this avoids cases where something like `?to=s` would return all items starting with s on a GET request
| } | ||
|
|
||
|
|
||
| def find_users_and_groups_by_search(pre, show_groups=False, exact=False): |
There was a problem hiding this comment.
Since both current use cases -- the API and the new_message view -- need suggestions rather than DB objects, and there's no current use case for DB objects, I would have this function return a list of suggestions by default, and perhaps add a keyword argument that allows the caller to ask for a list of DB objects instead.
Do you think the limit of users or groups -- in this case 10 -- should be configurable via a keyword argument as well?
|
I opened PR #6001 as an alternative suggestion to populate the username by default. It is assumed that's always a user since it's populated by the username of the profile. Thoughts? |
|
In the original work I was told there was no reason to grab the 'to' from a GET request, so I removed that functionality. We now found this use case for it. Thinking to the future, if our form allows users and groups in the |
|
Since groups target many users, I would argue that it's best to explicitly type the name in the form instead of prepopulating the field (now and in the future) to avoid spamming by mistake. Moreover, since this is a GET request passed as a parameter I believe it's good hygiene to default to the Regarding the refactor, it's totally up to you. For what is worth I don't see a use case right now for refactoring the code. The refactor won't make it more DRY than it is right now. FWIW, I would opt for just getting the fix in. |
|
Closing in favor of #6001 |
Uses the
get_autocomplete_suggestionsmethod fromapi.pywhen we receive a GET request that containstoapi.pyreturns confirmed User or Group in the right formatCaveat : if a name is passed in 'to' that is both a User and a Group, both will be returned and populated (if the user has
permissions). The end user can remove one if they'd like. This shouldn't be a problem as the bulk of this usage will be from people clicking "Private Message" on a profile page.