Feature Wiki

Information about planned and released features

Tabs

One stop for defining allowed upload files

1 Initial Problem

At the time being, administrators have to define the allowed upload types for the file object in Administration » Files and the type for allowed files in media objects in Administration » Media Objects. If one is not aware of this difference, this can lead to very annoying problems...

Learning Module with media object '0103_rosen.html' has been imported in ILIAS 5.4 installation and media object has been deactivated by masking the file as .sec file.

Administrator has checked before import if html is an allowed file type and found it in the white list. So he assumed the media object should work but felt in a trap because he didn't knew about an extra setting for media objects.

2 Conceptual Summary

ILIAS should offer one place for defining which type of files is welcome on the platform and which not. The media object component does only support a subset of file types that can be handled by the file service. So how about giving the file service the responsibility as gatekeeper and let the media object component just check what file types are allowed?

3 User Interface Modifications

3.1 List of Affected Views

{Please list all views (screens) of ILIAS that should be modified, newly introduced or removed.}

3.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.}

3.3 New User Interface Concepts

{If the proposal introduces any completely new user interface elements, you might consult UI Kitchen Sink in order to find the necessary information to propose new UI-Concepts. Note that any maintainer might gladly assist you with this.}

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 Information

{ 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 Implications

{ 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.

9 Discussion

Schmid, Fabian [fschmid] 2021-03-15: I fully support this request. I also think that there should be a single place where the file extensions are restricted, except perhaps that individual components can restrict them additionally. in this case, however, the final list of supported file extensions should always be displayed.

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: 15. Mar 2021, 07:58, Schmid, Fabian [fschmid]