Show Advanced KnowledgeHide Advanced Knowledge

Introducing Transfer-Service

1 Requirements

We have the issue with multiple institution that by synchronizing huge userbases into ILIAS some user have two different accounts on ILIAS. This happens if employers change job internally and get a new Account in e.g. LDAP, this leads to a second account in ILIAS as well. This may lead to some cases where a enduser has his data and test passes distributed on several ILIAS accounts. We describe a concept in this document how important data from a user, e.g. learning progress, test passes, etc. can be transfered from one user to another.

1.1 Analysis

The complexity in transfering data from one user to another lies in the heterogenity of the data to transfer. Modules and services that need to be able to be transfered have very specific data structures and need in almost all cases a specialized implementation. For example if a test resuled is transfered to a user that already passed this test, the transferer needs to specify which data is preferred. Furthermore the technical implementations for the different ILIAS items is too specialized to allow a generic method to transfer data between users. We thus suggest a concept  for an interface to transfer user data and after that different modules and services can implement that interface when needed.

1.2 User Interface

In the user administration (Administration -> User Administration) a new toolbar button is introduced: "Transfer User Data". By clicking this button we get to a selection, where the user can select from and to what user data should be transfered. This interface will be similar to the user administration table in order for the user to be familiar with the search (see screenshots).

After selecting the users for the transaction the user can click on "Transfer data..." and reaches a new view (see screenshot). In this view he can select what data he wants to transfer, grouped by their type. After the selection is made the user can transfer the data. If some transactions are irreversible a warning will be shown.

1.3 Implementation

The user data transfer will be implemented as a service. Each module and service that wants to offer data transaction from one user to another has to declare this in the module.xml respectively in the service.xml and has to implement a certain interface.

The data transfer service will offer an interface for other modules, services and plugins to implement. When listing items available for transaction the service will loop through the modules/services implementing the interface and gather which items can be transferred.

The interface for the user data tranfer looks as follows:

interface ilTransferInterface {



/**
* Returns a list of transferable items. Important: The user can make a selection, not all will be transfered
* @param $fromUser ilUser
* @param $toUser ilUser
* @return ilTransferItem[]
**/
public function getElements(ilUser $fromUser, ilUser $toUser);



/**
* Moves the item specified in $items from one user to another.
* @param $items ilTransferItem[]
* @param $fromUser ilUser
* @param $toUser ilUser
* @param $transactionId int The transaction Id will be used if the user wants to undo the transaction.
* @throws ilTransferItemsException
**/
public function doTransaction(array $items, ilUser $fromUser, ilUser $toUser, $transactionId);



/**
* @return bool returns true iff you offer a undo functionality of a tranaction.
**/
public function supportsUndo();



/**
* @param $transactionId int
* @param $elements ilTransferItems[] The original set of elements that was given to the transaction call.
**/
public function undoTransaction($transactionId, array $elements);
}



class ilTransferItem {
protected $id;
protected $title; //used for element display
protected $info //used for element display
protected $type; //used for icon display
protected $additionalParameters; //Custom parameters.



// [Getters und Setters]
}



class ilTransferException extends ilException {



protected $userFeedback;



/**
* @message string The usual message for an exception
* @userFeedback string Is used for a summary for the enduser.
**/
public function __construct($message, $userFeedback);



}

The service offers the GUIs as displayed in the mockups above. Furthermore it aggregates the transfer of user data of different services/modules/plugins.

The responsibility pf the implementation of the transaction of  the different items lies with the different modules/services. A first priority for transferable items are as follows:

• Global and local roles
  • Course memberships
  • Group memberships
  • Global roles
  • Self created roles
• Test passes
• SCORM passes and results
• Surveys
• Object ownerships

Important: Learning progress does not get transferred but is recalculated after each transaction.

2 Additional Information

• Idea / concept:
• Interest in funding: Customers of studer + raimann ag
• Maintainer: Fabian Schmid, sr.solutions
• Implementation of the feature is done by (will be set by Jour Fixe / maintainer)
• Testcases by: (please add your name if you want to create the testcases for this feature)

3 Discussion

JourFixe, ILIAS [jourfixe], Dec 21, 2015: We appreciate the introduction of this new service and schedule it for 5.1. Please contact the related component maintainer and deliver necessary methods and interfaces so that they can implement this service in their components for transfering the requested user data.

AT 2016-01-14: I took the liberty to number the mock-ups for easier reference in discussion. 

• Labels: Benutzerdaten übertragen / transer service is not a good lable. It is way too generic. Please re-label in de and en. 
• Mock-up 1: What happens after clicking on "Benutzerdaten übertragen"? How is the account that data is harvested into selected? Please provide mock ups of all steps and explain them in more detail. I am not sure whether a button in a tool bar (typically triggering a specific action) is the best control. 
• Mock-up 2: The control above the filter is unknown to me. I am not sure what controls are supposed to be used for "Bitte wählen". Please refer to similar control in ILIAS or to Kitchensink. There is no action column in the table nor is there a known action "Wähle". Maybe the Multi-Actions above the table? Maybe action colum? Please provide mock ups outlining the controls and outline of all steps and explain them in more detail.
• Mock-up 3: Is this an underworld or a sub-tab or what else? How will passes be singled out for transfer? Will the un-singled passed stay with the other account? What happens to learning progress? How is this GUI supposed to grow if the user transfer service is to include more objects? Do I have to work through all of the tabs before I trigger my merging action? Specifically what kind of control ist on top in the giant arrow "Benutzerdaten übertragen"?  I feel that the User Management there are already implementations for what I gather is supposed to be happening here. The new and the old interfaces should be harmonized as they do the same thing: 
  1. Listing  repository objects a specific account owns
  2. Listing roles of a specific account 
