Recently I have updated to 6.5.13 SP for aem. There is a custom workflow for page deactivation, which has the following steps:
Start-->lock payload--> create version-->Approval requested to content-administrator--> Approval granted by content administrator-->Deactivate Page/Asset-->Unlock Payload--> Sent Email to content author.
After upgrading to SP 13 , I noticed a difference in the workflow. After the unlock payload step, it is automatically calling and starting the OOTB workflow (request for deactivation).
Can anyone help me here. I have verified that none of the processes calls the OOTB workflow, and it was perfectly fine before installing service pack.
Is there an additional launcher active maybe that is called by that event? Maybe the default workflow has been reactivated with the update.
Related
everybody.
We have just successfully migrated from ADServer 2019 to ADServices.
We have a single custom process template that is used for all Team Projects. After migration, each team project has its own Process Template, as expected.
However, as all migrated Process Templates are equal, I would like to group all Team Projects in a single Process Template.
In order to do that, I do these steps:
Go to Organization Settings
Select Process
Click on one of my hosted process templates
Click on "Projects"
Click on "..." and select "Change Process"
A pop up appears, where I can select the target process I like to change. It's important to note that all hosted migrated process seems to be avaliable for the change.
When I select another hosted process, and click "Ok", the message "The feature is disabled. Contact your Azure DevOps Server administrator." appears and the change can't be done.
I have been looking how to enable this feature with no success.
Has anyone had this situation?
If is not possible to do that, is there any way to import the future changes of my process template via command line, in order to update all my team projects ?
Thanks in advance for the help.
Regards,
Alba
We evaluated this situation with MS and the answer is that there is no way to make this change of process template between team projects belonging to different hosted process template, even though the process templates are equals.
As we cannot change our Process Template to hosted process by now, our solution was making a script using AD api, in order to make a bulk update of all process templates for all our team projects.
See https://learn.microsoft.com/en-us/rest/api/azure/devops/processadmin/processes/import%20process%20template?view=azure-devops-rest-6.1
From the screenshot, you were trying to change the process used by the team project from a hosted xml to an inherited process. For your scenario, you need to
cloned your Hosted XML process to an inherited process.
Change a project from Hosted XML to an inherited process.
An useful blog for your reference:
https://devblogs.microsoft.com/devops/moving-from-hosted-xml-process-to-inherited-process-ga/
Concourse CI provides an easy way to trigger and abort pipeline job builds via the web interface or the fly CLI.
I haven't found a way to determine who performed these actions after the fact. Is this information logged somewhere that can be accessed by users?
The information displayed on the web page and accessible by the fly watch command doesn't appear to contain these details.
There was the work-around to viewing this, you can enable auditing and check the logs (Check_Here).
But there was one open issue related to display who triggered job in the UI (Check Issue here)
I'm trying to integrate my Visual Studio Team Services with Slack, and the first thing I tried to do was notify my Slack channel whenever a Pull request is created.
So I searched through the options, and the best fit so far was the Service Hooks available on Team Services, which integrate seamlessly with Slack, or does it?
The problem I encountered was: I use a tool that creates pull requests through the REST API, and the service hook doesn't seem to be working when I create pull requests through this method, only when using Team Services UI.
This is the Service Hook configuration.
Has anyone faced the same problem, or know any other way of notifying a pull request creation to slack?
Apparently the issue has been fixed by Microsoft, the last update of Team Services triggers the event without a problem now.
I have a custom workflow which starts an approval workflow whenever a list item is created. On our test server, this work fine. However, when I deployed on another server, the task of the approval workflow is not being created. Any ideas why?
Whether you have activated the feature to view the workflow or not? If yes check workflow setting whether it is referring to the same task list or not.
I am trying to build a Project Server workflow using SharePoint Designer 2013.
The workflow itself is working. It can create a task in the Project Server task list and approving it progresses the workflow.
However, if you click "Additional Workflow Data" the history is always empty. I have been able to create a custom event to log in the history via designer, but I am looking for the true history of the workflow. In 2010, the history would show it entering each stage and other logging data. My 2013 workflow history shows nothing.
I have verified the account has permissions to write to the list. I have checked the IIS logs to see the workflows are running. I have checked the project server permissions and groups for the workflow proxy account. I have ensured "Workflows can use app permissions" is activated for the PWA collection. I have also tried "Copy-SPActivitesToWorkflowService" cmd to see if it needed to installation needed to be repaired. I have restarted the workflows, republished, bounced the boxes, but still not workflow history!!
Does anyone know how to resolve this issue or have other suggestions on where to look?
You need to use an 'Action' within the Workflow called 'Log to History List' and enter what you want the log to say at the point where you have added the Action.
The sticking point comes from a differences in versions.
In Project Server 2010, the workflows showed default actions and processes. In 2013, you cannot see all the various behind-the-scenes actions.
Any actions which you want to be able to trace, for example, when the project entered the stage, must be added into the custom workflow manually.