A while back I asked how to override sails.js blueprints (CRUD blueprint overriding in sails.js)
With v0.11 of sails.js we now have blueprints (and they are awesome :)).
Is it possible to turn off the current blueprints and install a new version of them as a hook?
This issue comment (https://github.com/balderdashy/sails/pull/2173#issuecomment-54165548) from #sgress454 seems to indicate it is/was in the works, but I can't find anything more specific about it.
I know I can override by creating an api/blueprints folder, but it would be easier for my users to consume via an npm install.
You are right, this is possible.
It is actually what happens in Sails's core here : https://github.com/balderdashy/sails/tree/master/lib/hooks/blueprints
Default blueprints are loaded like an Installable Hook would be.
You can just go ahead and copy that MIT licensed code and then replace the content of the actions directory with your own blueprints.
After that, update the object BlueprintController in index.js to make sure it points to your files.
Finally, all the magic happens in the extendControllerMiddleware method. You can see the code will go through each controller to inject your blueprints. The key point here is the replace the call to _.defaults with _.assign because your sails hook will want to overwrite defaults blueprints and not simply add them if they do not exist.
Related
I have a custom sails.js hook which implements a Websocket server (we can't use the built-in socket.js hook because we needed to match an old API).
I also have a custom sails run script that does background processing.
Right now, when the sails run -name-of-my-script command is run, it also runs my hook which makes extra listeners for all of the events used by this hook.
I would like to make it that the hook only starts on a main application startup (sails lift or the equivalent node app.js), not on sails run ....
I have looked through the code and the documentation, but I can't seem to see any official way to do this.
I can think of two options:
In the hook, check for whether a script is being run and don't initialize.
In the script, disable the hook.
Is there any way to do either of those things?
Right now, there is no built-in way to do this because Sails scripts have no way to modify configuration - they use the default sails instance with its default settings.
Here is the hack that I used to make it work:
Add a check for a configuration option in the hook's initialize method:
if (app.config.notifier.active === false) {
sails.log.verbose('Notifier disabled');
return cb();
}
// Continue with notifier hook setup here
Add setting an environment variable to the top of the script (before the module.exports:
process.env.sails_notifier__active = false;
(Note: Step 1 is based on this answer but the package linked there no longer uses this technique. That question and answer are also extremely old -- at least as Sails.js answers go -- from before sails run existed.)
Based on the documentation https://learn.microsoft.com/en-us/vsts/extend/overview?view=vsts#what-makes-up-an-extension, a VSTS extension can be used to extend the work item form.
However, I would like my extension to automatically create a new work item type once it is installed. Is this something that is possible? I can't find any documentation online that suggests how to do it.
Theoretically this is possible, the extension has a "first load" call which you can use to use the rest api to create a custom process or update the existing custom process. The REST Api to change processes isn't public yet, so you'll have to work from using fiddler to watch how the web ui does it.
Due to the way processes are linked to projects, all projects with that process will get the new work item type.
I could not find a lot of documentation online for this, but the VSS web extensions SDK(https://www.npmjs.com/package/vss-web-extension-sdk) has a REST client called 'ProcessDefinitionsRestClient' declared in the typings/tfs.d.ts file. This client has a createWorkItemType method available that looks like this:
createWorkItemType(workItemType: ProcessDefinitionsContracts.WorkItemTypeModel, processId: string): IPromise<ProcessDefinitionsContracts.WorkItemTypeModel>;.
The 'ProcessRestClient' client has methods to create a new/inherited process to which the new WIT can be added.
I have not tried it out yet, and these APIs are still in preview, but maybe they can get you started on the right path.
I'm looking to create a vue-cli 3.x plugin that generates extra files in the project when invoked and templates these based on configuration info entered by the user.
It's rather easy to collect this information from user prompts but it'd be much nicer if users could put this info into some sort of configuration file and have the plugin read it from there.
I understand vue-cli now uses a vue.config.js file on the project level and ~/.vuerc on a more global (preset) level. However, it doesn't look like my generator function would have access to either one of those files.
"The entire preset" should be passed as the third argument to the function when invoking the plugin with module.exports = (api, options, rootOptions) => {} in ./generator/index.js, rootOptions is undefined.
Sililarly, the use of vue.config.js is discussed in the documentation when talking about service plugins, but there's no mention how to use it in a generator function.
Am I missing something obvious here or is there really no officially sanctioned way to do this? Nothing stops me from reading vue.config.js in my function, but this feels hacky. And I wouldn't even know how to find out which preset was used to create the project.
So your problem is that you can't find ~/.vuerc?
I had the same issue and I found the solution here.
The solution is to use the command line
vue config
to see .vuerc, and then use
vue config --delete presets.yourPresetName
to delete your preset.
As well, if you can't type in your preset name in the terminal because it contains a space or an apostrophe, you can use
vue config --edit
to open .vuerc with a text editor and just edit it there
I am currently working on with a solution that would be able to clone/copy/backup my existing rep:policy. 'Cause when we do some jobs it accidentally removed. I am trying to apply this kind of fix, but am failing to. It says it is an invalid path.
javax.jcr.security.AccessControlException: OakAccessControl0006: Isolated policy node. Parent is not of type [rep:AccessControllable]
final Workspace ws = session.getWorkspace();
ws.copy("/etc/commerce/products/abccompany/TvPackChannelMap/rep:policy","/tmp/nxt/TvPackChannelMap/rep:policy");
Are there other ways that I can be able to take the rep:policy thru code?
You need to make sure that your job does not touch the permissions or the rep:policy, this is the best way forward for you.
The exception could be because of /etc/commerce/products/abccompany/TvPackChannelMap/rep:policy does not exist or the user whose session you are using does not have read access to the node.
Make sure the path is correct, copy paste it to your CRX/DE to make sure it exists.
I have tried to use your code to copy a rep:policy from one node to another, works fine. But I would not* recommend copying permissions that way. The best practice is to use the Access Control Management API for all things permissions.
You can check, install and use the access control tool from netcentric. It offers a jmx interface for exporting AC entries and maybe also some APIs you could use to implement your custom solution.
The Other approach is to retrieve the ACL permissions through the query language.
For example, SELECT * FROM [rep:ACL] or SELECT * FROM [rep:ACE] where [rep:principalName] is not null should give you the results.
For more information, I would recommend you to check the ACS commons ACL Packager Implementation which is available on GitHub.
Reference Link - https://github.com/Adobe-Consulting-Services/acs-aem-commons/blob/master/bundle/src/main/java/com/adobe/acs/commons/packaging/impl/ACLPackagerServletImpl.java
When I create a new workflow model in AEM, it gets created under /etc/workflow/models. How do I get it to be created under a different path like /etc/workflow/models/myapp ? The only way I can think of is changing the path in CRXDE after the workflow gets created. Wanted so if there is a better way to do this.
Better way to move workflow to another place would be:
go to /miscadmin#/etc/workflow/models
use button "Move..."
Unfortunately, it seems, that there is no easy way to change place, where worflows, which are created through UI, are stored. To do this you should:
override "/libs/cq/workflow/widgets/source/widget/ModelsPanel.js" in you project, where you can find action this.newAction, where you will be able to change propery parentPath to /etc/workflow/models/myapp. But you can run into troubles after upgrading to another version of AEM.
also you can be interested in service Granite Workflow Service where you can set (through /system/console/configMgr) path to your models, which should be shown in Workflow Console /libs/cq/workflow/content/console.html. (Also it's applicable to CQ 5.6.1, for some older versions, you should configure Day CQ Workflow Service).