pub-solar/matrix-docker-ansible-deploy
5
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity
matrix-docker-ansible-deploy/roles/matrix-jitsi/templates/web/interface_config.js.j2

296 lines
10 KiB
Plaintext
Raw Normal View History

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).
2020-03-24 07:35:21 +00:00
/* 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.
2020-11-27 15:28:24 +00:00
/* 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).
2020-03-24 07:35:21 +00:00
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.
2020-11-27 15:28:24 +00:00
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).
2020-03-24 07:35:21 +00:00
/**
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.
2020-11-27 15:28:24 +00:00
* 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).
2020-03-24 07:35:21 +00:00
*/
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.
2020-11-27 15:28:24 +00:00
AUTO_PIN_LATEST_SCREEN_SHARE: 'remote-only',
jitsi-web: add more defaults
2020-03-29 06:48:46 +00:00
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).
2020-03-24 07:35:21 +00:00
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.
2020-11-27 15:28:24 +00:00
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).
2020-03-24 07:35:21 +00:00
/**
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.
2020-11-27 15:28:24 +00:00
* 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).
2020-03-24 07:35:21 +00:00
*/
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.
2020-11-27 15:28:24 +00:00
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).
2020-03-24 07:35:21 +00:00
/**
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.
2020-11-27 15:28:24 +00:00
* 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).
2020-03-24 07:35:21 +00:00
*/
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.
2020-11-27 15:28:24 +00:00
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).
2020-03-24 07:35:21 +00:00
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.
2020-11-27 15:28:24 +00:00
/**
* 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).
2020-03-24 07:35:21 +00:00
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.
2020-11-27 15:28:24 +00:00
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).
2020-03-24 07:35:21 +00:00
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.
2020-11-27 15:28:24 +00:00
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).
2020-03-24 07:35:21 +00:00
/**
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.
2020-11-27 15:28:24 +00:00
* 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).
2020-03-24 07:35:21 +00:00
*/
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.
2020-11-27 15:28:24 +00:00
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).
2020-03-24 07:35:21 +00:00
/**
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.
2020-11-27 15:28:24 +00:00
* 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).
2020-03-24 07:35:21 +00:00
*/
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.
2020-11-27 15:28:24 +00:00
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).
2020-03-24 07:35:21 +00:00
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.
2020-11-27 15:28:24 +00:00
/**
* 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).
2020-03-24 07:35:21 +00:00
/**
* Whether the speech to text transcription subtitles panel is disabled.
* If {@code undefined}, defaults to {@code false}.
*
* @type {boolean}
*/
jitsi-web: add more defaults
2020-03-29 06:48:46 +00:00
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).
2020-03-24 07:35:21 +00:00
/**
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.
2020-11-27 15:28:24 +00:00
* 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).
2020-03-24 07:35:21 +00:00
*/
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.
2020-11-27 15:28:24 +00:00
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).
2020-03-24 07:35:21 +00:00
/**
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.
2020-11-27 15:28:24 +00:00
* 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).
2020-03-24 07:35:21 +00:00
*/
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.
2020-11-27 15:28:24 +00:00
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).
2020-03-24 07:35:21 +00:00
/**
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.
2020-11-27 15:28:24 +00:00
* 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).
2020-03-24 07:35:21 +00:00
* 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.
2020-11-27 15:28:24 +00:00
* 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).
2020-03-24 07:35:21 +00:00
*
* @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.
2020-11-27 15:28:24 +00:00
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).
2020-03-24 07:35:21 +00:00
/**
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.
2020-11-27 15:28:24 +00:00
* 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).
2020-03-24 07:35:21 +00:00
*/
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.
2020-11-27 15:28:24 +00:00
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).
2020-03-24 07:35:21 +00:00
/**
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.
2020-11-27 15:28:24 +00:00
* 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).
2020-03-24 07:35:21 +00:00
*/
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.
2020-11-27 15:28:24 +00:00
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).
2020-03-24 07:35:21 +00:00
/**
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.
2020-11-27 15:28:24 +00:00
* 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).
2020-03-24 07:35:21 +00:00
*/
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.
2020-11-27 15:28:24 +00:00
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).
2020-03-24 07:35:21 +00:00
/**
* 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.
2020-11-27 15:28:24 +00:00
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).
2020-03-24 07:35:21 +00:00
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.
2020-11-27 15:28:24 +00:00
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
2021-03-29 07:59:57 +00:00
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.
2020-11-27 15:28:24 +00:00
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.
2020-12-06 12:50:45 +00:00
{% 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.
2020-11-27 15:28:24 +00:00
'microphone', 'camera', 'desktop', 'embedmeeting', 'fullscreen',
Remove the recording button from the Jitsi UI if recording is disabled.
2020-12-06 12:50:45 +00:00
'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.
2020-11-27 15:28:24 +00:00
'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).
2020-03-24 07:35:21 +00:00
// 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.
2020-11-27 15:28:24 +00:00
* 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).
2020-03-24 07:35:21 +00:00
*
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.
2020-11-27 15:28:24 +00:00
* @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).
2020-03-24 07:35:21 +00:00
*/
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.
2020-11-27 15:28:24 +00:00
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).
2020-03-24 07:35:21 +00:00
/**
* 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.
2020-11-27 15:28:24 +00:00
* 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).
2020-03-24 07:35:21 +00:00
*/
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.
2020-11-27 15:28:24 +00:00
// 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).
2020-03-24 07:35:21 +00:00
/**
* 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.
2020-11-27 15:28:24 +00:00
// 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).
2020-03-24 07:35:21 +00:00
};
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.
2020-11-27 15:28:24 +00:00
{{ 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).
2020-03-24 07:35:21 +00:00
/* eslint-enable no-unused-vars, no-var, max-len */
Reference in a new issue Copy permalink