| 2.5 Availability
04. Multi-Tenancy Policy | |
|---|
| 2.5.04 Multi-Tenancy Policy: | | 1. Bespoke Application Services are enjoyed by a very large number of independent organisations in all parts of the world. | | 2. Application services are not constrained by any industry or market sector; and it has been enlightening to discover that what appear to be different markets share a lot of common business requirements. | | 3. Application services are not constrained by any country, culture or language; and it is pleasing to discover that people in all parts of the world share common business requirements. | | 4. A key limiting factor has been the configuration of a new application service in a way that has strict barriers between applications, yet many functions are virtually identical. | | 5. The multi-tenancy solution is internally called "c03" as the tenent identifier. | | 6. A common set of services can be reused by many different tenants without any data leak from one tenant to another because all data records have an tenant assigned "c03". |
| 2. Tenant Identification: | | 1. Each Bespoke Application Service is assigned its own unique "c03" field value and that field value is replicated in every record that is owned by that tenannt. | | 2. For many years this simplistic partitioning of all data worked with not leaking of data from one tenant to another. | | 3. Then came the diary driven bespoke application services that required a tenant to be able to have any number of people, any number of companies and any number of projects; all with a unique HR identifier. | | 4. Some approved people can only view certain projects and may not have access to company data. | | 5. To switch from project to project, the "c03" tenant identifier is dynamically changed, but only to a project owned by a tenant. |
| 3. Dynamic Tenants: | | 1. Every tenant has their own unique "c03" tenancy number that is the tenants company primary key. | | 2. All data owned by the tenant contains the same "c03" tenant identifier. | | 3. Then came the diary driven bespoke application services that required a tenant to be able to have any number of people, any number of companies and any number of projects; all with a unique HR identifier. | | 4. Some approved people can only view certain projects and may not have access to company data. | | 5. To switch from project to project, the "c03" tenent identifier is dynamically changed, but only to a project owned by a tenant. | | 6. The effect is that each tenant has one primary tenancy number and any number of dependent tenancy numbers. The tenants company record primary key is the primary tenancy number. Each HR record owned by that tenant are dependent tenancy numbers that may be used by approved people owned by the tenant. | | 7. It is not possible to tenants to have any data shared with any other tenant, so it is not possible for any dependent tenacy number to be shared with any other tenant. |
| 4. Benefits: | | 1. When a new tenant is initiated, the following data is mandated: | | (1) Bepoke program name to reflect the tenants company name. | | (2) Bepoke public home page to reflect the tenants business message. | | (3) Bepoke private welcome page to reflect the tenants requirements - this may be generic. | | 2. It is practical to engineer all other services to be multi-tenancy using "c03" as a unique identifier to limit data access. | | 3. It is acceptable that an approved person cam switch to a dependent tenancy "c03" because that dependent key must be unique and only owned by the tenant. | | 4. Every tenant has any number of HR records for people, companies and projects and each HR record key is a potential dependent "c03" tenancy number. | | 5. The effect is that each tenant can have a very large number of sub-tenancies that are typically sites and projects. | | 6. An effect is that each approved person can be their own tenant with private and personal data that cannot be accessed by any other person - not even their own tenant or company. |
| 5. Procedures: | | 1. Any tenent may add new HR records for people, companies or projects - each HR record containts the tenants "c03" number. Each signed in person can only view their assigned tenants records - "c03" must match. | | 2. After a person has added a new project with a "c03" that matches their tenancy number, then the key to that project record becomes a potential dependent tenancy number. | | 3. A list of dependent tenancy number can be shown and one selected - it is normally known as select from a list of projects. | | 4. Selection of the project makes that project record key the dynamic tenancy number so the only data that can be viewed is that pertaining to that project. | | 5. Project dependent data can be added as tasks and documents where the "c03" value is that of the project and not the tenant. | | 6. An effect is that each approved person can be their own tenant with private and personal data that cannot be accessed by any other person - not even their own tenant or company. |
| 6. How does it work: | | 1. Built into every search select is a default clause to limit the search by "c03=site". That is all. | | 2. When the "tenant" number changes to a dependent project or dependent person, the clause limits the selection to only the data that is applicable to a person who has selected that HR record. | | 3. When the persons original "welcome" page is viewed, the person may select any HR record from the list where the list only shows the tenant company and the tenants HR children as people, companies and projects. | | 4. Every persons record is a HR record with a "c03" tenancy number that is used to switch the person to that tenancy site when the person signs in. | | 5. If a persons role and welcome page is designed to reduce a persons rights to one project, then the persons default welcome page will switch the persons tenancy to that project. | | 6. Where a person has self-registered and has no rights, the person has a tenancy "c03" that is equal to their own persons record so they can only process their own data. A self-registered person may be adopted by a tenant by changing the persons "c03" to that of the tenant, but that means viewing the self-registered persons data that cannot be seen by any tenant! The self-registered person can process their own data and may request to be adopted by a known tenant - the tenant can then confirm that transaction and Eliza will switch the "c03" tenancy for the person. A tenant can request to adopt a self-registered person (by name and mail) and Eliza will switch the self-registered person to belong to the tenant. | | 7. An approved person can only belong to one tenant, however the same physical person may have multiple HR records and each HR record belons to one tenant. A persons name and email address does not have to be unique, however warnigns are issued when the same email address is reused by a person at self-registration time. |
| 7. Look Up Lists: | | 1. Built into every every lookup is a default clause to limit the selection by "c03=site". | | 2. This means that a person cannot view data that belongs to any other tenant. | | 3. Where a persons rights only grant tham access to one project, then that project hass a "c03" that is dependent on the tenants "c03" sp no data loss is possible. | | (123) Site: Lookup with c03=site matching the current selected site. | | (125) User: Lookup with c03=user matching the users tenancy site. | | (127) ASP: Lookup for ASP or read-only use. |
| 8. Recursion: | | 1. Every owner is a tenant who can have any number of HR records as people, companies and projects - each as a dependent tenant. | | 2. Every dependent tenant can have any number of HR records as people, companies and projects - each as a double-dependent tenant. | | 3. This dependent heirachy has no theoretical limit as each private person can have their own projects, companies and other people. | | 4. The architecture is sound, but testing multiple levels of recursive dependents will be hard to demonstrate. | | THOUGHT: | | 1. A person self-registers free of charge - they are only able to process their own information. | | 2. That person adds some other people, some clients, some suppliers and some projects. | | 3. The person select one of their projects and for that project, adds some people, some suppliers and some projects. | | 4. Each dependent project may have other dependent projects added - confusing and hard to find, but perfectly logical. | | 5. Every person, company and project has a diary and every diary has tasks, documents, accounts and many other objects. | | 6. Every kind of object has its own "c03" tenancy that may be dependent on other tenancies that are dependent on higher tenancies. | | 7. Privacy-by-Design is working very well and its simplicity will foil the average criminal. |
| Diary selection | | 1. When a person signs in their profile assigns their user key and owner key. A persons owner key cannot change and that identifies the data they may access. | | 2. Each owner may have any number of diaries for each person, company and project that they own. | | 3. Every record has a c03 owner key that identifies the ownership of that data - ownership cannot change. | | 4. The owner of a project is the supplier - every project has an assigned client or customer. |
| Access Control | | 1. Three levels of welcome page is deployed as: | | (1) ASP root level welcome page for an ASP person who can switch to different owners. | | (2) Owner level welcome page for 95% of people who have access to one owner data. | | (3) Diary level diary or project page. | | 2. SESSION_USER_WELCOME is fixed page number assigned for each person to be shown when Welcome button is pressed. | | 3. SESSION_USER_NAME and SESSION_USER_KEY and SESSION_USER_ROLE are fixed values assigned for each person. | | 4. SESSION_USER_SITE is assigned as the owner key that is assigned by the owner welcome page - every record created has this owner key in c03. | | 5. SESSION_SITE_NAME and SESSION_SITE_KEY are selected for each HR entity to show a diary or project related data. | | 6. SESSION_SITE_CUSTOMER key is selected for each site/project as the company that pays for that project. SESSION_SITE_SUPPLIER is the SESSION_USER_SITE key for any selected site/project. |
| Diary Ownership | | 1. A company diary has: SESSION_SITE_NAME and SESSION_SITE_KEY as the selected company. Where the company type is a customer, then SESSION_SITE_CUSTOMER is the same as SESSION_SITE_KEY and SESSION_SITE_SUPPLIER is the owner as SESSION_USER_SITE. Where the company type is a supplier, then SESSION_SITE_CUSTOMER is the owner as SESSION_USER_SITE and SESSION_SITE_SUPPLIER is the owner as SESSION_SITE_KEY. Where the company is the owner, then SESSION_SITE_CUSTOMER and SESSION_SITE_SUPPLIER is the owner as SESSION_USER_SITE. | | 2. A personal diary has: SESSION_SITE_NAME and SESSION_SITE_KEY as the selected person. The SESSION_SITE_CUSTOMER is the same as SESSION_SITE_KEY and SESSION_SITE_SUPPLIER is the owner as SESSION_USER_SITE. | | 3. A project diary has: SESSION_SITE_NAME and SESSION_SITE_KEY as the selected project. The SESSION_SITE_CUSTOMER is the key of the customer who pays and SESSION_SITE_SUPPLIER is the owner as SESSION_USER_SITE. |
| Document Control: | | 1. Document Title: Multi-Tenancy Policy. | | 2. Reference: 162505. | | 3. Keywords: ITIL, Multi-Tenancy Policy. | | 4. Description: Multi-Tenancy Policy. | | 5. Privacy: Public education service as a benefit to humanity. This is not legal advice. | | 6. Issued: 11 Dec 2016. | | 7. Edition: 1.2. |
|
|