AdminGuide:GettingStarted:Multitenant/en - Cronologia

Silvia il 08:18, 30 apr 2018

2018-04-30T08:18:02Z

← Versione meno recente		Versione delle 08:18, 30 apr 2018
Riga 43:		Riga 43:
	Upon the activation of a multitenant license, should there be any inbound/outbound lines already configured on the PBX, assigned lines will be created (one for each outbound line) and attributed to the "default" tenant. In this phase, it is possible to specify which numbering to present to the tenant, in order to reserve others for use by other tenants.		Upon the activation of a multitenant license, should there be any inbound/outbound lines already configured on the PBX, assigned lines will be created (one for each outbound line) and attributed to the "default" tenant. In this phase, it is possible to specify which numbering to present to the tenant, in order to reserve others for use by other tenants.

	Assigning lines to the tenants works similarly to configuring DID on the inbound lines of a single-tenant system; the difference is that the destination will not be an entity such as an extension, queue, group, or other, but rather an entire tenant. Routing to the final destination will ~~happen~~ according to the configuration of the tenant, following the concept of DID associated to a single assigned line.		Assigning lines to the tenants works similarly to configuring DID on the inbound lines of a single-tenant system; the difference is that the destination will not be an entity such as an extension, queue, group, or other, but rather an entire tenant. Routing to the final destination will be carried out according to the configuration of the tenant, following the concept of DID associated to a single assigned line.

	'''N.B.:''' During the conversion from single-tenant to multitenant lines, it is important to consider that all inbound manipulation rules (to a gateway or a domain), which in a single-tenant scenario were implemented before applying the DID routing rules, will remain '''associated to the inbound lines''' and will not be transferred to the tenant. It follows that the rules for assigning lines to tenants MUST be implemented by configuring the '''resulting selections AFTER the inbound manipulation rules'''.		'''N.B.:''' During the conversion from single-tenant to multitenant lines, it is important to consider that all inbound manipulation rules (to a gateway or a domain), which in a single-tenant scenario were implemented before applying the DID routing rules, will remain '''associated to the inbound lines''' and will not be transferred to the tenant. It follows that the rules for assigning lines to tenants MUST be implemented by configuring the '''resulting selections AFTER the inbound manipulation rules'''.

Silvia il 11:07, 28 feb 2018

2018-02-28T11:07:55Z

← Versione meno recente		Versione delle 11:07, 28 feb 2018
Riga 35:		Riga 35:
	During the activation of a multitenant license, KalliopePBX executes a series of internal procedures; some are automatic, while others require the admin to input the necessary parameters.		During the activation of a multitenant license, KalliopePBX executes a series of internal procedures; some are automatic, while others require the admin to input the necessary parameters.

	When operating in its default single tenant mode, KalliopePBX is already a multitenant system with a single predefined tenant enabled (associated to the "default" domain); the pbxadmin and the tenant admin (see [[AdminGuide:BasicConcepts:Users and roles\|"Users and roles"]]) are simply combined into a single user, "admin".		When operating in its default single tenant mode, KalliopePBX is already a multitenant system with a single predefined tenant enabled (associated to the "default" domain); the pbxadmin and the tenant admin (see [[AdminGuide:BasicConcepts:Users and roles/en\|"Users and roles"]]) are simply combined into a single user, "admin".

	When a multitenant license is activated, the two users are made distinct, separating the admin's configuration privileges (the operation of the single tenant) from those of the new user "pbxadmin". The users of a single tenant are now identified by the domain of the tenant they belong to (in this case, "default", so the admin becomes admin@default, and so on) so they can have the freedom to pick any username within the tenant.		When a multitenant license is activated, the two users are made distinct, separating the admin's configuration privileges (the operation of the single tenant) from those of the new user "pbxadmin". The users of a single tenant are now identified by the domain of the tenant they belong to (in this case, "default", so the admin becomes admin@default, and so on) so they can have the freedom to pick any username within the tenant.

Silvia il 14:21, 23 feb 2018

2018-02-23T14:21:09Z

