Please backup before even attempting this. Actually, please backup with the Firebase auto-backup tier plan, because this can happen to you or your users just by accident. If it happens, you lose your organizations data object in Firebase, which makes your instance unusable to the public.
This happened with our instance before, but we didn't know why and I couldn't reproduce it. I just managed to reproduce it, but only on one of the following environments:
localhost (no issue)
linkyeg.firebaseapp.com (no issue)
linkyeg.ca <-- The steps below deletes the org tree
www.linkyeg.ca (no issue, surprisingly)
Note that linkyeg.ca (or www.linkyeg.ca) is not hosted by Firebase (the database is, but not the html/js files). I took the built public folder contents into an apache backend server. In all except the localhost environment, https is used.
Steps to reproduce
Go to /admin/organizations/new (via the "New Organization" button).
Add a name to the organization. Note that the component header changes from "New Organization" to whatever you typed in.
Add a phone number. Add some random number.
Hit "Delete this Phone". Note that the component header is changed back to "New Organization" even though your organization name still remains intact.
Hit "Submit".
My guess is that either this, or some variation of this error came up with one of the users who have been provided admin access to update/create organizations, and hit that scenario. I originally thought it was a Firebase vs Apache hosted solution that was the issue, but www.linkyeg.ca won't reproduce the issue, so I'm guessing not. It might have to do with the subdomain being a requirement, though that should mean that localhost should've reproduced the error as well.
If someone using Firebase to deploy/host the app can test it again their custom domain, making sure there's a backup of the Firebase json db file first, that would be very helpful. If this ends up being an issue for even Firebase-deployed instances with no "www" prefix on the custom domain, then this error could potentially affect someone down the line, and should be fixed.
If it's not the issue, then I'm happy to update the wiki to warn others of the potential issue if they deploy outside of FIrebase.
Please backup before even attempting this. Actually, please backup with the Firebase auto-backup tier plan, because this can happen to you or your users just by accident. If it happens, you lose your organizations data object in Firebase, which makes your instance unusable to the public.
This happened with our instance before, but we didn't know why and I couldn't reproduce it. I just managed to reproduce it, but only on one of the following environments:
Note that linkyeg.ca (or www.linkyeg.ca) is not hosted by Firebase (the database is, but not the html/js files). I took the built public folder contents into an apache backend server. In all except the localhost environment, https is used.
Steps to reproduce
My guess is that either this, or some variation of this error came up with one of the users who have been provided admin access to update/create organizations, and hit that scenario. I originally thought it was a Firebase vs Apache hosted solution that was the issue, but www.linkyeg.ca won't reproduce the issue, so I'm guessing not. It might have to do with the subdomain being a requirement, though that should mean that localhost should've reproduced the error as well.
If someone using Firebase to deploy/host the app can test it again their custom domain, making sure there's a backup of the Firebase json db file first, that would be very helpful. If this ends up being an issue for even Firebase-deployed instances with no "www" prefix on the custom domain, then this error could potentially affect someone down the line, and should be fixed.
If it's not the issue, then I'm happy to update the wiki to warn others of the potential issue if they deploy outside of FIrebase.