Support

Hello Herve! We're doing good, thank you :)

The TL;DR version is that what you experienced is the normal way Joomla works and there's no reason to be worried. The rest of the reply is a more technical discussion of how uploads work in ATS and Media Manager, their different context and explain their different behaviour.

ATS is using Joomla's API to handle uploads, namely the JHelperMedia::canUpload() method. This is a "black box" as far as our code is concerned. It will return false if Joomla rejects the upload based on the settings in Media Manager.

So let's shed some light into the black box, shall we? ;)

First, Joomla checks if the file's extension is within the "Legal Extensions (File Types)" list. In both cases the file is. There is, however, a second check. If you have enabled the "Restrict Uploads" option in Media Manager's Options page the JHelperMedia will check if the extension of the file belongs in the "Legal Image Extensions (File Types)" list. Before you made the change the uppercase JPG extension was not in that list, therefore the file failed to upload.

As for why the Media Manager works differently: it converts the file name to lowercase before calling the JHelperMedia::canUpload() method. In this case the lowercase .jpg extension is in both "Legal Extensions (File Types)" and "Legal Image Extensions (File Types)" lists. Therefore the file can be uploaded and that explains why the extension is lowercase.

The problem is that this essentially renames the file without asking you. This is perfectly acceptable for a Media Manager but not for a ticket system, where the filename may carry significance depending on the use case. Moreover, ATS does not store the file using its nominal filename and extension. We store it with a random alphanumeric key as its filename and store the filename and extension in the database. We only use the filename and extension when you are trying to download the file. This makes the security issues Joomla is trying to mitigate in the Media Manager completely moot (inapplicable to our case) which is why we don't try to make the filename safe, convert it to punycode and lowercase it like Joomla's Media Manager does. You can say that ATS is more lax with filenames because its indirect access to the file (the download goes through Joomla's index.php instead of the server directly) affords us this luxury.

So, what you observed is the expected Joomla behaviour, therefore there is no bug in either Joomla or ATS. What you did was the correct solution to the problem you experienced. No need to file any bug reports :)

Our policy is to not provide support or documentation for core Joomla features because then we have to track two feature sets: ours and Joomla's. We trust that our clients know how to build Joomla sites and troubleshoot core Joomla issues -- as you demonstrated :)

Yes, I know that ATS' documentation still contains references to articles on using Joomla ACLs. When the documentation was first written, in 2011, ACLs were still a new thing for most of our clients migrating from Joomla 1.5. Joomla's documentation was very sparse on information on the topic and there were too few people who actually knew how this feature worked, making it unlikely that someone could find peer help on the forum. In that context we had to point people to documentation on Joomla ACLs, something which will be removed. I just didn't have the time last year to deal with deep documentation refactoring. Between GDPR, launching Admin Tools for WordPress, modernizing our code base in preparation for PHP 7.4 and Joomla! 4 and implementing a new, more efficient to sell subscriptions -- not to mention having a baby -- my time for documentation has been extremely limited. Hopefully this summer I'll be able to focus on documentation :)