← Versione meno recente		Versione delle 14:21, 23 feb 2018
Riga 35:		Riga 35:
	During the activation of a multitenant license, KalliopePBX executes a series of internal procedures; some are automatic, while others require the admin to input the necessary parameters.		During the activation of a multitenant license, KalliopePBX executes a series of internal procedures; some are automatic, while others require the admin to input the necessary parameters.

	When operating in its default single tenant mode, KalliopePBX is already a multitenant system with a single predefined tenant enabled (associated to the "default" domain); the pbxadmin and the tenant admin (see [[AdminGuide:BasicConcepts:Users and roles~~/en~~\|"Users and roles"]]) are simply combined into a single user, "admin".		When operating in its default single tenant mode, KalliopePBX is already a multitenant system with a single predefined tenant enabled (associated to the "default" domain); the pbxadmin and the tenant admin (see [[AdminGuide:BasicConcepts:Users and roles\|"Users and roles"]]) are simply combined into a single user, "admin".

	When a multitenant license is activated, the two users are made distinct, separating the admin's configuration privileges (the operation of the single tenant) from those of the new user "pbxadmin". The users of a single tenant are now identified by the domain of the tenant they belong to (in this case, "default", so the admin becomes admin@default, and so on) so they can have the freedom to pick any username within the tenant.		When a multitenant license is activated, the two users are made distinct, separating the admin's configuration privileges (the operation of the single tenant) from those of the new user "pbxadmin". The users of a single tenant are now identified by the domain of the tenant they belong to (in this case, "default", so the admin becomes admin@default, and so on) so they can have the freedom to pick any username within the tenant.

Silvia il 14:20, 23 feb 2018

2018-02-23T14:20:43Z

← Versione meno recente		Versione delle 14:20, 23 feb 2018
Riga 35:		Riga 35:
	During the activation of a multitenant license, KalliopePBX executes a series of internal procedures; some are automatic, while others require the admin to input the necessary parameters.		During the activation of a multitenant license, KalliopePBX executes a series of internal procedures; some are automatic, while others require the admin to input the necessary parameters.

	When operating in its default single tenant mode, KalliopePBX is already a multitenant system with a single predefined tenant enabled (associated to the "default" domain); the pbxadmin and the tenant admin (see [[AdminGuide:BasicConcepts:Users and roles\|"Users and roles"]]) are simply combined into a single user, "admin".		When operating in its default single tenant mode, KalliopePBX is already a multitenant system with a single predefined tenant enabled (associated to the "default" domain); the pbxadmin and the tenant admin (see [[AdminGuide:BasicConcepts:Users and roles/en\|"Users and roles"]]) are simply combined into a single user, "admin".

	When a multitenant license is activated, the two users are made distinct, separating the admin's configuration privileges (the operation of the single tenant) from those of the new user "pbxadmin". The users of a single tenant are now identified by the domain of the tenant they belong to (in this case, "default", so the admin becomes admin@default, and so on) so they can have the freedom to pick any username within the tenant.		When a multitenant license is activated, the two users are made distinct, separating the admin's configuration privileges (the operation of the single tenant) from those of the new user "pbxadmin". The users of a single tenant are now identified by the domain of the tenant they belong to (in this case, "default", so the admin becomes admin@default, and so on) so they can have the freedom to pick any username within the tenant.

Silvia il 10:41, 21 feb 2018

2018-02-21T10:41:12Z

← Versione meno recente		Versione delle 10:41, 21 feb 2018
Riga 6:		Riga 6:
	To activate a Kalliope Multitenant license, follow these steps:		To activate a Kalliope Multitenant license, follow these steps:

	1. If you wish to activate the license on a new machine, begin by following the instructions for [[AdminGuide:GettingStarted:VM\|activating a KalliopePBX VM license]] with the license key you were provided.		1. If you wish to activate the license on a new machine, begin by following the instructions for [[AdminGuide:GettingStarted:VM/en\|activating a KalliopePBX VM license]] with the license key you were provided.
	If you wish to activate a Kalliope Multitenant license on a KalliopePBX VM that was previously set up, skip to step 2.		If you wish to activate a Kalliope Multitenant license on a KalliopePBX VM that was previously set up, skip to step 2.

Silvia: Creata pagina con "Within each tenant there are further manipulation tables (both inbound and outbound) associated to the single assigned line attributed to it, allowing both the pbxadmin and th..."

2018-02-21T10:28:41Z

Creata pagina con "Within each tenant there are further manipulation tables (both inbound and outbound) associated to the single assigned line attributed to it, allowing both the pbxadmin and th..."

