General idea

The general idea of this issue is to extend the multitenenacy capabilities of translate5, so that it is possible to 

• overwrite system configuration client specific (where it makes sense)
• overwrite the layout client specific
• overwrite and extend user roles and rights client specific
• use client specific workflows, that are defined on PHP level bei extending the general workflow class
• server side filtering of all data, that is client sensitive, if a client ID is set for the user / session, so that the user can only see the data of this client, no matter what filtering he sets in the front end. This filter will only be used as a double security for users, that only belong to one client and have no general admin or pm rights in translate5. For users with general admin or pm rights in translate5, when a client id is set, no server side filtering is done, but only the browser side filtering is set in the respective grids, so that only the data for this client is shown (but can be changed by the user by changing the filter of the grid).

The goal is to be able to have different clients in one translate5 instance, that have different user roles, user rights, GUI layouts and workflows and only see the data that belongs to their company. On the other hand the goal is to still have all data in one translate5 instance and still enable general translate5 PMs and admins to see the data of all clients and switch between client specific data views (as developed in TRANSLATE-1397, Multitenancy phase 1).

In this context important is the feature "TRANSLATE-1457 translate5 as openID Connect client / run the same translate5 instance on different subdomains", that will be implemented in the near future. With TRANSLATE-1456 it will be ensured, that TRANSLATE-1457 also works in the multitenancy context.

Implementation

Extension of customer administration

In the customer administration db backend a new unique text key "textId" is introduced.

This key is used as a reference in the different new db tables for client specific ACL rules (ACL stands for Access Control list) and client specific system configurations.

So far we avoid to establish an admin front-end for handling the overwriting / extension of the ACL and the overwriting of the default system configs per customer. 

The system administrator will be able to do this directly in the database. This new text key will NOT be shown in the browser GUI.

Client specific ACL rules

It will be allowed overwrite the existing rights for defaults roles in a new db table LEK_client_acl_rules.

It will be allowed to define new client specific roles in the LEK_client_acl_rules table (like client specific PMs and client specific admins with specifc rights. And like client specific roles, that do not exist at all in translate5.

For each role definition in the LEK_client_acl_rules table it will be possible to define, for which default system role it will see the change notifications in case of a translate5 update.

translate5 has a number of functionalities, that directly depend on a specific role, which must be refactored:

• The changeLog Klasse shows different contents for editor,admin,pm
• The installer sends mails to the admin
• The following classes use the system role PM als Workflow role PM:
  • PrevNextSegment.js
  • the AutoStates::getRoleToStateMap
  • SegmentController::getUsersAutoStateIds
  • Notification::createNotification
  • notifyNewTaskForPm.phtml
  • Notification::addCopyReceivers
  • WorkflowAbstract::getAddableRoles
  • Workflow/Actions werden öfters die ACL_ Konstanten 
• In all cases, it must be ensured that only the roles corresponding to the current client can be used for the roles in the frontend.
• Translators should be able to act non-specifically as a translator works for different clients. Here all data must come from the task.
• migration of current client specific ACL rules

Customer specific configuration

Currently there are 235 configuration parameters defined in the db table Zf_configuration. For many of these parameters (at least half of them) it makes sense to potentially overwrite them by client or even by task.

Some of these parameters are related to the layout and the workflow. Therefore to be able to customize layout and workflow by client, the best way from a perspective of consistent system development and a future proof system and architecture is to be able to overwrite the system configuration by client.

This overwriting will be implemented in a way that makes it relatively easy to extend this mechanism further in the future and overwrite the system config or client config by task with a task template.

In the Zf_configuration it will be defined, for which entry an overwriting is allowed, as this is not possible / does not makes sense for all entries.

To make all of this work, also a number of areas where the current config is used must be refactored.

Client specific layouts

Precondition: client specific configuration.

Currently it is already possible to overwrite a number of parts of the layouts (like header, login page) in a "client-specific" directory. This mechanism only enables to change the layout for this one installation (client basically means a client of MittagQI, using translate5 here).

The current defined overwritings are kept as system default. 

So the following mechanism is implemented:

• By default the translate5 default layouts are used
• If these are overwritten in the default client-specific directory (should be called "installation-specific), those layouts are used (not all must be overwritten, if something is not overwritten, still the default is used)
• If for the currently selected client (client according to the multitenancy feature) a specific layout config exists, values defined there overwrite the system default and the installation-specific default.

• The current subdomain (e.g. client123.lsp.de - see TRANSLALTE-1457) sets for users that are not logged in the current cliendId and therefore the layout.
• After login the clientId and therefore the layout is set according to the logged in user. Therefore it is possible, that a user logs into translate5 on client123.lsp.de, but sees the layout of clientABC.lsp.de, because the logged in user belongs to the LSP itself, has the right to see all data of all clients and has changed to clientABC.

In addition to the layout elements, it is already possible to overwrite the GUI texts of translate5 per installation in the installation-specific directory. This will also be extended, so that it will be possible to overwrite the GUI texts by client.

Client specific overwriting of term mark-up inside of the segments

Currently it is NOT possible to overwrite the layout of this mark-up on installation base. This will be changed so that it is possible to even overwrite it on client base.

Workflows

Currently it is possible to define different workflows on the PHP level in translate5 and select a defined workflow in the front-end. If this selecton really still works is not tested / never used. Also it is implemented in a way, that does not make sense on the current state of development of translate5 any more. Therefore this GUI selection of the workflow is removed.

Instead it will be possible to set the currently used workflow by client in the client-specific configuration.

Potential further development - not part of this issue

Potential enhancement to secure the client instances from each other:

• Several Zend_DB instances can be used, therefore one instance points to one DB, the other instance to another.
• Therefore we could perspectively use a separate DB per client
• The few general tables are also in a separate DB (session, mem cache, dbversion, worker, clients, general Zf_ tables)
• Foreign keys can be created across DB boundaries
• Problem: FK worker to task, wrong direction, worker table but should be unique → creation of tables difficult because in FK the DBName must be pure
• installer must be adjusted etc.