RE: Email triggering to test user when Calendar Event is created

thumbnail
Shiva Lingam K, modified 5 Years ago. New Member Posts: 18 Join Date: 5/9/18 Recent Posts
Hello everyone,                             I need a solution to my problem i.e.,   When i am adding an calendar event, an email is getting triggered to test@liferay.com in Liferay 7.2 . So i dont need the email triggered to test@liferay.com . So, can anyone help me to solve this problem. 
thumbnail
Olaf Kock, modified 5 Years ago. Liferay Legend Posts: 6441 Join Date: 9/23/08 Recent Posts
Shiva Lingam K:

Hello everyone,                             I need a solution to my problem i.e.,   When i am adding an calendar event, an email is getting triggered to test@liferay.com in Liferay 7.2 . So i dont need the email triggered to test@liferay.com . So, can anyone help me to solve this problem. 
Keywords to look up in the documentation are
  • ServiceWrapper
  • MessageQueue (for asynchronous handling)
to a lesser degree ModelListener - it might seem like an option, but I'd rather go with ServiceWrapper. In all cases, you most likely want to implement sending the mail asynchronously from your transaction.
thumbnail
Dominik Marks, modified 5 Years ago. Regular Member Posts: 149 Join Date: 8/29/12 Recent Posts
I would suggest to go for a ServiceWrapper. In a project for Liferay 7.0 I used the following code (should be adapted easily for Liferay 7.2).

@Component(
    immediate = true,
    service = ServiceWrapper.class
)
public class CalendarBookingLocalServiceOverride extends CalendarBookingLocalServiceWrapper {
    public CalendarBookingLocalServiceOverride() {
        super(null);
    }
    @Override
    public CalendarBooking addCalendarBooking(
        long userId, long calendarId, long[] childCalendarIds,
&nbsp; &nbsp; &nbsp; &nbsp; long parentCalendarBookingId, Map<locale, string> titleMap,
&nbsp; &nbsp; &nbsp; &nbsp; Map<locale, string> descriptionMap, String location, long startTime,
&nbsp; &nbsp; &nbsp; &nbsp; long endTime, boolean allDay, String recurrence, long firstReminder,
&nbsp; &nbsp; &nbsp; &nbsp; String firstReminderType, long secondReminder,
&nbsp; &nbsp; &nbsp; &nbsp; String secondReminderType, ServiceContext serviceContext) throws PortalException {</locale,></locale,>
&nbsp; &nbsp; &nbsp; &nbsp; serviceContext.setAttribute("sendNotification", false);
&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;
&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;return super.addCalendarBooking(userId, calendarId, childCalendarIds, parentCalendarBookingId, titleMap, descriptionMap, location, startTime, endTime, allDay, recurrence, firstReminder, firstReminderType, secondReminder, secondReminderType, serviceContext);
&nbsp;&nbsp; &nbsp;}
&nbsp;&nbsp; &nbsp;
}
thumbnail
Shiva Lingam K, modified 5 Years ago. New Member Posts: 18 Join Date: 5/9/18 Recent Posts
<p>HI Dominik Marks,</p>

<p>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Thanks for your answer, but if we make&nbsp; this as&nbsp; false (<strong>serviceContext.setAttribute(&quot;sendNotification&quot;, false</strong>);&nbsp; ) it will disable the notifications to all users who are invited. But my requirement is not to allow email&nbsp; only to <strong>test@liferay&nbsp;.com</strong>. Can anyone suggest how it will be done ?</p>
thumbnail
Olaf Kock, modified 5 Years ago. Liferay Legend Posts: 6441 Join Date: 9/23/08 Recent Posts
You could just delete that user account. You shouldn't have it anyway - create your own administrator user, not one that any brute force attack would try to check for first. It's shocking how many installations use this ancient default - and probably quite some with a nonsecure password.
Figure out, why it's sent to that user - e.g. because it's the owner of the site where the calendar is positioned - that mail you might want to send (to a proper person).
I'm not sure, but also: Isn't test@liferay.com blacklisted, so you won't send out the email anyway? Or was this implemented later and comes in 7.3?
But in general: Don't create user accounts with mails that you don't control.