← Versione meno recente		Versione delle 10:28, 21 feb 2018
Riga 49:		Riga 49:
	Similarly, any outbound rule will be applied on a PBX level after the call has left the tenant and has been attributed to a specific outbound line.		Similarly, any outbound rule will be applied on a PBX level after the call has left the tenant and has been attributed to a specific outbound line.

	~~All'interno di ogni singolo~~ tenant ~~sono poi presenti nuove tabelle di manipolazione~~ (~~sia in ingresso che in uscita~~) ~~associate alle singole~~ assigned line ~~attribuite a ciascuno di essi~~, ~~permettendo quindi sia al~~ pbxadmin ~~che al singolo~~ admin ~~di tenant di effettuare le necessarie modifiche ai numeri chiamante e chiamato nelle varie fasi di gestione della chiamata~~.		Within each tenant there are further manipulation tables (both inbound and outbound) associated to the single assigned line attributed to it, allowing both the pbxadmin and the admin to implement the necessary modifications to calling and called numbers during the various phases of call management.

Silvia: Creata pagina con "Similarly, any outbound rule will be applied on a PBX level after the call has left the tenant and has been attributed to a specific outbound line."

2018-02-21T10:28:35Z

Creata pagina con "Similarly, any outbound rule will be applied on a PBX level after the call has left the tenant and has been attributed to a specific outbound line."

← Versione meno recente		Versione delle 10:28, 21 feb 2018
Riga 47:		Riga 47:
	'''N.B.:''' During the conversion from single-tenant to multitenant lines, it is important to consider that all inbound manipulation rules (to a gateway or a domain), which in a single-tenant scenario were implemented before applying the DID routing rules, will remain '''associated to the inbound lines''' and will not be transferred to the tenant. It follows that the rules for assigning lines to tenants MUST be implemented by configuring the '''resulting selections AFTER the inbound manipulation rules'''.		'''N.B.:''' During the conversion from single-tenant to multitenant lines, it is important to consider that all inbound manipulation rules (to a gateway or a domain), which in a single-tenant scenario were implemented before applying the DID routing rules, will remain '''associated to the inbound lines''' and will not be transferred to the tenant. It follows that the rules for assigning lines to tenants MUST be implemented by configuring the '''resulting selections AFTER the inbound manipulation rules'''.

	~~Parimenti~~, ~~le regole di uscita vengono applicate~~ a ~~livello di~~ PBX ~~dopo che la chiamata sia uscita dal~~ tenant ~~e attribuita ad una specifica linea di uscita~~.		Similarly, any outbound rule will be applied on a PBX level after the call has left the tenant and has been attributed to a specific outbound line.

	All'interno di ogni singolo tenant sono poi presenti nuove tabelle di manipolazione (sia in ingresso che in uscita) associate alle singole assigned line attribuite a ciascuno di essi, permettendo quindi sia al pbxadmin che al singolo admin di tenant di effettuare le necessarie modifiche ai numeri chiamante e chiamato nelle varie fasi di gestione della chiamata.		All'interno di ogni singolo tenant sono poi presenti nuove tabelle di manipolazione (sia in ingresso che in uscita) associate alle singole assigned line attribuite a ciascuno di essi, permettendo quindi sia al pbxadmin che al singolo admin di tenant di effettuare le necessarie modifiche ai numeri chiamante e chiamato nelle varie fasi di gestione della chiamata.

Silvia: Creata pagina con "'''N.B.:''' During the conversion from single-tenant to multitenant lines, it is important to consider that all inbound manipulation rules (to a gateway or a domain), which in..."

2018-02-21T10:28:27Z

Creata pagina con "'''N.B.:''' During the conversion from single-tenant to multitenant lines, it is important to consider that all inbound manipulation rules (to a gateway or a domain), which in..."

