mehrwert / typo3-fal-quota Goto Github PK

Provide version w/ basic compatibility

Blocked by #31

When using the addAdditionalRecipients slot to extend the recipient list, only a single recipient receives the warning email.

Expected behaviour

The default quota_warning_recipients as well as all members of the added quota_warning_recipients group receive warning emails.

Actual behaviour

Instead of and the compiled list from quota_warning_recipients and quota_warning_recipients, only the very last recipient of quota_warning_recipients receives an email.

It seems the foreach in NotifyCommand::sendNotificationWithSymfonyMail() is not working as intended, see https://github.com/mehrwert/TYPO3-FAL-Quota/blob/master/Classes/Command/NotifyCommand.php#L200

I propose the followng change:

Before

foreach ($recipients as $recipient) {
    $mailMessage->to($recipient);
}

After

$mailMessage->setTo($recipients);

PHP 7.4
TYPO3 10.4.20

Refactor HTML (for smaller viewports), CSS and JavaScript.

I like the the extensions but I have a few suggestions for improvements:

1. make the table in the backend sortable (and maybe a filter would be nice, too)
2. if a "normal" editor is given access to the "FAL Quota" module, remove the action button, as the editor cannot and should not use the button. (In case it is not obvious why I would give a normal editor access to the module, I want them to now how much quota the have left without asking me :-) )
3. I am not sure why in the "FAL Quota" module (on the left) all filemounts are listed. I would probably get rid of it.

Thanks for the work already done :-)

@see https://github.com/ddev/ddev/releases/tag/v1.22.0

Testing with 1000 MB resulted in upload error message even in an empty storage.

composer install oder composer update commands lead to the following warning:

The TYPO3 extension package "mehrwert/fal-quota", does not define an extension key in its composer.json. Please report this to the author of this package. Specifying the extension key will be mandatory in future versions of TYPO3 (see: https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ExtensionArchitecture/ComposerJson/Index.html#extra)

As per documentation, providing the extra property in the extensions composer.json will solve this issue (which is also required for TYPO3 10 compatibility).

{
   "extra": {
      "typo3/cms": {
         "extension-key": "fal_quota"
      }
   }
}

The BE module currently is limited to systemMaintainer by access configuration. This should be changed to user,group.

Apply size calculations when storage w/ quota applied is copied.

Refactor all unit conversion (Byte → Kilobyte → Megabyte ...) and mathematical operations to use identical patterns.

https://github.com/mehrwert/TYPO3-FAL-Quota/blob/master/Classes/Utility/QuotaUtility.php#L184

vs.

https://github.com/mehrwert/TYPO3-FAL-Quota/blob/master/Classes/Slot/AbstractResourceStorageSlot.php#L97

The inline CSS added to the extensions backend module icon uses generic CSS classes which may be used in other icons (e.g. in2code-de/in2studyfinder) causing them to be unintentionally re-colored.

This is the original Icon:
https://github.com/in2code-de/in2studyfinder/blob/develop/Resources/Public/Icons/Extension.svg

This is the icon with fal_quota installed:

Provide version w/ basic compatibility

• Signal/Slot → https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/Hooks/EventDispatcher/Index.html
• Commands.php → Services.yaml
• Module registration w/ full namespace/class
• PHP Update limit < 8.0.0
• Backend templates

Given the following configuration (see screenshots - threshold of 75 clearly exceeded), the fal_quota:quota:update command should send a notification email to the corresponding recipient – but doesn't.

Storage:

FAL-Quota module:

The condition used in QuotaCommand::checkThreshold() seems to be the issue here.

This is the debug output of $quotaConfiguration (values from above mentioned storage):

current_usage => 4105236127 (integer)
soft_quota => 5242880000 (integer)
hard_limit => 5347737600 (integer)
quota_warning_threshold => 75 (integer)
quota_warning_recipients => "<redacted>"

This is the condition used in QuotaCommand::checkThreshold():

if ($quotaConfiguration['soft_quota'] > 0 &&
    $quotaConfiguration['quota_warning_threshold'] > 0 &&
    $quotaConfiguration['current_usage'] > $quotaConfiguration['soft_quota']) {
    $currentThreshold = (int)($quotaConfiguration['current_usage'] / $quotaConfiguration['soft_quota'] * 100);
    if ($currentThreshold >= $quotaConfiguration['quota_warning_threshold'] && !empty($quotaConfiguration['quota_warning_recipients'])) {
        $this->sendNotification($storage, $quotaConfiguration, $currentThreshold);
    }
}

As one can see $quotaConfiguration['current_usage'] > $quotaConfiguration['soft_quota'] evaluates to false (see given $quotaConfiguration) which causes the threshold check to be never reached.

This is a logical flaw, because the threshold is practically obsolete as long as the "current_usage has to be larger than soft_quota" condition is in place.

The email subject and body are currently hardcoded in QuotaCommand.php and cannot be changed easily. I therefore suggest moving the text to a localization file instead. This way labels could be changed or even overriden completely (see Custom Translations).

We might want to think about including a drud/ddev dev environment instead of having everyone set up their own TYPO3 instance in whatever way they choose, in order to contribute to the codebase.

Not only would this make the setup itself easier (thus lowering the barrier for potential contributions), it would also provide us with a consistent environment for feature improvements (e.g. tests).

Examples:

• Bootstrap Package
• Crawler

Currently the update of the storage usage statistics (current_usage) is performed at the same time as the email notifications are sent (see QuotaCommand).

There are however valid use cases in which these usage statistics shall be updated without instantly sending notifications (i.e. usage is updated daily for internal reference, but mails to inform editors should be sent weekly instead).

We should accomodate for this and implement these functions independently.

exception on typo3 10.4:
"Return value of Mehrwert\FalQuota\Hooks\DatamapDataHandlerHook::getLanguageService() must be an instance of TYPO3\CMS\Lang\LanguageService, instance of TYPO3\CMS\Core\Localization\LanguageService returned"

Solution:
Change line 15 of Classes/Hooks/DatamapDataHandlerHook.php
to: use TYPO3\CMS\Core\Localization\LanguageService;

I'm open to the idea of using PSR-14 events instead – due to signals and slots being deprecated since TYPO3 10 – but in order to retain backwards compatibility for version 9, I would rather choose the signal/slot route for now.