I am working in the hook. When I create a record from subpanel it doesn't trigger the hook. But when I use link existing record the hook is executing. Which hook should we use when create from a subpanel.
$hook_array['after_relationship_add'][] = array(
1,
'after relationship hook',
'custom/modules/Records/Hooks/LinkedRecord.php',
'Records_Hooks_LinkedRecord',
'linkedRecords',
);
Community Link: https://community.sugarcrm.com/message/94290-subpanel-create-dosent-trigger-hook
If you want to trigger your code on creation of record then you will need to use after_save and before_save logic hooks. See this link for further details: http://support.sugarcrm.com/Documentation/Sugar_Developer/Sugar_Developer_Guide_6.5/Module_Framework/Logic_Hooks/Module_Hooks/
Last but not least, create from module or sub-panel trigger same hooks (after and before) so no difference in creation from sub-panel and module.
Hopefully provided documentation is clear enough.
Related
Occasionally in our codebase we need to use an //eslint-disable to bypass a styleguide rule on a line. I would like to somehow automatically add a comment on each new instance of that in PRs, requiring the developer to explain why they bypassed the styleguide.
I've found this question referencing how to create a comment programmatically, but what I'm not sure how to do is identify the new code and parse it for a certain piece of text, then add comments on those particular lines where the text was found.
This is one of the approaches to ingest scripts & achieve what you want, wherein Expected outcome is:
On every pull request, a pre build validation pipeline kicks off & adds comments on the PR.
Create a script (powershell/python/bash) with following logic:
Find file names in the given branch which contains //eslint-disable
In the files above (1.), get the location/line number of //eslint-disable
Foreach file.LineNumber (wrote like that just for representation): add comment on file.LineNumber using Pull Request Threads API. See line parameter
Create a pipeline containing above script & add that pipeline as build validation or if you have an existing build validation process, add these scripts as tasks in that pipeline.
Hope this helps :)
I have been researching about this term for so many hours, but I found anything useful yet.
Hope you can help us building this redmine plugin, or provide us some research links to help us find the correct key.
What we want to build
The thing is we want to update one custom field in redmine (let's name it 'Target_CF') whenever another one is created or updated.
We are looking for incrementing possible values of Target_CF, so we can have all custom field's names available to select.
Of course, we want to achieve this without directly editing Redmine's Core, so we thought developing a plugin would be the best approach.
Our plugin also creates and configures a new custom field (the one mentioned above), but I will let this out of the question, because I think it is not relevant for this.
Where we are right now
We have identified some hooks that could be useful for us, as the following:
:controller_custom_fields_new_after_save
:controller_custom_fields_edit_after_save
We have the following directories/files structure so far:
plugins/
custom_plugin/
init.rb
lib/
hooks.rb
The code we have written
init.rb
require_dependency 'hooks'
Redmine::Plugin.register :custom_plugin do
name 'custom_plugin'
author 'author name'
description 'description text'
version '1.0.0'
end
hooks.rb
class Hooks < Redmine::Hook::ViewListener
def controller_custom_fields_edit_after_save(context={ })
#target_custom_field_name = "Target_CF"
CustomField.find_by_name(#target_custom_field_name).possible_values.push(context[:custom_field].name)
end
end
The result of this code is none. I mean, no erros, no updates, nothing at all. There is no change in our possible values after editing/creating another custom field. We are sure there is something we don't know, some concept or workflow, and due to this we are doing something so badly.
Please, help us understeand what we are missing.
Previously we have succesfully developed another plugin that overwrites certain views. So we have kind of little skills in views related plugins, but zero experience at all at controllers ones.
We are using a Redmine 3.2.0 stack by Bitnami and a mysql database.
Well, finally we found out how to extend base controller's methods. I will post it here so hopefully this can be useful to anyone who finds the same doubts we had.
After some more researching, we conclude that it is mandatory to extend base controllers, in order to not directly modify core methods.
This is our final directories/files structures:
plugins/
custom_plugin/
init.rb
lib/
custom_plugin/
issue_custom_field_patch.rb
We previously stated that we could use some hooks to inject our desired functionality, but it seems not to work that way with controllers. On the other hand, we built a patch which will extend target class functionality.
Our final working code
Init.rb
require 'redmine'
ActionDispatch::Callbacks.to_prepare do
require_dependency 'issue_custom_field'
unless IssueCustomField.included_modules.include? CustomPlugin::IssueCustomFieldPatch
IssueCustomField.send(:include, CustomPlugin::IssueCustomFieldPatch)
end
end
Redmine::Plugin.register :custom_plugin do
name 'custom_plugin'
author 'author name'
description 'description text'
version '1.0.0'
end
issue_custom_field_patch.rb
module CustomPlugin
module IssueCustomFieldPatch
def self.included(base) # :nodoc:
base.extend(ClassMethods)
base.send(:include, InstanceMethods)
base.class_eval do
unloadable
after_save :update_possible_values
end
end
end
module ClassMethods
end
module InstanceMethods
def update_possible_values
self.reload
updatedPossibleValues unless self.name == "Target_CF"
end
private
def updatedPossibleValues
#safe_attrs = ['project', 'description', 'due_date', 'category', 'status', 'assigned_to', 'priority', 'fixed_version', 'author', 'lock_version', 'created_on', 'updated_on', 'start_date', 'done_ratio', 'estimated_hours', 'is_private', 'closed_on']
#custom_fields = IssueCustomField.all.select {|cf| !cf[:position].nil?}.collect {|cf| cf.name}
#possible_values = #safe_attrs + #custom_fields
CustomField.find_by_name("Target_CF").update possible_values: #possible_values
end
end
CustomField.send(:include, IssueCustomFieldPatch)
end
Functionality explained
As we stated in the question, we needed to update Target_CF possible values each time the users create/modify/removes a custom field from Redmine.
We extended IssueCustomField's class's instance methods, triggering our new function 'updatedPossibleValues' after each save. This includes creating new custom fields, and of course, updating existing ones and removing them. Because we reload our list of possible values each time, we had to control if its position were nil. If it is, this means that custom field has been removed.
Because of the ultimate action of this patch, which is the updating of another custom field, this also triggered our function, causing an infinite loop. To prevent this, we linked our functionality to every other custom field which name was not 'Target_CF'. A bit rusty fix, but we couldn't find a better approach.
I hope this can be useful to somebody in the future, as they could invest a fraction of time that we spent on this.
Comments, fixes and improvements are very welcome.
Based on: https://www.redmine.org/projects/redmine/wiki/Plugin_Internals which is a bit outdated, but finally could complete the code with help of another resources and forums.
I am trying to trigger a process on the backend when data gets changed.
Here is a working trigger that I am currently using.
xquery version "1.0-ml";
import module namespace trgr="http://marklogic.com/xdmp/triggers"
at "/MarkLogic/triggers.xqy";
if (xdmp:database() eq xdmp:database("nbcu-test-ml-triggers"))
then ()
else fn:error((), 'NOTTRIGGERSDB', xdmp:database()) ,
trgr:create-trigger(
"typeahead_modify",
"Update Typeahead Document",
trgr:trigger-data-event(trgr:directory-scope("/triplestore/", "1"), trgr:document-content("modify"), trgr:post-commit()),
trgr:trigger-module(
xdmp:database("nbcu-test-ml-modules"),
"/ext/",
"sample-trigger.xqy"),
fn:true(),
xdmp:default-permissions(),
fn:true() )
However at the end of the module it is triggering, I would like to call an xdmp:spawn-function in order to do some asynchronous processing.
I am pretty new to Permission management, but I tried adding to the set of permissions a xdmp:privilege, but that didn't work.
Can someone please help to advise how to add xdmp:Spawn execute privilege to this trigger?
Thanks
Edit: I use mlgradle to deploy the /ext/sample-trigger.xqy
The scope of the user running the trigger is the user that caused the insert/update/delete/property-change on the document. The only exception to this rule is the database online event in which you actually define a user.
Therefore, the xdmp:spawn privilege must be attached to a role that is attached (directly or indirectly) to the user described above.
To troubleshoot, you could add xdm:log(xdmp:get-current-user()) to the trigger module to make sure you understand the user being used to invoke the code. Then add the xdmp:spawn privilege to one of the roles of that user.
I'm working on a rather simple script which should handle new values in the spreadsheet and then send emails to specified addresses. And I faced with the problem. My code is listed below:
function onEdit(e) {
//part of the code for checking e.range to process only updated values
sendEmail();
}
function sendEmail() {
// arguments are missed only for demo
GmailApp.sendEmail();
}
While I'm using "simple trigger", my function "sendEmail()" works only if I start it from script editor. I allowed sending emails on behalf of my at first time and then function works fine. But if I'm changing the value in the spreadsheet - function "onEdit(e)" processes new data but function "sendEmail()" does nothing.
I partly solved this problem by using project's triggers from "current project's triggers" menu. In that case, function "sendEmail()" works properly, but I have no access to the information about update.
For my purposes I could use just second way and find new values "manually" every time, but I wish to optimize this work.
So, my questions are:
Is the process I described above proper or I made a mistake
anywhere?
If process proper, is where a way to combine both cases?
Thanks!
You correctly understood that (as the docs say) simple triggers cannot send an email, because they run without authorization. An installable trigger, created via Resources menu, can: it has the same rights as the user who created the trigger. If it is set to fire on edit, it will get the same type of event object as a simple trigger does.
So, a minimal example would be like this, set to run "on edit":
function sendMail(e) {
MailApp.sendEmail('user#gmail.com', 'sheet edited', JSON.stringify(e));
}
It emails the whole event object in JSON format.
Aside: if your script only needs to send email but not read it, use MailApp instead of GmailApp to keep the scope of permissions more narrow.
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?