Feature Wiki

Information about planned and released features

Tabs

Detection of existing files

Page Overview

[Hide]

1 Initial Problem

When a user uploads files whose titles already exist, a duplicate of the file is created. It does not matter if it is an updated version of the file or an exact copy, a duplicate is always created. 
The system does not warn the user that the file already exists. 

2 Conceptual Summary

If the system detects that a file with the same title already exists, it should warn the user and display a prompt:

A file with this title already exists. What do you want to do?
- Replace the existing file
- Add the file anyway
- Cancel

If the user chooses "Add the file anyway" a suffix "- (copy)" should be added to the filename.

Mockup - upcoming

3 User Interface Modifications

3.1 List of Affected Views

  • file/upload

3.2 User Interface Details

We would suggest the prompt as a modal with selectable buttons. If the user moves several files, there should be a seperate dialogue for every already existing file. 
The dialogue should be something like this: "a file with the title "[title of file]" already exists.
The modal should have three options as buttons: 1. replace 2. add as "(copy)" 3. don't copy II cancel II skip

3.3 New User Interface Concepts

It will be discussed in the UI clinic.

3.4 Accessibility Implications

Modals can be a problem for screen readers. The suggested implemtation follows the modal from the conformation of the deleting of a Page-Object.

4 Technical Information

{ The maintainer has to provide necessary technical information, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues. }

5 Privacy

{ Please list all personal data that will need to be stored or processed to implement this feature. For each date give a short explanation why it is necessary to use that date. }

6 Security

{ Does the feature include any special security relevant changes, e.g. the introducion of new endpoints or other new possible attack vectors. If yes, please explain these implications and include a commitment to deliver a written security concept as part of the feature development. This concept will need an additional approvement by the JourFixe. }

7 Contact

8 Funding

If you are interest in funding this feature, please add your name and institution to this list.

  • ILIAS.nrw
  • TH OWL

9 Discussion

UI Clinic, 17 NOV 2022: Minutes of meeting (row 42):

The preliminary discussion with the file maintainer Fabian Schmid showed that the feature is more complex and shows more problem households than first thought. The feature request should be adapted according to the discussed points.

Relevant points from the discussion:

  • Verification is only done within own containers where a file is uploaded.
  • ILIAS knows 2 titles of a file: The object title (self-selected when uploading a file) and the actual title of the file (which is also displayed when downloading). Which one is used for the check? Should only the title be checked or also whether the content has remained the same? Recommendation: Name and content must match (define 3 usecases).
  • In ILIAS there is the versioning concept. You can't necessarily draw one-to-one conclusions from the file behavior of operating systems. So there are basically three possible actions: (a) file is uploaded like a new file (b) a new version is created (c) the previous versions are replaced.
  • In ILIAS there are two different ways to upload a file: (I) Add new object, you are on the content page in a form (II) Drag&Drop on container, a modal opens.
  • Modal as solution is not possible according to current status. With upload variant (II) one would have a modal in a modal. A roundtrip modal is difficult because the "second page", where you decide what to do in case of a check, cannot be shown optionally.
  • What happens if I upload multiple files, but where I only have to make such a decision for 1, but not for the others?
  • There needs to be an "intermediate" page that allows a "decision" after the review. How can such a screen with form elements per duplicate look like? First "bubble" ideas: Item with metadata and FormInput? New KS Form Decision with more info? Intermediate page Content with FormInputs? Slate?...
  • The trigger for the decision (new, version, replace version) must not be a button, because you would leave the view after clicking. Concerns how can a multiple decision be made on one screen (file 1 new, file 2 version, file 3 replace version).
  • It is noticeable that the current table for copying and exporting objects has a similar problem, perhaps the solution can be used here as well.

We recommend in a first step to update the feature request to list the important usecases and to answer the question "Which information must a user have to make the decision a, b or c per file". Subsequently, solutions can be sought in collaboration with the maintainer. It is also possible to arrange a new appointment in the UI Clinic.

10 Implementation

{ The maintainer has to 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}.

Last edited: 18. Nov 2022, 15:45, Seiler, Yvonne [yvseiler]