How to add history item from Redmine plugin - plugins

I am trying to write a plugin for Redmine. The plugin will allow users to create Code Review Requests.
When the user creates / updates / deletes a request I want to add the event to history.
Anyone here familiar with creating a Journal object and attaching it to an issue?
I tried doing (using the console)
is = Issue.find(1234)
jr = Journal.new(:journalized => is)
jr.save
However jr.save returns false.
Please let me know what would be a correct way to do this?
Thanks!

To create issue history line on behalf of user(as a comment):
writing line by line, to show howto. You can combine in 1 line all this code
issue = Issue.find(1234)
user = User.current
journal = issue.init_journal(user, 'My text for history line')
journal.save

Related

TYPO3 WEC_Map Extension <script> Tag not inserted in HTML

I’m using Typo3 (Version 6.2.14) and upgraded WEC_Map to version 3.1.3 because I saw a warning on my map which says that I need to use an API key for Google Maps.
So I’ve generated an API key for "Maps Static API" and inserted it in WEC Map Admin. (I’ve used the same key for Browser API Key and Server API Key. Only difference is that I’ve added the secret for the Browser API Key separated by a comma.)
If I’ve visit my FE User Map in the backend the map is showing.
In the frontend instead I get the following error: "
There doesn't seem to be anything to display. Make sure the map is configured correctly and there are users or markers set".
Inspecting the source code I saw that the script tag to maps.googleapis.com is not generated. It looks like this is causing the issue, but I don't know why it is happening.
I hope that someone using a similar setup can point me into the right direction.
Thank you guys. (It would be nice if someone could add the Tag for WEC_Map)
Ok I resolved this. The problem was that I was using the userGroups setting to filter the map markers by multiple user groups.
plugin.tx_wecmap_pi2 {
height = 500
width = 500
showDirections = 1
prefillAddress = 0
initialMapType = G_HYBRID_MAP
controls.mapControlSize = large
controls.showOverviewMap = 1
controls.showMapType = 1
controls.showScale = 1
userGroups = 2,3,5
pid = 2,3,5 # <-- This uses a AND condition
}
Since this setting is using an AND condition under the hood I received the error "There doesn't seem to be anything to display. Make sure the map is configured correctly and there are users or markers set"
In fact I opened a feature request for this 3 years ago. Unfortunately the feature request never made it into the plugin. But Jan Bartels posted a workaround as reply to the feature request. This workaround got lost while updating the extension.
Also recomment to the extension authors to make it more clear in their documentation that the property userGroups uses a AND condition.

TeamCity REST API get list of pending changes

Is there a REST API endpoint to get a collection of changes that are pending for a build in TeamCity?
We have the build set to manual and it is triggered outside TeamCity and would like to show a bullet point list of commits that'd be in that build.
In the user interface you can see this under the "Pending Changes (X)" tab.
I can't find any examples of doing this and the closest I've found is:
http://<server>/httpAuth/app/rest/changes/buildType:<build type id>
This seems to return the last change though.
Anyone done this before?
I just found a working solution thanks to this question. I'll show it here in case other people are looking for a full solution :
You need to know the buildTypeId of the build on which you want to get the pending changes. In this case lets say buildTypeId=bt85
1
http://<server>/httpAuth/app/rest/buildTypes/id:bt85/builds/
// Get the last build from the XML returned.
// Lets say last build id = 14000
2
http://<server>/httpAuth/app/rest/changes?build=id:14000
// The newest change returned is the one you need.
// Lets say newest change id = 15000
3
http://<server>/httpAuth/app/rest/changes?buildType=id:bt85&sinceChange=15000
// You're now looking at the pending changes list of the buildType bt85
My eventual solution in a work around kind of way is to:
Find the latest change ID from my database of builds outside of TeamCity (I guess you could query the TeamCity API to find the last successful build and pull it from there)
Then call:
http://<server>/httpAuth/app/rest/changes?buildId=id:<build id>&sinceChange=id:<last change id>
Then fetch each individual change from that list.
A bit of a workaround but I couldn't see anyway otherwise to get the list of pending changes.

TYPO3 : no updated newsletter with direct_mail and scheduler

