I have set up an Email notification in SonarQube for project builds
Everything is working fine but I need to change the following part
See it in SonarQube: http://<>domain-name:9000/project/issues?id=attendance%3AAttendance%3Amaster&createdAt=2018-10-23T10%3A17%3A44%2B0000
to
See it in SonarQube: http://<>domain-name:9000/project/issues?id=attendance%3AAttendance%3Amaster only
Can I modify that ?
No, you cannot modify the URLs embedded in email notification messages. And in this particular example, the createdAt parameter is intentionally present to direct you to a page with filtered results so that you see only relevant content. In other words, this is explicitly by design, and it's not customizable.
Related
I would like to pass an additional parameter like keepMeInformed on Sentry Report feedback. Their embed report feedback form supports only:
- comments
- email
- name
I can create my own Report feedback dialog with Rest API usage on submit. But i can't find any way to bind this keepMeInformed as tag or extra value to existing event.
Without going into details as to which SDK you're using I can't help you with an exact answer, but if your SDK has a beforeSend callback you could use that to both 1) delay the event going out until the user has decided on whether they would want to get informed 2) set a tag value based on that.
I've set up a gmail account to use when sending email notifications from my TeamCity installation. The emails are being sent correctly, but I want to specify the From: header using their .ftl files. According to this page (under Supported Output Values), I can specify email headers. I've copied their <global#... block directly into a number of their template files, namely common.ftl, build_successful.ftl and it never works.
The block I added looks like this:
<#global headers>
From: Some Test <myteamcitytestnotreal#gmail.com>
</#global>
It doesn't do anything. Neither does their sample headers. Any help is appreciated.
You can specify the From: address via the UI under Administration > Email Notifier -> Send email messages from:.
This updates the value stored in the <TeamCity data directory>/config/_notifications/email/email-config.xml file.
I suspect overriding the From: address at the ftl template level is not a supported approach given that the above is the documented method; it might make for a good feature request in TC 9.0.
I have a simple plugin for a custom entity that is set to trigger on Update of my custom entity. It is registered in the Post Operation stage. I have noticed some strange behaviour when I make changes to the Owner field of the record in addition to other standard fields (e.g. text boxes, dates etc).
The plugin fires the first time and the only attributes that come across in the image are all the regular fields. The owner field does not come across.
The plugin then fires again, but the Depth property of the context is still only one (i.e. the plugin is not getting triggered by changes made in the plugin code). In this run of the plugin, the attribute that come across is only the Owner field.
My theory is that because the owner fields are 'special', the CRM is doing two different requests - one to change the regular fields, and then another request for changing the owner via an AssignRequest. However, I cannot find any 'official' documentation for this behaviour.
Can someone explain why this is happening?
I am running Dynamcs CRM 2013 UR2
The Update event fires during the Assign event. So if an assignment takes place your plug-in will execute. The same is true for SetState - if you activate/deactivate a record an Update event takes place. These items are not documented in the SDK.
A good practice is to use Attribute Filtering on your Update plugin so it only fires for the fields it is concerned about - this will, assuming it is isn't looking at the owner related fields, avoid it firing twice. If you have logic specific to record ownership you would put it in a plugin that is registered on the Assign event.
I was not able to find official documentation about this, but I think Assign message is what you are looking for (if the entity is user-owned. See http://msdn.microsoft.com/en-us/library/gg328576.aspx. I would strongly recommend that you specify Filtering Attributes if you are registering a plugin on Update message. You could also debug your plugin and inspect MessageName property of plugin context and see what message gets triggered. I hope this helps.
I'm relatively new to the CRM SDK, and I'm trying to write a plugin to alter From/CC fields of an email on Create. It seems when this is registered in Pre-operation, the ActivityParty collection cannot be modified(though things like subject and body can be modified), and this post recommended setting the pipeline stage to Pre-validation.
When I do this the plugin no longer gets triggered. I know this because when remote debugging, breakpoints are only hit when pre-operation is selected. Also, when not remote debugging, none of the other changes get implemented in the plugin code.
Does anyone know what might be preventing this plugin from executing?
When you register plugin on Create message fields To, CC, BCC will be empty. Try register on DeliverIncoming / DeliverPromote messages
Is there any way to send an email in Hudson which has the list of recent changes in that build?
For example
Trigger a build and if you go recent changes there we have some recent changes. Once it is success, the email should have the list of the changes that happened in that particular build. After this, say the next build fails (build fail email will be triggered), but it records the changes and these change lists also should be included in next successful build.
You'll first need to install the Email-ext plugin for Hudson.
Inside the project configuration, under Post-build Actions click the Email Notification and Editable Email Notification checkboxes. Instead of having the Content be $PROJECT_DEFAULT_CONTENT you'll want to use a different token. Those are described when you click the help icon (?) for Content Token Reference.
Specifically to your example, add (or edit if it exists) the trigger for Success. Change the Content of the success email to use the token ${CHANGES_SINCE_LAST_SUCCESS, reverse, format, showPaths, changesFormat, pathFormat}. The different options are explained in the reference. If you just want the defaults, simply use ${CHANGES_SINCE_LAST_SUCCESS}