Unable to add attribute: users and team names are not recognized

[mattermost-community]

Unable to add attribute: users and team names are not recognized

[gabrielctn]

If it can help, I personally figured that after managing to migrate to a subdomain URL instead of subpath installation, the plugin worked:
https://mattermost.example.com instead of https://example.com/mattermost
It is annoying because Mattermost (almost) support subpath installation, but I had many more issues (with Boards just to mention it for example).
I would recommand, if you can, to use a subdomain installation.

[gabrielctn]

You are most welcome !
Yes it is that simple, in the config.json file, just set the line "SiteURL": "https://mattermost.yoursite.com", restart and voilà.
At least, it worked for me 😉
Of course users will have to set the modified URL in their Mattermost App server settings, and most probably do the famous "Clear Cache and Reload".

[zaengerlein]

I just installed the Custom Attributes plugin on our server and we experience the same issue. Neither user nor team search return any results.
This is a major issue, as it renders the plugin unusable as far as I can see?
When inspecting the request & response which entering text in the username / teamname text boxes triggers, I found that the server for some reason responds with a HTTP 400 error response. Here are the detail, I hope they help debugging. Can I do something more to expedite to find out whether this is some error specific to our installation or whether this is an issue in either the API request triggered by the plugin?

`Request
POST /api/v4/users/search
Content-Type: text/plain;charset=UTF-8
Accept: /
Origin: https://OURSERVERURL
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.4 Safari/605.1.15
X-Requested-With: XMLHttpRequest
X-CSRF-Token: h1wqofmzf38r9cbxydpywpjmyw

Redirect Response
302 Found
Date: Tue, 22 Mar 2022 14:47:52 GMT
Location: /mattermost/api/v4/users/search

Request
GET /mattermost/api/v4/users/search HTTP/1.1
Accept: /
Origin: https://OURSERVERURL
Cookie: MMAUTHTOKEN=THETOKEN; MMCSRF=h1wqofmzf38r9cbxydpywpjmyw; MMUSERID=9r8oheaa5ibb9butu8qqa979sw; rl_anonymous_id=RudderEncrypt%3AU2FsdGVkX183UBkrtKmI3qkPaFtwivpS%2F5yKCxyhDkJNVlriTaCufHdTzyHl2mV3UHP0ZQewOjRiY0ysmlq1UQ%3D%3D; rl_trait=RudderEncrypt%3AU2FsdGVkX19OcwZNp4l24B4A9Jq6VUB9J5eEbjlJ2Is%3D; rl_user_id=RudderEncrypt%3AU2FsdGVkX1%2BjsqD6yqPDWvEhvKRoPT44qfXLR20Ot94BLON8RMFabpcN%2FBUjwrbT; _ga=GA1.2.604029463.1647867422; rl_page_init_referrer=RudderEncrypt%3AU2FsdGVkX19jTC69QubWsfUytUK33w9ij9MGA4e3b2E%3D; rl_page_init_referring_domain=RudderEncrypt%3AU2FsdGVkX1%2BqkxbklpU0mblBOMyvmuGsEFalLJa6Bkw%3D
Host: ...
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.4 Safari/605.1.15
Accept-Language: de-DE,de;q=0.9
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
X-CSRF-Token: h1wqofmzf38r9cbxydpywpjmyw
X-Requested-With: XMLHttpRequest

Response
HTTP/1.1 400 Bad Request
Content-Type: application/json
Vary: Accept-Encoding
Date: Tue, 22 Mar 2022 14:47:52 GMT
Content-Length: 201
Expires: 0
Connection: close
Server: Apache/2.4.41 (Ubuntu)
X-Version-Id: 6.3.3.6.3.3.8b47315f7db8caeee0fdce3efe04cdef.false
X-Request-Id: z7ktprr6wfb3tfe3rergy5c9sh`

The get request contains the following request data (which I think looks fine) and no mime-type is set.
{"term":"a"}

When I compare this request to the request data which is sent for a successful user search request, I see that there a mime-type is set for the request: "application/json".

The server log shows the following entry when entering text in the respective text boxes:
{"timestamp":"2022-03-22 15:55:33.438 +01:00","level":"debug","msg":"Invalid or missing user_id parameter in request URL.","caller":"web/context.go:101","path":"/mattermost/api/v4/users/search","request_id":"miamw44uf3rdtc5t1oqu37x7th","ip_addr":"127.0.0.1","user_id":"9r8oheaa5ibb9butu8qqa979sw","method":"GET","err_where":"Context","http_code":400,"err_details":""}

[zaengerlein]

@gabrielctn thanks for your suggestion, this is highly appreciated. We are already using a subdomain installation for our server but apparently combined with a subpath 🧐 I will test your suggestion.
Can I just remove the subpath from the server URL in the configuration and restart? I suppose this will result in errors for all users currently logged in... 🙈

[zaengerlein]

@gabrielctn I am flabbergasted! Removing the subpath in the SiteURL did indeed resolve the issue for me as well! Again thank you! I hope your tip also helps the Mattermost team to fix the issue :)

[muratbayan]

This issue is there on v1.3.1, could a fix be considered? Multiple organizations I work with tend to run proof of concept or small deployments using subpaths, some of which remain under a subpath for the long term, some moving to a subdomain over time