@amyblais No subpath, just the plain domain.

Hi @amyblais, thanks for taking a look!

Here are the banner settings:

# grep -i banner config.json 
        "EnablePreviewModeBanner": true,
        "EnableBanner": false,
        "BannerText": "",
        "BannerColor": "#f2a93b",
        "BannerTextColor": "#333333",
        "AllowBannerDismissal": true

I should also mention that I’ve previously enabled Developer Mode ("EnableDeveloper": true), but I’m not sure it’s related, since the notification in this issue has the normal blue background, not a purple one.

The issue reappeared today for the other affected user, then kept disappearing and reappearing under testing, but we were unable to pin down any specific reason. Their browser console (Firefox) only has this:

websocket connecting to wss://[redacted]/api/v4/websocket websocket_client.jsx:35:20

and the server log meanwhile only has this line repeated:

mlog/log.go:174	{"name":"TypeError","message":"NetworkError when attempting to fetch resource.","stack":""}	{"path": "/api/v4/logs", "request_id": "g8wwo8yu57djmkipjxjxn7hy3y", "ip_addr": "[redacted]", "user_id": "[redacted]", "method": "POST", "err_where": "client", "http_code": 0, "err_details": ""}

(where user_id is the one for the affected user.)

Summary

Selecting the ”Refresh the app now” link from update notification doesn’t make the notification go away.

Steps to reproduce

Have MM server updated to latest release. Open an existing session of the web app in Firefox. See the refresh prompt, select ”Refresh the app now”.

Expected behavior

Web page is refreshed, the notification goes away.

Observed behavior (that appears unintentional)

Web page is refreshed, but the update notification is still there, still prompting to refresh.

Verbose version

With some of the most recent updates (perhaps 5.16 and newer), the ”Refresh the app now” link in the update notification (”A new version of Mattermost is available”) on the web app did not make that notification go away for myself and another user. The link did cause a refresh of the page content, but the notification persisted. Meanwhile the version being reported by ”About Mattermost” was the correct (5.16.2).

Ctrl+shift+r or other hard refresh attempts did not have an effect, but logging out and then back in to the site finally did make the notification go away.

We’re both Firefox users, and due to the nature of the issue it was difficult to tell if this was browser-specific, but a fresh login using Chrome (while the previous session in Firefox still showed the notification) did not bring up the notification in the new session.

The issue, though irritatingly persistent while it lasted, was still relatively ephemeral, and now that it’s gone, I wouldn’t know how to reproduce it before the next server update. That said, I’ll happily provide more details if I can.

A hint for anyone googling for this: make sure that the value of gcmSenderId in your AndroidManifest.xmlstill has the trailing backslash (\) after you’ve changed the project number to your own. Otherwise the value gets interpreted as int, when it should be a string, which is one way to trigger the issue of devices being assigned empty/null IDs.

(The building instructions do have this documented in bold, but it’s still very easy to miss, I know I did. Complicating the debugging was my Nexus 5X, which kept getting a proper device ID even when all other devices using the same broken build failed to.)

The build-android target calls the pre-build target as pre-buid, resulting in build failure for the build-android target. This PR fixes the issue.

(PR #2272 did the same for a typo in the build-pr target.)

The push proxy codebase refers to notifications as ”notificaitons” once in the README and once in a LogInfo() call.

Steps to reproduce

$ git clone https://github.com/mattermost/mattermost-push-proxy.git
$ cd mattermost-push-proxy/
$ git rev-parse HEAD
41affc6595fc927a75de1184292cec89278b40a8
nothing to commit, working tree clean
$ git rev-parse HEAD
41affc6595fc927a75de1184292cec89278b40a8
$ grep -Ri "notificaiton" .

Expected behavior

$ grep -Ri "notificaiton" .
$

Observed behavior (that appears unintentional)

$ grep -Ri "notificaiton" .
./server/android_notification_server.go:	LogInfo(fmt.Sprintf("Initializing Android notificaiton server for type=%v", me.AndroidPushSettings.Type))
./README.md:For more in-depth instructions on setting up push notificaitons with your own build please follow the directions at [docs.mattermost.com](https://docs.mattermost.com/developer/mobile-developer-setup.html#push-notifications-with-your-own-build)

Possible fixes

Here’s a link to the line in server/android_notification_server.go, README.md link unavailable because Github doesn’t allow per-line linking to Markdown files (that I know of). I think this should be pretty easy to fix and I can provide a pull request.

Output from procps’ ps with -e only produces the process name, so grepping for ”cli.js start” fails every time. This change adds (POSIX-compliant) -f to all ps calls to get the full command. AWK print parameter is adjusted accordingly where needed.

Issue #1359 resulted in PR #1370, but only addressed the stop: target. The changes here address the rest of the ps calls the same way.

Reproducible here on a Galaxy Tab 4 (SM-T530), Android 5.0.2.