more expressive certificate names

1 Initial Problem

Currently, all files with certificates for courses are generated with a common certificate name "Certificate.pdf" or an according name in the users language of choice. This uniform naming convention poses a challenge as it lacks specificity and fails to distinguish between certificates obtained from different courses. As a result, tracking and managing certificates becomes cumbersome, leading to potential confusion and inefficiencies in certificate management workflows.

For example: If a users downloads multiple certificates from a system, files will be stored with names like "certificate.pdf", "certificate (1).pdf", "certificate (2).pdf", etc. in her download folder. If these files need to be archieved in any reasonable fashion, files need to be opened individually and information from the certificate (if available...) need to be transfered to the filename manually.

The same problem exists for certificates in other ILIAS objects.

2 Conceptual Summary

The problem shall be solved by giving a more helpful filename to the certificate files. It shall be created according to this pattern:

{object type}_{user lastname}_{user firstname}_{object name}_{creation_date}.pdf

For a certificate that was created at a course for Klees, Richard [rklees] on christmas eve this would look like:

crs_Klees_Richard_My Christmas Course_2024-12-24.pdf

3 User Interface Modifications

3.1 List of Affected Views

• no views are affected

4 4 Technical Information

N.a.

5 Privacy

No new personal data will be stored when this feature is introduced. However, introducing this feature means that real names of users (and the other info) will appear in HTTP communication, as the filenames are in fact URLs. This means that this information might be logged at certain systems, such as http-proxies, where one might be able to connect them to other personal information, such as IPs. Since TLS is mostly standard in HTTP contexts nowadays, this risk should be easy to mitigate for properly configured installations.

6 Security

The implementation of a more expressive certificate naming system is unlikely to introduce significant security vulnerabilities. This feature primarily involves modifications to the certificate generation and management processes, focusing on improving naming conventions and user experience.  

7 Contact

• Author of the Request:  Klees, Richard [rklees]
• Maintainer: Jansen, Michael [mjansen]
• Implementation of the feature is done by: Minervis

8 Funding

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

• …

9 Discussion

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}

Privacy

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

Approval

Approved at {date} by {user}.