An entry could be added to $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS'] and handled inside definition source components.

Example:

$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['NotiZ']['DefinitionSource'][\CuyZ\Notiz\Domain\Definition\Builder\Component\Source\TypoScriptDefinitionSource::class][] = 'EXT:my_extension/Configuration/TypoScript/Notification/MyDefinition.typoscript';

This would facilitate adding new sources files without using the whole API which is more powerful but more complicated to use.

If an event has a marker that contains an array, the values are not accessible.

Hello @romm,

When access for Manager module is granted to Editors after createning notification this error pop ups (see screen below). Since all notifications are created with pid=0, it's not possible to grant access to editors with DB Mounts defined.

See:

If slack channels are defined via TypoScript the fields for target and webhook_url shouldn't be required fields from my point of view.

A new system that allows the mail body to be divided into several slots should be introduced.

The slots should be defined within the mail layout file: a Fluid section should be used, allowing loops, conditions and other Fluid features to be used.

The slots will then be listed in the FlexForm of the mail body, and may be divided into tabs.

To make it work, all the markers provided by the event should be assigned to the view, so the template can have access to them (allowing advanced control like loops, conditions, etc…).

Markers that are currently using the syntax #FOO# should now look like {foo}.

Additionally, they should support dotted path syntax to fetch nested values, for instance {foo.bar}.

Some basic RTE configuration should be added to the mail body field.

CKEditor, as well as HtmlArea, should be supported, and allow only some basic features (bold, italic, underlined, etc…).

Currently, only markers are assigned to the template view of an email:

All existing properties should be fetched for the notification and passed to the view.

Maybe create an interface AssignedToTemplate or something like that which can be implemented by properties?

See:

Currently, the only way of viewing an exception thrown by the system is located in the backend module. However, an exception can be thrown only in the frontend context, meaning the exception would not be thrown in the backend contact. Therefore it can't be viewed and analyzed, making the debugging way harder.

Some kind of logging should be introduced in the RuntimeService which is in charge of gathering the exceptions catch during the runtime.

@romm I just wanted to know if there are any plans for further development of this extension. No code update since 3 years and no compatibility for TYPO3 CMS v10 or higher.

If this extension is no longer maintained a short note in the README would be nice.

Every field but title and event should be hidden while no event is selected (should happen only upon the creation of a new notification record).

With the incoming support of TYPO3 10 LTS, widget(s) might be added to the new dashboard feature that will be delivered with the new LTS.

https://www.richardhaeser.com/typo3-blog/an-update-about-the-dashboard-for-typo3

I think this extension would benefit from a settings which allows to set the TYPO3 Context (Development/,Live/,...) in which notifications should be send.

Currently, the fields exist in the TCA, but are never used.

I created a custom event in a Symfony Console Command. If the command is executed via the scheduler in the backend everything works as expected. If the relevant scheduler task is executed via CLI/Cronjob no notification is sent.

The problem seems to be a missing Signal/Slot configuration which is automatically generated under "normal" circumstances. In \TYPO3\CMS\Extbase\SignalSlot\Dispatcher::dispatch() no slot is found in line 131.

Test in TYPO3 9 LTS with EXT:notiz 2.1.1

When you navigate to an event, you can see a list of notifications listening to this event.

This notifications list is currently not filtered by event.

Would be great if TCA migration messages will be fixed

Hello,

We have TYPO3 v8 (8.7.31) and Notiz v2.1.2.
When I add new notification and set email as channel, emails are not sent.
TYPO3 email configuration is working correctly via SMTP.

After some debugging I found out that emails are sent correctly if I comment out line 136 in file notiz/Classes/Domain/Channel/Email/TYPO3/EmailChannel.php:
$this->dispatchEmailSignal($mailMessage);

This call only do simple dispatch, but somehow mess up message sending.

I was not able to find out why this happens...

Best regards,
Sinisa Mitrovic

This will allow to send notifications to any Slack instance.

Several details should be customizable via the backend:

• the message (with markers)
• the sender's name
• the sender's avatar
• the slack team and target: #channel or @user

Currently, the namespace used to register definition is config.tx_notiz.

This doesn't really make sense because TypoScript (by default) is not used as a configuration language here, features like stdWrap and others are not used.

The current namespace was added to respect a convention that is not even useful in this context.

A new namespace should be used. What about notiz?

I get a problem each time an email notification is saved with the "body" field. There are new paragraphs between the existing paragraphs over and over each time I save the content. See capture attached. Thanks.

Hi
I'm trying to get notified when a scheduler task is hanging up for too much time. The task didn't fail or success so i cannot get notified out-of-the-box with NotiZ.
It could be nice to have a way to check if a task is in late after a certain amount of time.
What do you think?

Another question: do you have any plan for version 10?

Thank you very much.

A link to the extension configuration (usually found in the extension manager) could be added somewhere in the administration module.

In event is not possible to set multiple email addreses for {email} property.
This will send email only to first email address, other are trimmed out.

    /**
     * @label Recipient emails
     * @email
     *
     * @var string
     */
    protected $emails = '[email protected], [email protected], [email protected]';

Definition path: notiz.eventGroups.foo.events.bar.configuration.flexForm.file

Hi @romm

Wouldn't be better to set notiz.notifications.entityEmail.settings.defaultSender as default value to $GLOBALS['TYPO3_CONF_VARS']['MAIL']['defaultMailFromAddress']

The default configuration for emails is html.
A nice addition would be a checkbox to mark the email as "text/plain".

The definition object shouldn't allow modifications once it has been built.

I'm getting this error:

Fatal error: Declaration of CuyZ\Notiz\ViewHelpers\Slot\RenderViewHelper::compile($argumentsName, $closureName, &$initializationPhpCode, TYPO3\CMS\Fluid\Core\Parser\SyntaxTree\AbstractNode $node, TYPO3\CMS\Fluid\Core\Compiler\TemplateCompiler $compiler) must be compatible with TYPO3Fluid\Fluid\Core\ViewHelper\ViewHelperInterface::compile($argumentsName, $closureName, &$initializationPhpCode, TYPO3Fluid\Fluid\Core\Parser\SyntaxTree\ViewHelperNode $node, TYPO3Fluid\Fluid\Core\Compiler\TemplateCompiler $compiler) in /var/www/html/web/typo3conf/ext/notiz/Classes/ViewHelpers/Slot/RenderViewHelper.php on line 0

typo3: 8.7.19

In some mails it may be needed to set a fix PDF as attachement. It would be nice to set it like any other sys_file_reference.
In addition it should be able to mark attachements like the '@email' marker (e.g. @attachement as single "File" property)