search

genielabs / HomeGenie

HomeGenie, the programmable automation intelligence
https://homegenie.it
GNU General Public License v3.0
387 stars 154 forks source link

[BUG] #421

Closed helled closed 3 years ago

helled commented 3 years ago

Version v1.3-beta.17 (June 28, 2020)

Describe the bug Configuration backup destination window becomes "404 - Not Found"

Code to Reproduce Config Zipfile is created but the path to designate a custom download folder and file name is broken.

Expected behavior Upon requesting a configuration backup, HG should offer a window to download the config zipfile to a location as desired by user.

Screenshots/Stacktrace Only visible is a white screen with "404 - Not Found"

Additional context Using PuTTY, I found the homegenie_backup_config.zip in the expected location [ ~/homegenie/html]. Discovered file had desired permissions but was assigned Owner:Group of root:root. I used "sudo chown pi:pi -R homegenie_backup_config.zip" to modify.

Could have used any one of several file transfer utilities, but ended up mounting a USB thumb drive to my Pi Zero W equipped with a multiport USB dongle. Copied file with "CP homegenie_backup_config.zip /media/USB" to a SSH created folder /media/USB.

From my Windows 10 laptop, l was able to successfully Restore the configuration with that same "homegenie_backup_config.zip" using the HomeGenie browser. So Restore functions but Backup does not.

Just to be sure this problem was not due to something else I adulterated in the late-2019 Tuicemen image I use, I embraced learning how to create a fresh SD card with the latest Buster Lite OS and only HG version 17. The "404 - Not Found "condition repeats.

mralapete commented 3 years ago

Did you check for previously reported bugs https://github.com/genielabs/HomeGenie/issues/418

tuicemen commented 3 years ago

@genemars closed issue #418 which to me indicates it was fixed. However the fix has not been offered in a build for end users in a beta or stable release. Most users don't check closed issues if running the current build. IMO, isues shouldn't be closed untill a build that addresses them has been released.

mralapete commented 3 years ago

The clue is in the label WIP.

The application is going through a major rewrite to incorporate the .Net Core environment so a resolution to that bug will be incorporated in that release.

The standard advice applies. Use the latest Stable version unless you are participating in the Beta testing process.

tuicemen commented 3 years ago

Lables mean nothing if the issue is closed. There are several issues with the wip lable, these issues are no longer there with the current stable. Beta releases can reintroduce previously fixed issues. However the title of #418 does mention the build something many fail to add to the title.

mralapete commented 3 years ago

If you are not happy with Genes labelling conventions it’s best that you take the matter up with him.

Personally it’s clear enough to me. The bug was reported and the outcome was a WIP which will be addressed in a future release.

For those wanting stability use the stable version. It really is that simple.

helled commented 3 years ago

Misunderstood that bug was fixed PRIOR to version 17. Not that it was fixed AFTER the version was posted.