I'm trying to find whether the Episerver Scheduled job (Episerver CMS 11) is triggered manually or automatically.
While on finding in Episerver documents I do see the 'ScheduledJobTrigger' and 'ScheduledJobLogItem' are related to this. But still, I am unable to find out how to call the service for implementation and get the expected value. Can anyone help me on this?
In code, the ScheduledJob will not have a user associated with it's context when fired automatically (either via API or scheduled firing), whereas a manual start will have user context associated to it.
If you are looking to identify if this was triggered manually, checking that user context may be what you are looking for.
Related
I'm trying to implement automatic backfills in Argo workflows, and one of the last pieces of the puzzle I'm missing is how to access the lastScheduledTime field from my workflow template.
I see that it's part of the template, and I see it getting updated each time a workflow is scheduled, but I can't find a way to access it from my template to calculate how many executions I might have missed since the last time the scheduler was online.
Is this possible? Or maybe, is this the best way to implement this functionality on Argo?
I've been looking at organisation and project settings but I can't see a setting that would prevent users from creating work items in an Azure DevOps project.
I have a number of users who refuse to follow the guidelines we set out for our projects so I'd like to inconvenience them and the wider project team so that they find it better to follow the guidelines than not - at the moment we've got one-word user stories and/or tasks with estimates of 60-70 hours which isn't reflective of the way that we should be planning.
I'd still want them to be able to edit the stories or tasks and moving statuses, but that initial creation should be off-limits for them (for a time at least). Is there a way to do this??
The Azure DevOps Aggregator project allows you to write simple scripts that get triggered when a work item is created or updated. It uses a service hook to trigger when such an event occurs and abstracts most of the API specific stuff away, providing you with an instance of the work item to directly interact with.
You can't block the creation or update from, such a policy, Azure DevOps will inform the aggregator too late in the creation process to do so, but you can revert changes, close the work item etc. There are also a few utility functions to send email.
You need to install the aggregator somewhere, it can be hosted in Azure Functions and we provide a docker container you can spin up anywhere you want. Then link it to Azure DevOps using a PAT token with sufficient permissions and write your first policy.
A few sample rules can be found in the aggregator docs.
store.DeleteWorkItem(self);
should put the work item in the Recycle Bin in Azure DevOps. You can create a code snippet around it that checks the creator of the work item (self.CreatedBy.Id) against a list of known bad identities.
Be mindful that when Azure DevOps creates a new work item the Created and Updated event may fire in rapid succession (this is caused by the mechanism that sets the backlog order on work items), so you may need to find a way to detect what metadata tells you a work item should be deleted. I generally check for a low Revision number (like, < 5) and the last few revisions didn't change any field other than Backlog Priority.
I'd still want them to be able to edit the stories or tasks and moving statuses, but that initial creation should be off-limits for them (for a time at least). Is there a way to do this??
I am afraid there is no such out of setting to do this.
That because the current permission settings for the workitem have not yet been subdivided to apply to the current scenario.
There is a setting about this is that:
Project Settings->Team configuration->Area->Security:
Set this value to Deny, it will prevent users from creating new work items. But it also prevent users from modify the workitem.
For your request, you could add your request for this feature on our UserVoice site (https://developercommunity.visualstudio.com/content/idea/post.html?space=21 ), which is our main forum for product suggestions.
Whenever the user submits a workflow request from Enterprise portal clicking more than once, multiple instances are generated. Kindly suggest a way to avoid as it is misleading.
Thank you.
Have a look here
In the event this.WorkflowActionBar.EvaluatingCanSubmitToWorkflow you could via the EP's Business Connector session call a static method in X++ to check whether a workflow for your current process / document / whatever already exists and avoid submitting it again. How you determine that of course depends on your environment / process etc.
I am trying to get the pages which are scheduled to activated in cq5.5 through code.To get the pages ,which are activated,I have used the property replicationAction.
But for the pages which are scheduled to activated,is there any similar property we can use or is there any other way we can get it.
Thanks for the help.
It's not trivial, but doable. I'm not sure whether that's the easiest way to achieve it, but this is how I'd start:
Get an AgentManager service through reference
Find the appropriate Agent from the map retrieved by getAgents()
getQueue() on the agent will give you the ReplicationQueue object that provides the functionality you're looking for.
I need to capture the events for tagging in CQ. Need to capture the tags whenever the users add/remove/change/delete tags in CQ tagging console.
I have an idea to implement a workflow & launchers to handle the event handling in tagging console. Whenever such event occur, automatically the workflow will get trigger and get the events. I don’t know how to implement such workflow. Please share any url related to this.
Also I heard that JCR listener, Is this helpful to manage event handling?
Please share if you have come across any requirement ?
I would also use a workflow model with an appropriate launcher, as you suggested.
The launcher is actually quite easy to create - you can specifiy the location to watch (probably /etc/tags), the type of event (node creation, update, deletion) and the workflow to be triggered.
For workflow model creation, adobe has some articles here:
http://docs.adobe.com/docs/en/cq/5-6-1/workflows/create-models.html