Quinntin Comer

Would love to check this out and even contribute to it if possible!

Excellent! Just updated our instance

Appreciated! Cant wait to update the instance. Is there a URL available for the update? I do not see it in the release notes and it is not available in the updates feed in the PBX. I see you the Windows release is lagging behind, but what about Linux?

Glad that was useful for you!

@Vodia PBX I only asked if one existed. How do the partners get their hands on that or in what format is that available? I would love to see what's coming down the pipeline.

Absolutely could add that as a step!

This seems like an interesting response. I am not sure why the immediate jump to defensiveness. Nowhere in my post did I attack the development cycle, say that Vodia, was lacking, etc. When you are a "partner", you want to feel like a partner. You want to be partners in eachothers success. I dont think I have ever partnered with a product that doesnt have any established roadmap to let its partners know where its going... Certainly this cannot be the case? There is at a minimum some kind of yearly roadmap or goals?

Hi folks, Thought I would share this in case anyone was interested. This is just a daily script for backing up the PBX data directory. We have a file "vodiapbx-backup" in the /etc/cron.daily folder with no extension, just named "vodiapbx-backup", so that it will run dailly. You can see when your cron jobs are scheduled by running the following command: grep run-parts /etc/crontab and you will see results similar to: 17 * * * * root cd / && run-parts --report /etc/cron.hourly 25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) 47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly ) 52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly ) Based on the results above, you can see our daily will run at 6:25 daily. https://crontab.guru/#25_6_*_*_* In that "vodiapbx-backup" file, we have the following script: #!/bin/sh # Set the variables source_dir="/usr/local/pbx" backup_dir="/data/backups" now=$(date +%Y%m%d) filename="VodiaPBX_Backup_$now.tgz" # Delete backups older than 7 days echo "Deleting older backups" find "$backup_dir/*.tgz" -mtime +7 exec rm {} \; # Start Backups echo "Starting Backup" tar -zvcf "$backup_dir/$filename" "$source_dir" This script will perform the following: Define the following variables: source_dir: This is the source directory we want to backup backup_dir: This is the path where we want to store our backup (in our case, we have a mounted volume) now: This is the current datetime stamp with YYYY/MM/DD format. filename: This is the filename to use for the backup file, example: VodiaPBX_Backup_20230912.tgz" Deletes any tgz files older than 7 days from the backup_dir path compresses the source_dir path into $backup_dir/$filename

Nope. This is from multiple browsers, machines, incognito, etc. maybe something specific to the AWS template, but that part I cannot really say.

Is there a roadmap available? Coming features? Plans? etc?

Definitely a mystery for the Vodia PBX team. I have tried it from multiple computers, multiple browsers, etc. I dont know if its something specific to the image in the AWS marketplace or not.

I was able to resolve this with the following modifications: usr_portal.html [[#header name="Content-Security-Policy" content="default-src 'self' data: 'unsafe-inline' https://fonts.gstatic.com https://cdnjs.cloudflare.com https://accounts.google.com; style-src 'unsafe-inline' 'self' https://cdnjs.cloudflare.com https://fonts.googleapis.com;"]] welcome.htm: [[#header name="Content-Security-Policy" content="default-src 'self' data: https://accounts.google.com 'unsafe-inline'; child-src 'none'; frame-src https://accounts.google.com"]]

No, you can see in the error itself that it shows the exact string you are expecting at the very end so nothing is translating it or editing it. This is on a FRESH install in AWS. Errors happen in both Chrome and Edge (latest versions). If you add 'data:' to the policy, it corrects it. It is just a matter of missing information in the default config. If you add 'data:' to the CSP, it loads correctly. 'self' does not include 'data:' which is how the fonts are being loaded. If you guys are using webpack by any chance for the build process, there is a known error in webpack.

Hello, As of v69.0.8 we are seeing many failures due to Content Security Policy settings to load the fonts as well as numerous 404 errors for several js files. We have modified the templates as a short term fix. Refused to load the font 'data:font/woff2;charset=utf-8;base64,d09GMgABAAAABPfYAAoAAAANDGgABPeLAwQBAA…3vVTy4JjPl3dW7rL/5M5q5e6D9CAVi9h+FdkMTe2kWWnqGdWT8TM66vW13xqSu5Kz/MgADAAA=' because it violates the following Content Security Policy directive: "font-src 'self' https://fonts.gstatic.com/". DevTools failed to load source map: Could not load content for https://pbx.company.com/libraries/chartJs/chart.umd.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE Unchecked runtime.lastError: The message port closed before a response was received.