When the home assistant integration was introduced, I was like ”okay, this must be one of Lloyd’s jokes, right?” But no, turns out it’s real.

Then your Alexa bit came and had me in tears.

I think I’ve (accidentally) found a reliable way to reproduce this:

1. Have a card with a checklist
2. From the card’s hamburger menu, select More -> Delete, but don’t touch the (”Delete card?”) confirmation prompt!
3. With the card deletion confirmation prompt still visible, delete the checklist (choose Delete from the checklist title, then confirm the checklist deletion)
4. Now select Delete from the (still lingering) card deletion prompt

Boom! The card (and the board) is now undeletable.

Thank you for the app, it’s surprising that this basic functionality doesn’t come built-in with the device.

Would it be possible to either add an option to autostart tracking when GPS is ready, or to allow the user to start the tracking despite GPS not being ready yet? My problem is that if GPS isn’t ready right away, I forget to manually start the tracking when GPS becomes ready later. (I’m used to ignoring the device buzzing during activities.) I don’t mind missing GPS data at the start of my walks (before satellites are found), tracking the time is more important for me.

Also, for my 735XT at least, the up arrow button has a long-press options menu, which (among other things) allows you to lock the buttons. For some reason this doesn’t seem to work in Simple Walk, as the up arrow button only brings up another data screen. I don’t know if it’s possible to implement (or pass through) the options menu in apps, but I’d like to be able to lock the device for walks too.

Ehdottaisin viimeisen pohjoisen suuntaan illalla lähtevän 20B:n aikataulun myöhentämistä 10 minuutilla. Illan viimeinen juna on on yöjuna Helsinkiin, ja se tulee Ouluun aikataulun mukaan klo 23.48. Tuo viimeinen 20B ohittaa viereisen linja-autoaseman pysäkin 23.43, joten siihen ei nyt enää mitenkään ehdi junalta, jollei juna satu olemaan roimasti etuajassa. Kävely asemalta esim. Toppilaan asti kantamuksien kanssa on aika vaivalloista varsinkin näin talvisin, kun on liukasta.

Valittaisin tuosta kaurahiutalepakettien ulkoasu-uudistuksesta. Uudet pakkaukset ovat kyllä tyylikkäämpiä, mutta jostain syystä pikakaurahiutalepaketista tehtiin uudistuksessa samanvärinen (tummansininen) tavallisten hiutaleiden paketin kanssa, ja sen seurauksena olen nyt jo monta kertaa ostanut vahingossa pikakaurahiutaleita tavallisten sijasta, kun niitä on niin vaikea erottaa. Ja kun minulla on suhteellisen normaalisti toimivat hoksottimet, niin voin vain kuvitella miten vaikeaa esimerkiksi dysleksikoilla on näiden kanssa.

Kehottaisin vaihtamaan jomman kumman pakkauksen pääväriä, jotta ne olisivat yhtä selvästi eroteltavissa kuin aiemmin, kun toinen pakkaus oli vaaleansininen ja vain toinen tummansininen.

@amyblais No subpath, just the plain domain.

Your service keeps asking me to verify my e-mail address over and over again. When I open the verification link from the email, the verification succeeds and the yellow notification goes away, but when I return to the site the next day, the notification has reappeared and I have to go through the whole process again. This has been going on for weeks if not months.

I found one Community Forum thread with the same issue, but the ”solution” there just tells the affected user to contact support. https://github.community/t5/How-to-use-Git-and-GitHub/Continual-repeated-requirement-to-verify-email-address-for-users/td-p/18085

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.

The git-annex page has a removal warning at the top (introduced here). It currently says ”Warning: GitLab has completely removed in GitLab 9.0 (2017/03/22).”

My guess is it’s actually supposed to say ”Git annex support has been completely removed in GitLab 9.0 (2017/03/22).”