Feature Wiki

Information about planned and released features

Tabs

Data Collection : Change Log for Data Collection Records

Page Overview

[Hide]

1 Summary

Making changes identifiable and comprehensible.

In a great variety of situations, it may be helpful, useful or essential to be able to identify when, by whom and what changes were made to the Data Collection records.

This may concern large datasets, or datasets where many different people create or edit entries, or simply in the case of especially relevant information.

2 Problem Statement

There is a recurring need to be able to identifiy when, by whom and what changes were made to the Data Collection records.

The objectives are ‘overview’, ‘transparency’ and ‘traceability’.

For this purpose, a 'Change Log' (German: 'Logbuch' or 'Prtokoll') is to be implemented.

3 Concept

Provision of a 'History' tab.

We store following informations in a UI Data Table with following options.

Headline: 'Change Log for Data Collection Records'

Columns / Content

  • Date and time
    • dd.mm.yyyy hh:mm
  • Unique ID
    • {Unique ID} must be capable of being called ? What is called? The form? The non-editable content of form in nearly plain text? The Detail View?
  • Context
    • Table: '{Table title}' (Note: this may be omitted if the dataset contains exactly one table)
  • Activity:
    • New Record
      • Full Content
    • Deleted Record
      • Full Content
    • Changed Record (former Content of Field(s))
      • Change to the field '{Field Title}' from the value '{Field value}' to the value '{Field value}'
      • Change to the field '{Field Title}' from the value '{Field value}' to the value '{Field value}'
      • Change to the field '{Field Title}' from the value '{Field value}' to the value '{Field value}'
      • [All for changes from 1 … n in one row per save]
      • [If Data Collection contains more than one table (Use Cases < 5%), the syntax is in addition changed to: Change to the field '{Field Title}' of table '{Table Title}' from the value '{Field value}' to the value '{Field value}']
    • Field(s)
      • Field '{Field Title}' is created
      • Field '{Field Title}' is renamed to '{New Field Title}'
      • Field '{Field Title}' is deleted
    • Table(s)
      • Table '{Table Title}' is created
      • Table '{Table Title}' is renamed to '{New Table Title}'
      • Table '{Table Title}' is deleted
      • [There are no details about inner table content stored.]
  • Change made by:
    • {Full name, Username, linked if available}
  • Actions / Link
    • Action “Open entry” or a link glyph
    • [It may be unclear here in which view the entry opens, possibly the default or the last used by the user themselves]
    • [In a way, it’s the same problem as with the unique ID]

Change Log Permissions:

In principle, access to the ChangeLog is bound to the ‘Edit settings’ permission. 
Otherwise, chaos is guaranteed, as individual users (or rather ‘roles’) are not supposed to see certain tables or views at all. It would then be necessary to specify once again, for the display of the ChangeLog, who is actually permitted to view which information. Furthermore, gaps in the ChangeLog resulting from this approach would corrupt the ChangeLog itself by interrupting the continuity of change history.

  • Tasks
    • Definition für alle Feldtypen. Besonders bspw. Formel, ILIAS-Objekt, Medienobjekt und Rating interessant » Konzeptarbeit vervollständigen.

{ This is the heart of the feature request: the concept. The content here shall:

  • make it possible to discuss this feature thoroughly on the Jour Fixe and make a decision
  • allow operators of ILIAS to understand the impact of this feature on their installations
  • allow all contributors to understand the impact of the change on their components and the complete system

So this is not about jumping through hoops, this is a crucial communication task in our software development process.

To help in this effort, we propose to use these guiding questions:

  • How will existing functionality look differently after the change?
  • How can an existing feature be used differently after the change?
  • Which mockups (or even scribbles) will help to understand changes in the user interface?
  • Which UI components will need to be introduced or modified?
  • How will your Feature Request change an underlying logic of the system or a component?
  • Which diagrams, graphs, tables or other forms of visual aid will help to understand that change in logic?
  • How will this affect operators or users who are already familiar with and rely on the current version of this feature?
  • Which changes might catch operators or users off guard or throw them off track, despite their familiarity with the current version of the feature or system?
  • How will this change existing data structures or established workflows?
  • How will this affect compatibility to previous ILIAS versions?
  • Which components of the system will be involved with or affected by the change?
  • Which dependencies to other software will be introduced when implementing this features?
  • Which technical specialities are worth considering to understand this change?
  • Which risks to the system or its operators are worth considering?

These questions are not meant to be answered one by one, but instead shall help you to create a coherent text that describes your feature. Tell us the story about your idea! }

4 User Interface Modifications

4.1 List of Affected Views

  • …

{ For all screens that should be modified, newly introduced or removed, please list the title and breadcrumb of all affected views. }

4.2 User Interface Details

{ For each of these views please list all user interface elements that should be modified, added or removed. Please provide the textual appearance of the UI elements and their interactive behaviour. }

4.3 New User Interface Concepts

None.

4.4 Technical Aspects

{ Necessary technical information have to be provided here, e.g. dependencies on other ILIAS components, the introduction of new third-party software (dependencies), necessary modifications in general services/architecture, potential security or performance issues. }

5 Non-Functional Implications

5.1 Security

None.

5.2 Privacy

Information about the changes is also stored with regard to the user who made them. This ensures that it is clear who made which change and when.

5.3 Accessibility Implications

None.

6 Process Information

6.1 Involved Authorities

If this request is related to multiple components, please list both authorities for all related components.

6.2 Contact

6.3 Funding

Funding status and funding parties are listed in the block 'Status of Feature' in the right column of this page.

If you are interested to give funding for this feature, please get into contact with the person mentioned above as 'Contact'.

7 Discussion

8 Implementation

Feature has been implemented by {Please add related profile link of this person}

8.1 Description and Screenshots

{ Description of the final implementation and the changed behaviour in the related components. Please add screenshots to visualise the changes if possible. }

8.2 Test Cases

Test cases completed at {date} by {user}

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

8.3 Privacy

Information in privacy.md of component: updated at {date} by {user} | no change required

8.4 Approval

Approved at {date} by {user}.

Full Screen

Last edited: Today, 07:24, Samoila, Oliver [oliver.samoila]