This is my 1st question on this forum... So, please, be indulgent !
I'm using TYPO3 4.7.11 (PHP 5.3.3) with extension direct_mail 3.1.1 for the intranet site of a non-profit firm.
My problem (maybe connected to Bug #51583 : http://forge.typo3.org/issues/51583) is that, after numerous tests and attempts, it seems impossible to have an updated version of a page saved as draft for newsletter in an automatic scheduler driven way : the same newsletter is produced with the same informations that were already there on the day it was first created and saved.
The specific page used for newsletter includes a content element 'Menu/Sitemap' with 'Recently updated pages' as 'Menu type'. It has been saved as 'draft (for recurring sendings)' in Direct Mail.
The scheduler contains these 2 tasks with recurring type :
- Direct Mail: Create Mail from Draft (direct_mail)
- Direct Mail: Mailing Queue (direct_mail)
Note : the manual way is fully functional and the newsletter produced is really updated. Same with option "Testmail - Simple" !
So, my problem seems to be linked to the automatic scheduled mailing ! It looks as if the newsletter draft has turned into a freezed snapshot of a specific moment and that Typo3 is unable to update/recalculate this page when invoked in scheduler mode.
On the web, I saw reported problems that could be related like "When mails get sent via the scheduler the same subject is used for all sendings ( https://review.typo3.org/21313 )" and "Adding hooks when sending direct mails via scheduler ( forge.typo3.org/issues/48994 )", but these issues seem to be fixed with direct_mail 3.1.1 version.
I made these observations and, in my opinion, there is some relevancy :
1.There is no domain proposed in the 'Domain of internal links' drop-down list in 'Set default values for mail content fetching options' in Direct Mailer, and yet I have a single record in sys_domain table with a domain name (with no protocol and no final slash). Is there a reason why this record is not considered good, or isn't it the right table ? (uid=3, pid, tstamp, crdate, cruser_id, hidden, sorting, prepend_params and forced=0, redirectHttpStatusCode=301, domain_name=site.subdomain.domain, redirectTo=)
2.In the Typo 3 Log, I get this systematic error message for user _cli_scheduler#LIVE :
Core: Error handler (BE): PHP Warning: Invalid argument supplied for
foreach() in
...typo3conf/ext/direct_mail/Classes/Scheduler/MailFromDraft.php line
125.
The concerned part of MailFromDraft.php is this function : initializeHookObjects
...
/*
* Initializes hook objects for this class
*
* #return void
*/
function initializeHookObjects() {
foreach ($GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['direct_mail']['mailFromDraft'] as $hookObj) {
$hookObjectInstance = t3lib_div::getUserObj($hookObj);
if (is_object($hookObjectInstance) && ($hookObjectInstance instanceof x_directmail_Scheduler_MailFromDraftHook)) {
$this->hookObjects[] = $hookObjectInstance;
}
}
}
...
I'm not sure of understanding very clearly the origin and the use of the hook Object... (in spite of this interesting article by Robert Lemke : typo3.org/documentation/article/how-to-use-existing-hooks-in-your-own-extension/ )
3.Nothing like the apparently requested GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['direct_mail']['mailFromDraft'] seems to exist in TYPO3_CONF_VARS (Global configuration).
Can anybody give me an advice or a clue about what's going on and why I can't get a weekly updated newsletter with the scheduler ? I feel a bit confused !
Thanks in advance for any suggestion or solution (if a miracle is possible).
Greetings.
P-H SILLIAU
I've read about this issue before, but couldn't remember where.
Googling "direct_mail draft (for recurring sendings)" helped.
Try this bug: http://forge.typo3.org/issues/4421
User Markus says:
Things work fine, when you set a domain-record in your system and
select it in the direct_mail settings!
If you don't have a domain-record and specify it in the direct_mail
setup you're able to send normal newsletters, but if you try the
draft-functionality it won't work because the getUrlBase function in
class.tx_directmail_static.php returns an unsuable URL to the System
so it can't use the fetchHTML($file) and quits - therefore not
replacing the old draft contents created when starting the first time.
I don't really get why this works the first time you set up the draft
though....
So setting up the domain-record is a work-around that works.
I hope it does!
Probably, you will find more related topics.
Else, workarounds would be
re-considering the task. As it's a NPO intranet, maybe requirements are not that required suddenly, if asked again :-)
setting up a custom notification tool that only does that precise job.
To put an end to this problem, after many attempts (and informations gleaned from the internet), here is the solution we finally used in our specific case to make the newsletter work :
1st. We created a record in table sys_domain. This was a recurrent instruction in the manual and the forums, and it was IMHO legitimate.
Important : note that the redirectTo field had to remain empty, due to global malfunction of the site if filled (whatever we put in it like /, /var/www/sitename, ...)
2nd. All images, CSS, JS included in template had to be hardcoded (i.e. http ://site/fileamin/images/xxx.png for instance). If we didn't do that, the result would have been an abort in the production of the newletter : Not Found... Maybe, by digging a bit deeper, should we be able to find a parameter we forgot or neglected in some way to solve this issue...
3rd. In the newsletter template TS setup, we added these 2 parameters :
mod.web_modules.dmail.use_domain=[uid of sys-domain]
config.absRefPrefix = / (in order to get rid of PHP DOCUMENT_ROOT (or TYPO3_DOCUMENT_ROOT ?) otherwise wrongly present in all generated links.)
The result is now a well dynamically-generated newsletter, the date is OK, all links are correct and realUrl-compliant (no ../index.php?id=nnn) .... and you know what ?... We're happy ! :-)
Hope it will help !
Many thanks to everybody who answered (Markus, Urs...) or even thought of a possible solution...
P-H Silliau

Remove custom code workflow programmatically

For a variety of reasons too convoluted to explain here, I find myself in a position where I need to be able to remove custom code workflows, while leaving the solution there.
I essentially have the same code as the plugin registration tool
Namely
service.Delete("plugintype", new Guid(info));
where info is the workflow id [running on a foreach loop but that's beside the point]
However, while the tool removes the workflows without any issues, my code complains about dependencies.
EM:
Additional information: The PluginType(a0b2dcf7-cf2a-111e-7da9-003021880a42) component cannot be deleted because it is referenced by 1 other components. For a list of referenced components, use the RetrieveDependenciesForDeleteRequest.
which I duly did
RetrieveDependenciesForDeleteRequest req = new RetrieveDependenciesForDeleteRequest();
req.ComponentType = 90; //plugintype
req.ObjectId = new Guid(info);
RetrieveDependenciesForDeleteResponse resp = (RetrieveDependenciesForDeleteResponse)OrgService.Execute(req);
This retrieves an optionvalueset, but there is little I can do with it as I cannot remove it from the solution as the solution is managed.
The only difference I can see is the way the OrganizationServiceProxy gets instantiated. The plugin registration tool includes a way to refresh the securitytoken, but as far as I can tell it's not doing much (I've stepped through the code, but it's possible I missed something)
Are you sure that it is an OptionSetValue that is the dependency? It's much easier to use GUI to determine what the dependencies are. Fire up your solution in CRM 2011, click 'plug-in assemblies', select the relevant assembly then go through each custom workflow/plugin item and click 'Show Dependences'.
In my case I had another workflow (created within CRM) that was referencing a custom workflow preventing removal of the assembly.
You won't be able to remove components from a Managed solution... Are you the author of the solution originally?
As an aside, does your workflow fire on change of the OptionSet that is showing as a dependency?

Updating Jira Plugin from Version 3 to Version 4, Replacing SearchParameter

i am pretty new to Jira Development so please be patient
I should upgrade a Plugin that worked with Jira Version 3 to work with Jira Version 4
Most of the thins went pretty well, but now i am kind of stuck
The SearchParameter and the ProjectParameter Class are not available in the new Version and i dont exacly know how to replace them. its really just this few lines of code, where its needed
these Classes are outdated: SearchParameter and ProjectParameter
i looked in the jira doc buts its seems pretty complicated, you would do me a great favor if you could help me
SearchRequest sr = srs.getFilter(ctx, filterId);
...
SearchParameter param = sr.getParam(new ProjectParameter().getName());
...
List columns = columnLayout
.getVisibleColumnLayoutItems(user,
param.getValues(), Collections.EMPTY_LIST);
It would even Help if you could explain what the seccond Line intends
Thanks in advance
I can't help you rewrite the plugin entirely, but I can try help you decipher what those quoted lines of code mean:
SearchRequest sr = srs.getFilter(ctx, filterId);
This line loads a saved SearchRequest with the corresponding filterId.
SearchParameter param = sr.getParam(new ProjectParameter().getName());
This line gets the Project search parameter that was saved in the SearchRequest. As you may know, SearchRequests (or saved filters if you prefer) all you to save a search from JIRA with parameters defined. One possible parameter to define is a ProjectParameter. So if your search is "all issues in project X", then you would have a SearchParameter in your SearchRequest which is a ProjectParameter that knows to search for project X.
List columns = columnLayout
.getVisibleColumnLayoutItems(user,
param.getValues(), Collections.EMPTY_LIST);
This line retrieves the ColumnLayoutItems which are visible to the specified user, for the specified projects of the SearchRequest (by extracting the value from the ProjectParameter of the SearchRequest as retrieved in line 2).
It's a bit unclear what this code is attempting to do without more context, but that's what those lines are doing anyway. You might find the API documentation useful:
http://docs.atlassian.com/jira/3.13/
http://docs.atlassian.com/jira/3.13/com/atlassian/jira/issue/fields/layout/column/ColumnLayout.html