• How will the confirmation/overview over data to be transeferred look like? How is this list organised?
• Curiosity: How are conflicts handled? i.e. both accounts have completed the same survey and one is about merging the results into one account? What is the plan for preventing this and how are conflict messages displayed?
• Curiosity: Is the account from which the data is taken deleted or just ripped of some data? If the later will there be any indication of "ripped account" provided? how will it look like? Where and how will the undo option be offered and how are the steps carried out 
• How will the merging be communicated to the accounts in question? Data Integrety info message? How will it communicate to the objects whose results were transfered? 

 2016-01-16:


Thanks for the review Alexandra!

--Labels: Benutzerdaten übertragen / transer service is not a good lable. It is way too generic. Please re-label in de and en.
. As it is a generic service to transfer user data from one user to another, I'd suggest: User Data Transfer, Benutzerdaten Übertragen/Transfer.

--Mock-up 1: What happens after clicking on "Benutzerdaten übertragen"? How is the account that data is harvested into selected? Please provide mock ups of all steps and explain them in more detail. I am not sure whether a button in a tool bar (typically triggering a specific action) is the best control.
. In mockup 1 a click on "Benutzerdaten übertragen" will lead you to mockup 2. mockup 2 is discussed below.

-- Mock-up 2: The control above the filter is unknown to me. I am not sure what controls are supposed to be used for "Bitte wählen". Please refer to similar control in ILIAS or to Kitchensink. There is no action column in the table nor is there a known action "Wähle". Maybe the Multi-Actions above the table? Maybe action colum? Please provide mock ups outlining the controls and outline of all steps and explain them in more detail.
. I'd revoke my previous mockup as it doesn't follow any ILIAS guidelines. I'd suggest a form that is more user friendly: A simple form where you can choose from user and to user. This would mean we need a new user input element: SingleUserSearchInputGUI. It would need the Select2 Library. It would use ajax to load users and reuse ilObjUser::searchUser($term) to find them. Thus it implements pretty much the current searchUser that is currently only available in the toolbar.

-- Mock-up 3: Is this an underworld or a sub-tab or what else?
. In the image given they are subtabs. But I'm open for discussion. Maybe a select would be better?

-- How will passes be singled out for transfer?
. By clicking the checkbox.

-- Will the un-singled passed stay with the other account?
. Yes, it will.

-- What happens to learning progress?
. Depending on what's transfered the learning progress has to be reevaluated for both users. That's the responsibility of the given module.

-- How is this GUI supposed to grow if the user transfer service is to include more objects?
. See above. Maybe a select is a whiser choice?

-- Do I have to work through all of the tabs before I trigger my merging action?
. You have to check everything that you want to transfer, yes. I'd suggest to add a "select all" per data type.

-- Specifically what kind of control is on top in the giant arrow "Benutzerdaten übertragen"?
. This is a "green" main action button.

-- I feel that the User Management there are already implementations for what I gather is supposed to be happening here. The new and the old interfaces should be harmonized as they do the same thing:
Listing repository objects a specific account owns
Listing roles of a specific account
. The GUIs don't display repository objects or roles specifically but a more general style of transferable data. ILIAS tables are not really flexible for reuse on the coding side. Thus I fear reuse, except from conceptual reuse, will not be possible.

-- How will the confirmation/overview over data to be transeferred look like? How is this list organised?
. A textual list of what's being transfered + a ilUtil::sendInfo (blue box) if somehting's irreversible/may get overriden.

-- Curiosity: How are conflicts handled? i.e. both accounts have completed the same survey and one is about merging the results into one account? What is the plan for preventing this and how are conflict messages displayed?
. That's up to the module maintainers. Generally a warning is displayed in the confirmation screen if some data is overriden/irreversible.

-- Curiosity: Is the account from which the data is taken deleted or just ripped of some data?
. I'd suggest the taken data is deleted. For example with object ownership there's no other way.

-- If the later will there be any indication of "ripped account" provided? how will it look like? Where and how will the undo option be offered and how are the steps carried out
. The undo option is not offered yet. We save the transfers made for future use. Generally speaking the undo function can be done in a first step by doing the same transfer operation in the other direction.

-- How will the merging be communicated to the accounts in question? Data Integrety info message? How will it communicate to the objects whose results were transfered?
. The user's in questions will not be informed automatically by ILIAS. This lies within the responsibility of the administrator.

Killing, Alexander [alex], 16 Jan 2017:

• ilTransferItem: I understand that the IDs and types are repository types and IDs (it says that the type is used for icon presentation), is this correct? But the mockup is including "Test Resultate" which are sub entities of tests. Test objects would also include concepts like authorship for test questions and other things. What kind of objects/entities does the service handle?
• Undo Operation: "Generally speaking the undo function can be done in a first step by doing the same transfer operation in the other direction." But then the components need to mark data records as being imported from another account. The transfer service seems only to have knowledge about top repository object ids. But in tests e.g. you would have sub entities like test runs. So the test would need to store this information for each test run (has been imported from another account with transaction ...). This may results in lots of tables having to add these transaction information. What happens if this kind of data is now being updated by the user before the undo action (how long will the undo action be available)? E.g. if an unfinished test run is transfered and the target account finishes this?

JourFixe, ILIAS [jourfixe], 16 Jan 2017: We still appreciate this feature request and schedule it for 5.3. But we don't want to support 'undo' actions in a first version due to related conceptual problems.

• 'Mock-up 2' should get title: "User Administration" and uses a default form incl. 'Cancel' button. This screen should also offer radio buttons to select which data types should be transfered (e.g. "role assignments")
• 'Mock-up 3' should get a standard table with multi-select and buttons for 'Transfer' and 'Cancel'. The filter above is a default table filter.

4 Implementation

{please give a description of the final implementation and add screenshots if possible}

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.