titanz
/
matrix-docker-ansible-deploy
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'f2293f61ee'
${ noResults }
matrix-docker-ansible-deploy/roles/matrix-jitsi/templates/web/interface_config.js.j2

296 lines
10 KiB
Raw Normal View History Unescape

Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
/* eslint-disable no-unused-vars, no-var, max-len */
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
/* eslint sort-keys: ["error", "asc", {"caseSensitive": false}] */
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
var interfaceConfig = {
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
APP_NAME: {{ matrix_jitsi_web_interface_config_app_name|to_json }},
AUDIO_LEVEL_PRIMARY_COLOR: 'rgba(255,255,255,0.4)',
AUDIO_LEVEL_SECONDARY_COLOR: 'rgba(255,255,255,0.2)',
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
/**
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
* A UX mode where the last screen share participant is automatically
* pinned. Valid values are the string "remote-only" so remote participants
* get pinned but not local, otherwise any truthy value for all participants,
* and any falsy value to disable the feature.
*
* Note: this mode is experimental and subject to breakage.
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
*/
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
AUTO_PIN_LATEST_SCREEN_SHARE: 'remote-only',
jitsi-web: add more defaults
5 years ago
BRAND_WATERMARK_LINK: {{ matrix_jitsi_web_interface_config_brand_watermark_link|to_json }},
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
CLOSE_PAGE_GUEST_HINT: false, // A html text to be shown to guests on the close page, false disables it
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
/**
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
* Whether the connection indicator icon should hide itself based on
* connection strength. If true, the connection indicator will remain
* displayed while the participant has a weak connection and will hide
* itself after the CONNECTION_INDICATOR_HIDE_TIMEOUT when the connection is
* strong.
*
* @type {boolean}
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
*/
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
CONNECTION_INDICATOR_AUTO_HIDE_ENABLED: true,
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
/**
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
* How long the connection indicator should remain displayed before hiding.
* Used in conjunction with CONNECTION_INDICATOR_AUTOHIDE_ENABLED.
*
* @type {number}
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
*/
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
CONNECTION_INDICATOR_AUTO_HIDE_TIMEOUT: 5000,
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
/**
* If true, hides the connection indicators completely.
*
* @type {boolean}
*/
CONNECTION_INDICATOR_DISABLED: false,
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
DEFAULT_BACKGROUND: '#474747',
DEFAULT_LOCAL_DISPLAY_NAME: 'me',
DEFAULT_LOGO_URL: 'images/watermark.svg',
DEFAULT_REMOTE_DISPLAY_NAME: 'Fellow Jitster',
DEFAULT_WELCOME_PAGE_LOGO_URL: 'images/watermark.svg',
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
DISABLE_DOMINANT_SPEAKER_INDICATOR: false,
DISABLE_FOCUS_INDICATOR: false,
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
/**
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
* If true, notifications regarding joining/leaving are no longer displayed.
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
*/
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
DISABLE_JOIN_LEAVE_NOTIFICATIONS: false,
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
/**
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
* If true, presence status: busy, calling, connected etc. is not displayed.
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
*/
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
DISABLE_PRESENCE_STATUS: false,
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
/**
* Whether the ringing sound in the call/ring overlay is disabled. If
* {@code undefined}, defaults to {@code false}.
*
* @type {boolean}
*/
DISABLE_RINGING: false,
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
/**
* Whether the speech to text transcription subtitles panel is disabled.
* If {@code undefined}, defaults to {@code false}.
*
* @type {boolean}
*/
jitsi-web: add more defaults
5 years ago
DISABLE_TRANSCRIPTION_SUBTITLES: {{ matrix_jitsi_web_interface_config_disable_transcription_subtitles|to_json }},
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
/**
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
* Whether or not the blurred video background for large video should be
* displayed on browsers that can support it.
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
*/
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
DISABLE_VIDEO_BACKGROUND: false,
DISPLAY_WELCOME_FOOTER: true,
DISPLAY_WELCOME_PAGE_ADDITIONAL_CARD: false,
DISPLAY_WELCOME_PAGE_CONTENT: {{ matrix_jitsi_web_interface_config_display_welcome_page_content|to_json }},
DISPLAY_WELCOME_PAGE_TOOLBAR_ADDITIONAL_CONTENT: false,
ENABLE_DIAL_OUT: true,
ENABLE_FEEDBACK_ANIMATION: false, // Enables feedback star animation.
FILM_STRIP_MAX_HEIGHT: 120,
GENERATE_ROOMNAMES_ON_WELCOME_PAGE: {{ matrix_jitsi_web_interface_config_generate_room_names_on_welcome_page|to_json }},
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
/**
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
* Hide the logo on the deep linking pages.
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
*/
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
HIDE_DEEP_LINKING_LOGO: false,
/**
* Hide the invite prompt in the header when alone in the meeting.
*/
HIDE_INVITE_MORE_HEADER: false,
INITIAL_TOOLBAR_TIMEOUT: 20000,
JITSI_WATERMARK_LINK: {{ matrix_jitsi_web_interface_config_jitsi_watermark_link|to_json }},
LANG_DETECTION: {{ matrix_jitsi_web_interface_config_lang_detection|to_json }}, // Allow i18n to detect the system language
LIVE_STREAMING_HELP_LINK: 'https://jitsi.org/live', // Documentation reference for the live streaming feature.
LOCAL_THUMBNAIL_RATIO: 16 / 9, // 16:9
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
/**
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
* Maximum coefficient of the ratio of the large video to the visible area
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
* after the large video is scaled to fit the window.
*
* @type {number}
*/
MAXIMUM_ZOOMING_COEFFICIENT: 1.3,
/**
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
* Whether the mobile app Jitsi Meet is to be promoted to participants
* attempting to join a conference in a mobile Web browser. If
* {@code undefined}, defaults to {@code true}.
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
*
* @type {boolean}
*/
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
MOBILE_APP_PROMO: true,
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
/**
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
* Specify custom URL for downloading android mobile app.
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
*/
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
MOBILE_DOWNLOAD_LINK_ANDROID: 'https://play.google.com/store/apps/details?id=org.jitsi.meet',
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
/**
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
* Specify custom URL for downloading f droid app.
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
*/
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
MOBILE_DOWNLOAD_LINK_F_DROID: 'https://f-droid.org/en/packages/org.jitsi.meet/',
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
/**
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
* Specify URL for downloading ios mobile app.
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
*/
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
MOBILE_DOWNLOAD_LINK_IOS: 'https://itunes.apple.com/us/app/jitsi-meet/id1165103905',
NATIVE_APP_NAME: {{ matrix_jitsi_web_interface_config_native_app_name|to_json }},
// Names of browsers which should show a warning stating the current browser
// has a suboptimal experience. Browsers which are not listed as optimal or
// unsupported are considered suboptimal. Valid values are:
// chrome, chromium, edge, electron, firefox, nwjs, opera, safari
OPTIMAL_BROWSERS: [ 'chrome', 'chromium', 'firefox', 'nwjs', 'electron', 'safari' ],
POLICY_LOGO: null,
PROVIDER_NAME: {{ matrix_jitsi_web_interface_config_provider_name|to_json }},
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
/**
* If true, will display recent list
*
* @type {boolean}
*/
RECENT_LIST_ENABLED: true,
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
REMOTE_THUMBNAIL_RATIO: 1, // 1:1
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
SETTINGS_SECTIONS: [ 'devices', 'language', 'moderator', 'profile', 'calendar' ],
SHOW_BRAND_WATERMARK: {{ matrix_jitsi_web_interface_config_show_brand_watermark|to_json }},
/**
* Decides whether the chrome extension banner should be rendered on the landing page and during the meeting.
* If this is set to false, the banner will not be rendered at all. If set to true, the check for extension(s)
* being already installed is done before rendering.
*/
SHOW_CHROME_EXTENSION_BANNER: false,
Fix variable name typo (take 2) Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/970
4 years ago
SHOW_DEEP_LINKING_IMAGE: {{ matrix_jitsi_web_interface_config_show_deep_linking_image|to_json }},
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
SHOW_JITSI_WATERMARK: {{ matrix_jitsi_web_interface_config_show_jitsi_watermark|to_json }},
SHOW_POWERED_BY: {{ matrix_jitsi_web_interface_config_show_powered_by|to_json }},
SHOW_PROMOTIONAL_CLOSE_PAGE: false,
/*
* If indicated some of the error dialogs may point to the support URL for
* help.
*/
SUPPORT_URL: 'https://community.jitsi.org/',
TOOLBAR_ALWAYS_VISIBLE: false,
/**
* The name of the toolbar buttons to display in the toolbar, including the
* "More actions" menu. If present, the button will display. Exceptions are
* "livestreaming" and "recording" which also require being a moderator and
* some values in config.js to be enabled. Also, the "profile" button will
* not display for users with a JWT.
* Notes:
* - it's impossible to choose which buttons go in the "More actions" menu
* - it's impossible to control the placement of buttons
* - 'desktop' controls the "Share your screen" button
*/
TOOLBAR_BUTTONS: [
{% if matrix_jitsi_enable_transcriptions %}
'closedcaptions',
{% endif %}
Remove the recording button from the Jitsi UI if recording is disabled.
4 years ago
{% if matrix_jitsi_enable_recording %}
'recording',
{% endif %}
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
'microphone', 'camera', 'desktop', 'embedmeeting', 'fullscreen',
Remove the recording button from the Jitsi UI if recording is disabled.
4 years ago
'fodeviceselection', 'hangup', 'profile', 'chat',
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
'livestreaming', 'etherpad', 'sharedvideo', 'settings', 'raisehand',
'videoquality', 'filmstrip', 'invite', 'feedback', 'stats', 'shortcuts',
'tileview', 'videobackgroundblur', 'download', 'help', 'mute-everyone', 'security'
],
TOOLBAR_TIMEOUT: 4000,
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
// Browsers, in addition to those which do not fully support WebRTC, that
// are not supported and should show the unsupported browser page.
UNSUPPORTED_BROWSERS: [],
/**
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
* Whether to show thumbnails in filmstrip as a column instead of as a row.
*/
VERTICAL_FILMSTRIP: true,
// Determines how the video would fit the screen. 'both' would fit the whole
// screen, 'height' would fit the original video height to the height of the
// screen, 'width' would fit the original video width to the width of the
// screen respecting ratio.
VIDEO_LAYOUT_FIT: 'both',
/**
* If true, hides the video quality label indicating the resolution status
* of the current large video.
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
*
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
* @type {boolean}
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
*/
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
VIDEO_QUALITY_LABEL_DISABLED: false,
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
/**
* How many columns the tile view can expand to. The respected range is
* between 1 and 5.
*/
// TILE_VIEW_MAX_COLUMNS: 5,
/**
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
* Specify Firebase dynamic link properties for the mobile apps.
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
*/
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
// MOBILE_DYNAMIC_LINK: {
// APN: 'org.jitsi.meet',
// APP_CODE: 'w2atb',
// CUSTOM_DOMAIN: undefined,
// IBI: 'com.atlassian.JitsiMeet.ios',
// ISI: '1165103905'
// },
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
/**
* Specify mobile app scheme for opening the app from the mobile browser.
*/
// APP_SCHEME: 'org.jitsi.meet',
/**
* Specify the Android app package name.
*/
// ANDROID_APP_PACKAGE: 'org.jitsi.meet',
/**
* Override the behavior of some notifications to remain displayed until
* explicitly dismissed through a user action. The value is how long, in
* milliseconds, those notifications should remain displayed.
*/
// ENFORCE_NOTIFICATION_AUTO_DISMISS_TIMEOUT: 15000,
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
// List of undocumented settings
/**
INDICATOR_FONT_SIZES
PHONE_NUMBER_REGEX
*/
// Allow all above example options to include a trailing comma and
// prevent fear when commenting out the last value.
// eslint-disable-next-line sort-keys
makeJsonParserHappy: 'even if last key had a trailing comma'
// No configuration value should follow this line.
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
};
Update Jitsi to build 5142 This supersedes/fixes-up this Pull Request: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719 The Jitsi Web and JVB containers now (in build 5142) always start by bulding their own default configuration (`config.js` and `sip-communicator.properties`, respectively). The fact that we were generating these files ourselves was no longer of use, because our configuration was thrown away in favor of the one created by the containers on startup. With this commit, we're completely redoing things. We no longer generate these configuration files. We try to pass the proper environment variables, so that Jitsi services can generate the configuration files themselves. Besides that, we try to use the "custom configuration" mechanism provided by Jitsi Web and Jitsi JVB (`custom-config.js` and `custom-sip-communicator.properties`, respectively), so that we and our users can inject additional configuration. Some configuration options we had are gone now. Others are no longer controllable via variables and need to be injected using the `_config_extension` variables that we provide. The validation logic that is part of the role should take care to inform people about how to upgrade (if they're using some custom configuration, which needs special care now). Most users should not have to do anything special though.
4 years ago
{{ matrix_jitsi_web_custom_interface_config_extension }}
Manage Jitsi configuration by ourselves for most components We do this for 2 reasons: - so we can control things which are not controllable using environment variables (for example `stunServers` in jitsi/web, since we don't wish to use the hardcoded Google STUN servers if our own Coturn is enabled) - so playbook variable changes will properly rebuild the configuration. When using Jitsi environment variables, the configuration is only built once (the first time) and never rebuilt again. This is not the consistent with the rest of the playbook and with how Ansible operates. We're not perfect at it (yet), because we still let the Jitsi containers generate some files on their own, but we are closer and it should be good enough for most things. Related to #415 (Github Pull Request).
5 years ago
/* eslint-enable no-unused-vars, no-var, max-len */