I have 2 small plugins:
In Authentication group and works on onUserAuthenticate event
In System group and works on onAfterRoute event
As 2 plugins i need to install 2 zip-files. Is it possible with registerEvent function create 1 plugin?
Mhm... on my opinion you should keep two different plugins.
Infact you could call a plugin from another, but what if the user just installed one and not the other?
Moreover, you can trigger an event, not a single plugin.
This means that you'll trigger all the plugin linked to that event, not just your.
IMHO you should use two plugins or you can get some errors that will be a nightmare to debug.
Related
I want to visit an url perform some operations then open different url in different tab/window and perform some action in new tab and come back to the previous tab/window and so on. Is this possible in cypress?
Please suggest some solution if possible.
Cypress does not and will not support handling more than one tab/browser, for further read and recipes see: https://docs.cypress.io/guides/references/trade-offs.html#Multiple-tabs
I see two solutions:
Use api request for the operations needed for the external url
Divide the test in different cases
2.1. In before/beforeEach section make preparations needed
2.2. It case for first part in your project
2.3. It case for the different url
2.4. It case for the second part needed in your project
If have some repetitive data that needs to be reused - you can declare it as a variable ouside of the "describe" scope with usual JS code.
I am working on designing a lengthy approval system in CRM using a combination of OOB workflows (designed using CRM UI Workflow Designer) and custom actions (actions written using .NET code). Idea is to keep the entire branching/simpler logic in OOB workflow and call custom Actions wherever necessary. However I have few questions with this approach:
How can I handle run-time errors generated in the action code?
For example, one of my Actions contain the code to push data to an external system via web service. In case this web service call fails, I need to perform some steps in the parent workflow.
How can I handle 'if conditions' which can't be handled by 'Check Condition' step? For example, suppose that before performing a certain workflow step I need to check some data which can't be queried within CRM. I can create an Action which will return true/false based on the custom logic which can then be checked in parent workflow.
An alternate approach would be to use plugins but I am inclined towards using OOB functionalities as much as possible. Any inputs would be helpful.
First of all let's clear the semantics, because I'm not sure if you understand what are you talking about - there are Actions (you can refer to them as custom actions, but then you should refer to every workflow you create as custom and I figured out of your post that you are describing them as OOB, which also is semantically wrong - every workflow you create is a custom workflow, maybe it's using OOB steps, but that's a different story) and Custom Workflow Activities. I'm assuming that you want to use Custom Workflow Activities, because the are more suited for what you are trying to achieve here. Also you tagged your question as CRM 2011 and CRM 2013 - not sure what you meant, because Actions were not available for CRM 2011.
So basically Custom Workflow Activities can have Input and Output parameters. Output parameters are answer to both your questions, because you can use them to get the error message after your custom processing or use then in conditional statements later in your workflow. Output parameters can be defined like that:
[Output("Error message")]
public OutArgument<string> ErrorMessage { get; set; }
You can find more examples here:
https://technet.microsoft.com/en-us/library/gg327842.aspx
You can of course set this properties simply by calling
ErrorMessage.Set(executionContext, messageText)
So now when you define your workflow, wherever you need something not configurable in OOB blocks, you can put your Custom block, after it's done simply check it's output for the error (this is just an example, you can pimp it up by adding additional output parameters, to make it more generic), if it's empty then do something, if not then do something else for example send email with the error message. It all depends on what are you trying to achieve.
Actions are serving different purposes, they are useful to create a logic that can be easily called through plugin or javascript (webAPI) and allows you to also put a plugin on it alongside doing everything within one transaction. Maybe it will be useful somewhere in your workflow, but as far as I remember in CRM 2013 actions could not be called from a workflow...
UPDATE:
Ok so if we are dealing with CRM 2016, we can call Action from a workflow. What is best in this situation really depends on the scenario and what we are trying to achieve, but to make it easier to decide let me highlight main differences:
1) Activities are simply a blocks of code that can be put inside your workflow. Actions by themself are not code, they are custom Messages that you can call. Of course you can register a plugin on this custom Message and do there any custom logic you want, but this is another step to take
2) Actions can be run in transaction, Activities not (but you can run Activities inside Actions, so in this case they can run in transaction)
3) Actions can be called directly from Javascript, plugins and workflows. It's a great thing, but if you will make let's say 10 custom Actions which you will be using ONLY inside you one workflow, they will be visible when you will be registering plugins (and also any js developer will be able to call them with JS)
So basically Actions are a big, fat feature that can serve many purposes (including running Activities on their own!), Activities are much simpler but in your case they will also do their job. So you should ask yourself questions:
Do I need my logic to run inside transaction?
And
Do I need to call this logic somewhere else than my workflow?
If you have any "Yes" then go for Actions, of no, then go for Activities, because you will be overcomplicating things without any good reason.
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 would like to be able to build functionality for my application in a plugin style system for a couple reasons:
New projects can choose which plugins are necessary and not have code for functionality that's not needed
Other developers can build plugins for the system without needing too much knowledge of the core workings.
I'm not really sure how to go about implementing this. I would like to have a plugins folder to host these separately but I guess my questions are:
How do plugins interact with the core system?
How does the folder structure work? Would each hold the standard MVC structure: controllers, services, models, views, etc?
I guess if anyone has a tutorial or some documentation relating to this technique that would be helpful. I've done a bit of searching but it's all a little too closely related to the actual code they're working with instead of the concept and I hadn't found anything specifically related to nodejs.
I suggest an approach similar to what I've done on the uptime project (https://github.com/fzaninotto/uptime/blob/master/app.js#L46):
trigger application events in critical parts of your application
add a 'plugins' section in the applicaition configuration
each plugin name must be a package name. The plugin packages should return either a callback, or an object with an init() function.
either way, inject to the plugins the objects they will need to run (configuration, connections, etc) when calling init(), or executing the callback.
plugin modules register listeners to the application events and modify it
Benefits:
lightweight
rely on npm for dependencies
don't reivent the wheel
Create a plugin prototype for the base
functionality, and let the user define its plugin in a module. In the
module the user would inherit an object from the prototype, extend its
functionality, and then export a constructor which returns the plugin
object.
The main system loads all plugins by require("pluginname") and for
each calls the constructor.
My goal is to disable the module programmatically (for example during some observer event).
The earliest observer I found is controller_front_init_before.
So my module is listening to it, and then do the next:
Mage::getConfig()->getModuleConfig('IG_LightBox')->active=(string)'false';
But the selected module is still active on each page.
Also I tried this approach (the same but in different way):
Mage::getConfig()->getNode('modules/IG_LightBox')->active=(string)'false';
Also I tried to reinit config after all and to loadModules one more time, but both won't help.
Mage::getConfig()->loadModules(); // won't help
Mage::getConfig()->reinit(); // won't help
Is it possible to disable the module programmatically?
Update 1.
This solution perfectly works for the back-end. active=false really disables the module, but I need it for the front-end too. So I keep my search.
Update 2
There are 2 methods in the app/Mage.php, called init and initSpecified, which allows to run the Magento with the selected number of modules only. But those methods are not called in the default flow.
Update 3
There is an observer event we can use for activating or deactivating the payment modules on the fly. It's called payment_method_is_active. This code example makes the check money order payment method being not active:
public function payment_method_is_active(Varien_Event_Observer $observer)
{
if($observer->getMethodInstance()->getCode()=='checkmo')
{
$observer->getResult()->isAvailable=false;
}
}
I think it depends on which kind of module you want to disable. My article worked for the kind of module I wanted to disable, but that module double-checked if it was activated, while most modules don't do that.
Magento loads all module configuration at once. Its impossible to create a module that will listen to this process because the module would have not been loaded while the process takes place. This creates a paradox. Its impossible to prevent a module from loading using another module.
As a result the only options you are left with are:
Edit the core.
Use modules which are better designed and explicitly allow themselves to be disabled through a config option or method.
Edit/extend the module you want to disable so that you can disable its functionality during runtime.
Hope this helps.. let me know if I can help you find a way to disable the module you're dealing with.
Here is one solution I found.