Feature Wiki

Information about planned and released features

Tabs

Terms of Services

1 Requirements

The way ILIAS is currently handling user agreements and their confirmation by users is not satisfying for all ILIAS using institutions. They want ILIAS to show for each user when she or he has accepted which version of the user agreement.
 
Suggestions for improvement:
  • The administration of the user agreement in ILIAS should be separated from the language handling to have more space and options for interface design.
  • The user agreement of one language is defined as "Default" and will be used for all users that have selected a language that is not supported by a dedicated user agreement of this language.
  • The handling of user agreements should be moved from a file based solution in the Customizing directory of ILIAS to a file based solution in the ILIAS administration itself. As already known from the ILIAS file object it should be possible to upload a new version into an existing file object and get a new version number for it. This would allow to store which user has accepted which version of a language version agreement.
  • If a new version of an user agreement of a specific language is uploaded, all users that have accepted the former version of this user agreement have to accept the new agreement when they login the next time.
  • It should easily be possible to find out which user has accepted which version of an user agreement when. This could be done by entering the user's name or login and get the output when this user accepted which version of a user agreement in which language. This information should also be offered in a printable version.
  • Since there are a lot of ILIAS-Instances that do not use an user agreement at all, it should be possible to disable the requirement to accept a user agreement

2 Status

3 Additional Information

  • If you want to know more about this feature, its implementation or funding, please contact: Matthias Kunkel

4 Discussion

MJ 15 May: Where should we place the user agreement administration? Is it possible to use an ILIAS file object outisde the repository context (question to the maintainer of the file object)?

Matthias Kunkel, 15 May 2012: I see two options for placing the user agreement administration:
  1. A new administration node "User Agreement"
  2. An additional tab in "User Accounts" called "User Agreement"
Even if the User Account administration has already several tabs I personally prefer solution 2 – and would recommend to re-organise a bit within the user accounts administration, e.g. making some tabs like "Extended User Search" and "Export" to a subtab of "User Accounts".

MJ 15 May: So the re-organisation should be part of this concrete request or is this a seperate task/request/offer?

MJ 22 May: The re-organisation should be part of the implementation.

MB 22 May: After discussing the matter with MJ, we come to the conclusion, that variant 1 is the superior approach:
  1. Extensive and extensible 'user agreement' management would be handled in an own service.
  2. User account management is already a crowded place, adding more to it will grow the morass, not drying it. ;-)
    (We see a good point in moving the two menu entries and feel the time needed to do that would not exactly justify the administrative overhead involved in writing quotations, orders and invoices.)
  3. The term "user agreement" does not exactly reflect the nature of the document in question and misleads the feature into the proximity of the user account. "Usage agreement" or even "Terms of Service" are well known names for this kind of feature. The metaphor of signing this kind of legal document which we are to implement makes clear, that the whole thing is almost an act of signing a contract and as such should receive a proper and 'own' place to be managed at.

Matthias Kunkel, 22 May 2012: I agree with your conclusion and I like the title "Terms of Service". It makes clear that the user has to accept these terms and not to make an agreement with the provider of this installation.
It would be great if you could add the latest requirements to the Description text above so that this text describes how the feature would look like when implemented.

MB 22 May:
Before we jump into the details of the implementation, we have identified a few questions about the processes involved:
 
Terms and Conditions as described above are in some way 'connected' documents. This means, that there i.e. may be one authoritative version of which translations only exist for the users convenience. You see a case like that with the GPL in german: GPL v3 which adds the following disclaimer:
 
"Dies ist eine inoffizielle deutsche Übersetzung der GNU General Public License, die nicht von der Free Software Foundation herausgegeben wurde. Es handelt sich hierbei nicht um eine rechtsgültige Festlegung der Bedingungen für die Weitergabe von Software, die der GNU GPL unterliegt; dies leistet nur der englische Originaltext. Wir hoffen jedoch, daß diese Übersetzung deutschsprachigen Lesern helfen wird, die GNU GPL besser zu verstehen.
 
This is an unofficial translation of the GNU General Public License into German. It was not published by the Free Software Foundation, and does not legally state the distribution terms for software that uses the GNU GPL—only the original English text of the GNU GPL does that. However, we hope that this translation will help German speakers understand the GNU GPL better."
 
In such a scenario, should it be applicable, how do the "connected" documents behave and/or is the behaviour to be implemented as optional?
 
