Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix email notification not sending #384

Merged
merged 1 commit into from
Oct 26, 2019
Merged

Fix email notification not sending #384

merged 1 commit into from
Oct 26, 2019

Conversation

johnheusinger
Copy link
Member

Description

Changed 'notify' to 'notification' in the request body to align with API documentation

Motivation and Context

Closes issue #382

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist

  • My code follows the code style of this project.
  • I have added Pester Tests that describe what my changes should do.
  • I have updated the documentation accordingly.

@johnheusinger johnheusinger requested review from a team as code owners October 23, 2019 21:01
@skuzzles
Copy link

Commenting from my phone here. But you must also change the notify param to String and value "true"

FROM
[Boolean]
$Notify = $true

TO
[String]
$Notify = "true"

@johnheusinger
Copy link
Member Author

@skuzzles, can you explain why it should be a string?

I agree that there might be a better way to do this, particularly with @replicaJunction's idea to identify default behavior and use a switch parameter to change it. But, adjusting the data type would be a functionality change, potentially breaking existing automation. The fix I submitted has been tested to resolve the issue and keeps this in the 'bug fix' category.

@lipkau
Copy link
Member

lipkau commented Oct 24, 2019

@skuzzles
it should definitely not be a string, as the user can't type anything he wants in there.
if a string true is needed, the following would be a way to implement it:

if ($Notify) {"true"} else {"false"}

but not to allow the user to type any string


@johnheusinger
Have you tested this manually?
The tests in the module can't test if an email was sent or not

@johnheusinger
Copy link
Member Author

@lipkau Yup, tested it manually

@skuzzles
Copy link

https://docs.atlassian.com/software/jira/docs/api/REST/8.5.0/?_ga=2.157337087.49623261.1571848884-351338371.1565634928#api/2/user-createUser

Atlassian documentation states the notification property is a string. "true" is default and "false" is accepted alternative. The reason @johnheusinger suggestion works is because it is defaulting to true, since the property is now successfully changed from notify to notification. If you've tested it manually, try testing it with -Notify false to see if you do not receive a notification.

@lipkau
Copy link
Member

lipkau commented Oct 24, 2019

@johnheusinger : can you please test it with -Notify:$false?

@johnheusinger
Copy link
Member Author

@lipkau I tested the following cases:

Without -Notify param - Sends email
-Notify:$true - Sends email
-Notify:$false - Does not send email

@lipkau lipkau changed the base branch from master to develop October 26, 2019 08:09
@lipkau lipkau changed the base branch from develop to master October 26, 2019 08:09
@lipkau lipkau merged commit 301d909 into AtlassianPS:master Oct 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants