Boris Berenberg - Atlas Authority added a comment - 07/May/2020 12:04 PM - edited <3 thanks! Can we update the status of this issue to show that?

Aidan Goldthorpe added a comment - 07/May/2020 5:29 AM feedback1534286591 I'm glad we're on the same page with what the issue is. I agree that sendMail not being set for this field is potentially confusing. To improve this, the behaviour will be changed in 4.10 to be consistent with the other fields on the issue view, i.e. sendMail is true.

Boris Berenberg - Atlas Authority added a comment - 22/Apr/2020 12:13 PM - edited Oh cool thanks for pointing to that doc. Editing other values in the JSD right panel fires an Issue Updated event. This is a consistent behavior across not only JSD, but every other inline field edit that Jira offers, and across every surface on which it fires. This one field being edited behaves in a manner which is not standard to any other field. Also to be clear, I wasn't looking at Jira's native emails, only the events being fired. My guess is that the support agent may have been inspecting emails? But I should point out that a field being edited is still something a user is trained to expect an email for. By having this one field not send an email, a JSD Agent could mis an important update. Edit: Hold on I think there was a mistake in our test. Going to re-test, may be totally wrong. Edit #2: agoldthorpe I went back on this with our devs and it looked like I misunderstood what they were saying. The issueUpdated event is being fired properly. However this is the only field edit where sendMail is set to false. I continue to point out that this is not consistent with the behavior of any directly editable field, on any surface, in Jira that I can find.

Aidan Goldthorpe added a comment - 22/Apr/2020 1:54 AM First of all, this event does exist: https://docs.atlassian.com/software/jira/docs/api/8.5.4/com/atlassian/jira/event/issue/IssueChangedEvent.html The IssueChangedEvent is distinct from the IssueEvent, but both events are fired in a number of circumstances, including when fields on an issue are modified. The below screenshot is the result of a test plugin I made to listen to the IssueEvent, and the IssueChangedEvent and simply log the event. I modified the customer request field in the right panel, as can be seen from the change items. This also shows the `sendMail` parameter being set to false, as previously mentioned. I've attached the code of the event listener used (it does have some unrelated code, as I was previously testing workflow related behaviour with it). package com.atlassian.test.impl; import com.atlassian.event.api.EventListener; import com.atlassian.event.api.EventPublisher; import com.atlassian.jira.bc.issue.IssueService; import com.atlassian.jira.bc.workflow.WorkflowService; import com.atlassian.jira.event.issue.IssueChangedEvent; import com.atlassian.jira.event.issue.IssueEvent; import com.atlassian.jira.event.type.EventType; import com.atlassian.jira.issue.Issue; import com.atlassian.jira.security.JiraAuthenticationContext; import com.atlassian.jira.user.ApplicationUser; import com.atlassian.jira.workflow.JiraWorkflow; import com.atlassian.jira.workflow.TransitionOptions; import com.atlassian.jira.workflow.WorkflowManager; import com.atlassian.plugin.spring.scanner.annotation.imports.JiraImport; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.beans.factory.DisposableBean; import org.springframework.beans.factory.InitializingBean; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Component; @Component public class TestEventListener implements InitializingBean, DisposableBean { private static final Logger log = LoggerFactory.getLogger(TestEventListener.class); @JiraImport private final EventPublisher eventPublisher; @JiraImport private final IssueService issueService; @JiraImport private final JiraAuthenticationContext jiraAuthenticationContext; @JiraImport private final WorkflowService workflowService; @JiraImport private final WorkflowManager workflowManager; @Autowired public TestEventListener(EventPublisher eventPublisher, IssueService issueService, WorkflowService workflowService, WorkflowManager workflowManager, JiraAuthenticationContext jiraAuthenticationContext) { this .eventPublisher = eventPublisher; this .issueService = issueService; this .workflowService = workflowService; this .workflowManager = workflowManager; this .jiraAuthenticationContext = jiraAuthenticationContext; } /** * Called when the plugin has been enabled. * @ throws Exception */ @Override public void afterPropertiesSet() throws Exception { log.info( "Enabling plugin" ); eventPublisher.register( this ); } /** * Called when the plugin is being disabled or removed. * @ throws Exception */ @Override public void destroy() throws Exception { log.info( "Disabling plugin" ); eventPublisher.unregister( this ); } @EventListener public void onIssueEvent(IssueEvent issueEvent) { log.error( "Issue Event {}" , issueEvent); Long eventTypeId = issueEvent.getEventTypeId(); Issue issue = issueEvent.getIssue(); if (eventTypeId.equals(EventType.ISSUE_GENERICEVENT_ID)) { ApplicationUser user = jiraAuthenticationContext.getLoggedInUser(); JiraWorkflow workflow = workflowManager.getWorkflow(issueEvent.getIssue()); int actionId = workflow.getActionsByName( "Start Progress" ).iterator().next().getId(); IssueService.TransitionValidationResult transition = issueService.validateTransition(user, issue.getId(), actionId, issueService.newIssueInputParameters(), new TransitionOptions.Builder().setAutomaticTransition().build()); if (transition.isValid()) { IssueService.IssueResult result = issueService.transition(user, transition); log.info( "Transition succeeded {}" , result); } else { log.error( "Transition failed due to {} or ." , transition.getErrorCollection()); } } if (eventTypeId.equals(EventType.ISSUE_CREATED_ID)) { log.info( "Issue {} has been created at {}." , issue.getKey(), issue.getCreated()); } else if (eventTypeId.equals(EventType.ISSUE_RESOLVED_ID)) { log.info( "Issue {} has been resolved at {}." , issue.getKey(), issue.getResolutionDate()); } else if (eventTypeId.equals(EventType.ISSUE_CLOSED_ID)) { log.info( "Issue {} has been closed at {}." , issue.getKey(), issue.getUpdated()); } else if (eventTypeId.equals(EventType.ISSUE_UPDATED_ID)) { log.error( "Issue {} has been updated at {}." , issue.getKey(), issue.getUpdated()); } } @EventListener public void onIssueChangedEvent(IssueChangedEvent issueEvent) { log.error( "Issue Changed Event {}" , issueEvent); } } Unfortunately I also can't find much documentation on how inline edit differs from going via the edit issue screen. The best I can point out is that there are front end API hooks specifically for dealing with inline editing, so there is some behaviour specific to this type of editing: https://developer.atlassian.com/server/jira/platform/extending-inline-edit-for-jira-plugins/  

Boris Berenberg - Atlas Authority added a comment - 21/Apr/2020 1:33 PM - edited When installing a testing plugin to listen to the IssueChanged event There is no such event: https://docs.atlassian.com/DAC/javadoc/jira/reference/com/atlassian/jira/event/type/EventType.html The banner not appearing and mail not being sent for inline edited fields is normal behavior, and I believe will occur for every field in the right panel, such as request participants. Your assumption is not right. Editing the Request Participants in the right panel triggers an Issue Updated event as does editing the Organization field. I am not aware of any mention of side panel actions behaving differently (in the context of triggering behaviors) than main panel inline edits or modal screen edits in any doc, nor does this meet any user expectation (even Atlassian support expected this to work), not does this actually align with how anything else in Jira works.    

Aidan Goldthorpe added a comment - 21/Apr/2020 12:32 AM When installing a testing plugin to listen to the IssueChanged event, I can confirm the event is being fired on the back end. There are differences in editing a field via the Edit Issue screen as opposed in inline editing a field, but these are expected. The banner not appearing and mail not being sent for inline edited fields is normal behaviour, and I believe will occur for every field in the right panel, such as request participants.