We see the following differing approaches, from which you please pick which one best suits the needs of the customer:
  • Ignore:
    The change of one ToS-text is relevant only to itself, forcing only those users to confirm their continued submission to the terms, which they have signed/accepted in the respective prior version. This may lead to a state in which different languages lead to different matters of fact, if i.e. a german version is at 10 while the "Suaheli" agreement is at v.3.
  • Head:
    The change of the default text is relevant to all users. This makes sense, if all non-default language texts have a disclaimer and link to the original text, so the users can read the legally binding text if they choose to. The change of any translation would not raise the need for reconfirmation, but remove a notice, explaining that the default text changed with the translation not being up to date. To make this feature round, we would recommend to add an "effective as of"-date, so a new head and its translations can be prepared without unintentionally(!) risking a state in which people sign an outdated text (again), even if the original text is all shiny and new (and from their perspective in a foreign language which they don't understand to the extent that makes it a legally binding mutual agreement).

JF 11 Jun 2012: We appreciate this improvement and schedule it for 4.4. We will discuss its details next time someone from Databay participates in the JF.

MB 21 Jun 2012: As Databay will participate (train tickets booked for me, probably BH will join as well), I put this again on the JF agenda for 25 Jun 2012.

JF 25 June 2012: There is still an open conceptual discussion with the customer. We would prefer that all language dependents texts are put under "one version" that is activated. A new version can be added and edited (including all language depenedent texts) in the meantime. When ready the new version could be activated and all users would need to agree to the new version.

JF 21 Jan 2013: We appreciate the idea and schedule it for 4.4. Please use the overlay also for the last screen. Please show the date of the last reset beside the reset button. If easy possible, think of storing the agreements not multiple times but identify them by a md5 string.

MJ 29 Jan 2013: Implemented and committed. Feel free to suggest other object icons (e.g. for the main menu).

Matthias Kunkel, 29 Jan 2013: Thank you for this detailed description of the implementation for 4.4. I can modify the icon to give it a better anti-aliasing. But what I would like to have is that you move the "Terms of Service" menu to the section "Users" as it is very much user related.

MJ 08 Feb 2013: I will move the node to the "Users" section.

MJ 13 May 2013: What is the expected behaviour for the following situation:
  1. The terms of service are globally enabled
  2. An administrator resetted the terms of service for all users (the field agree_date in database table usr_data is set to NULL for every dataset)
  3. A user is forced to accept (because  the terms of service (caused by the admin's reset) after login but there is no file available for the language
Current bahiour: The message "There is currently no user agreement text provided with this installation. Please contact the system administrator." appears and the user has the possibility to click a logout button.
 
Important: Accepting a non existent document (or rather the content) is (currently) not supported with ILIAS 4.4.
 
 

JF 27 May 2013: The behaviour outlined above is ok. It should not be possible to accept non-existing documents. The administrator contact should be clickable here (like in the footer).

MB 27 May 2013: There is a small issue connected to this: ILIAS does not (and should not, of course) ship "standard terms". On a fresh install, the signing of terms is activated. This makes logins - except for root - impossible unless either terms are created or the option is deactivated. In light of this, would you agree that the option should be inactive by default?

JF 27 May 2013: Please change the default behaviour for new installations as follows: Terms of Services is not activated (and therefore the problem described above will not appear). Once it is enabled a notification should be displayed that no user agreement is available and that this has to be added to ILIAS. Otherwise ILIAS could not be used. Next question: what happens with ILIAS installation that are migrating to 4.4 and have no agreement yet?

MJ 27 May, 2013:
  • There are already hints in the user interface if a document to accept is missing for a certain language.
  • We should add a database update step: We have to check whether or not there is at least one agreement file stored in file system. If not, we should deactivate the feature. If at least one file for one certain language was found, we should activate the feature. Then the administrator can easyly see (in the administration user interface) if agreement files are missing. @JF: Any objections?

JF 10 June 2013: @MJ: No objections.

MJ 11 June, 2013: Added database update step

5 Implementation

Michael Jansen, 17 Jan 2013: Feature implemented:

  1. First of all we introcuded a new administration node in the menu, because we removed all "User Agreement" related code from the language administration.

  2. This new area currently enfolds two views, the "Settings" view and the "Terms of Service" view. At the settings screen. the user has the possibility to globally enable/disable the terms of service.

  3. In the "Terms of Service" view a tabular presentation of all installed languages is given.
     
    For each language the user gets the information, whether or not a terms of service file exists.
    Furthermore, the location of the respective terms of service file, which the users have to accept after login, is printed in a separate table column. If the user clicks on the arrow icon (known from the ILIAS action menus), the content of the
    file appears in a layer with limited dimensions.
     
    Furthermore the user can reset (after a confirmation) the acceptance flag for all users of the installation.

  4. We introcuded new information concerning the users' terms of service status in each user profile of the user administration.

  5. You can collapse these information by clicking the checkbox.

Michael Jansen, 27 May 2013: The administrator contact, which appears if no user agreement exists for the chosen language, is now clickable (like in the footer).

Last edited: 17. Apr 2025, 15:00, Kunkel, Matthias [mkunkel]