← Versione meno recente		Versione delle 10:28, 21 feb 2018
Riga 45:		Riga 45:
	Assigning lines to the tenants works similarly to configuring DID on the inbound lines of a single-tenant system; the difference is that the destination will not be an entity such as an extension, queue, group, or other, but rather an entire tenant. Routing to the final destination will happen according to the configuration of the tenant, following the concept of DID associated to a single assigned line.		Assigning lines to the tenants works similarly to configuring DID on the inbound lines of a single-tenant system; the difference is that the destination will not be an entity such as an extension, queue, group, or other, but rather an entire tenant. Routing to the final destination will happen according to the configuration of the tenant, following the concept of DID associated to a single assigned line.

	'''~~ATTENZIONE!~~''' ~~In questa procedura di conversione delle linee da~~ single ~~a multi~~-tenant ~~è importante considerare il fatto che le eventuali regole di manipolazioni in ingresso~~ (~~ad un~~ gateway ~~o ad un dominio~~) ~~che nello scenario~~ single-tenant ~~venivano effettuate prima dell'applicazione delle regole di instradamento dei~~ DID, ~~vengono mantenute~~ '''~~associate alle effettive linee di ingresso~~''' ~~e non sono invece trasferite al~~ tenant. ~~Ne consegue che le regole di assegnazione delle numerazioni ai tenant (assigned~~ lines~~) DEVE essere effettuata configurando le~~ '''~~selezioni risultanti DOPO le manipolazioni di ingresso~~'''.		'''N.B.:''' During the conversion from single-tenant to multitenant lines, it is important to consider that all inbound manipulation rules (to a gateway or a domain), which in a single-tenant scenario were implemented before applying the DID routing rules, will remain '''associated to the inbound lines''' and will not be transferred to the tenant. It follows that the rules for assigning lines to tenants MUST be implemented by configuring the '''resulting selections AFTER the inbound manipulation rules'''.

	Parimenti, le regole di uscita vengono applicate a livello di PBX dopo che la chiamata sia uscita dal tenant e attribuita ad una specifica linea di uscita.		Parimenti, le regole di uscita vengono applicate a livello di PBX dopo che la chiamata sia uscita dal tenant e attribuita ad una specifica linea di uscita.

	All'interno di ogni singolo tenant sono poi presenti nuove tabelle di manipolazione (sia in ingresso che in uscita) associate alle singole assigned line attribuite a ciascuno di essi, permettendo quindi sia al pbxadmin che al singolo admin di tenant di effettuare le necessarie modifiche ai numeri chiamante e chiamato nelle varie fasi di gestione della chiamata.		All'interno di ogni singolo tenant sono poi presenti nuove tabelle di manipolazione (sia in ingresso che in uscita) associate alle singole assigned line attribuite a ciascuno di essi, permettendo quindi sia al pbxadmin che al singolo admin di tenant di effettuare le necessarie modifiche ai numeri chiamante e chiamato nelle varie fasi di gestione della chiamata.

Silvia: Creata pagina con "Assigning lines to the tenants works similarly to configuring DID on the inbound lines of a single-tenant system; the difference is that the destination will not be an entity..."

2018-02-21T10:28:14Z

Creata pagina con "Assigning lines to the tenants works similarly to configuring DID on the inbound lines of a single-tenant system; the difference is that the destination will not be an entity..."

← Versione meno recente		Versione delle 10:28, 21 feb 2018
Riga 43:		Riga 43:
	Upon the activation of a multitenant license, should there be any inbound/outbound lines already configured on the PBX, assigned lines will be created (one for each outbound line) and attributed to the "default" tenant. In this phase, it is possible to specify which numbering to present to the tenant, in order to reserve others for use by other tenants.		Upon the activation of a multitenant license, should there be any inbound/outbound lines already configured on the PBX, assigned lines will be created (one for each outbound line) and attributed to the "default" tenant. In this phase, it is possible to specify which numbering to present to the tenant, in order to reserve others for use by other tenants.

	~~L'assegnazione delle linee ai tenant avviene in modo analogo alla configurazione delle selezioni passanti (~~DID~~) nel caso delle linee di ingresso di un sistema~~ single-tenant, ~~con la differenza che adesso la destinazione d'inoltro non sarà più una entità quali interni~~, ~~code~~, ~~gruppi o altro~~, ~~ma sarà un intero~~ tenant. ~~Nella configurazione del~~ tenant ~~sarà poi effettuato l'instradamento alle destinazioni terminali~~, ~~secondo il concetto di~~ DID ~~associati alle singole "~~assigned line".		Assigning lines to the tenants works similarly to configuring DID on the inbound lines of a single-tenant system; the difference is that the destination will not be an entity such as an extension, queue, group, or other, but rather an entire tenant. Routing to the final destination will happen according to the configuration of the tenant, following the concept of DID associated to a single assigned line.

	'''ATTENZIONE!''' In questa procedura di conversione delle linee da single a multi-tenant è importante considerare il fatto che le eventuali regole di manipolazioni in ingresso (ad un gateway o ad un dominio) che nello scenario single-tenant venivano effettuate prima dell'applicazione delle regole di instradamento dei DID, vengono mantenute '''associate alle effettive linee di ingresso''' e non sono invece trasferite al tenant. Ne consegue che le regole di assegnazione delle numerazioni ai tenant (assigned lines) DEVE essere effettuata configurando le '''selezioni risultanti DOPO le manipolazioni di ingresso'''.		'''ATTENZIONE!''' In questa procedura di conversione delle linee da single a multi-tenant è importante considerare il fatto che le eventuali regole di manipolazioni in ingresso (ad un gateway o ad un dominio) che nello scenario single-tenant venivano effettuate prima dell'applicazione delle regole di instradamento dei DID, vengono mantenute '''associate alle effettive linee di ingresso''' e non sono invece trasferite al tenant. Ne consegue che le regole di assegnazione delle numerazioni ai tenant (assigned lines) DEVE essere effettuata configurando le '''selezioni risultanti DOPO le manipolazioni di ingresso'''.

Silvia: Creata pagina con "Upon the activation of a multitenant license, should there be any inbound/outbound lines already configured on the PBX, assigned lines will be created (one for each outbound l..."

2018-02-21T10:27:58Z

Creata pagina con "Upon the activation of a multitenant license, should there be any inbound/outbound lines already configured on the PBX, assigned lines will be created (one for each outbound l..."

← Versione meno recente		Versione delle 10:27, 21 feb 2018
Riga 41:		Riga 41:
	At the same time, the external SIP lines (gateways, domains, trunks, terminations) and the tenants are decoupled, as the former are controlled by the pbxadmin and their visibility to the tenants needs to be mediated. This introduces the concept of an "assigned line", a numbering or numbering range attributed to an outbound line, which is assigned to the exclusive use of a single tenant.		At the same time, the external SIP lines (gateways, domains, trunks, terminations) and the tenants are decoupled, as the former are controlled by the pbxadmin and their visibility to the tenants needs to be mediated. This introduces the concept of an "assigned line", a numbering or numbering range attributed to an outbound line, which is assigned to the exclusive use of a single tenant.

	~~Al momento dell'attivazione della licenza multi-tenant~~, ~~in caso di presenza di linee di ingresso~~/~~uscita già configurate sul~~ PBX, ~~vengono implicitamente create delle linee assegnate~~ (~~una per ciascun linea di uscita~~) ~~che vengono attribuite (con selezione~~ "~~qualsiasi~~"~~) al~~ tenant ~~"default"~~. In ~~questa fase è possibile anche specificare solo alcune numerazioni da presentare al~~ tenant, in ~~modo da riservare poi altre nuemrazioni eventualmente presenti sulla linea ad altri tenant~~.		Upon the activation of a multitenant license, should there be any inbound/outbound lines already configured on the PBX, assigned lines will be created (one for each outbound line) and attributed to the "default" tenant. In this phase, it is possible to specify which numbering to present to the tenant, in order to reserve others for use by other tenants.

	L'assegnazione delle linee ai tenant avviene in modo analogo alla configurazione delle selezioni passanti (DID) nel caso delle linee di ingresso di un sistema single-tenant, con la differenza che adesso la destinazione d'inoltro non sarà più una entità quali interni, code, gruppi o altro, ma sarà un intero tenant. Nella configurazione del tenant sarà poi effettuato l'instradamento alle destinazioni terminali, secondo il concetto di DID associati alle singole "assigned line".		L'assegnazione delle linee ai tenant avviene in modo analogo alla configurazione delle selezioni passanti (DID) nel caso delle linee di ingresso di un sistema single-tenant, con la differenza che adesso la destinazione d'inoltro non sarà più una entità quali interni, code, gruppi o altro, ma sarà un intero tenant. Nella configurazione del tenant sarà poi effettuato l'instradamento alle destinazioni terminali, secondo il concetto di DID associati alle singole "assigned line".