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.
Related
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.
With the classic build pipelines and classic triggers, it was easy enough to track builds that were triggered by completion of other builds by just polling for builds requested by the same user.
Now, with resource triggers, the requested by property switching to the build service account instead of the original author of the triggering commit.
I have been going through the documentation to try and find another way to see triggered builds from the original build ID but have not found anything.
There is an "Associated Pipelines" tab on the build summary page that at least has the pipelines containing the triggered builds, but I cannot find anything to get that by API either.
According to your description, you can first call the REST API to get all the running build pipelines in the definition, and then use the powershell script to loop check the id in the parameter triggeredByBuild in the request body in the specific build so that you can see triggered builds from the original buildId.
Note: The id marked in the attachment is the original buildId that triggered another build pipeline.
I have a pipeline built where, simplified, it deploys a chatbot to a QA Bot Service and then, with a pre-deployment approval, to a PROD Bot Service. Normally it works fine. However, if I do not approve the release, my PROD Bot Service gets wiped (the project files are gone). I tried moving the approval to a post-deployment approval on the QA Bot Deployment, and I have the same exact issue. So my question is, why are my PROD Bot Service files being affected if that step is never being run? I need to be able to cancel the release without impacting the existing production code!
Edit: Updated with additional context. I have determined the issue is happening at provision Azure resources step. Somehow that is causing the code to clear out, before I get to ANY bot service deployment steps. Updated title as well to match issue.
I figured it out. When you set the app service configuration settings, everything is cleared out except the settings you put in (annoying, but that's a whole other issue...). My issue was that I didn't have the WEBSITE_RUN_FROM_PACKAGE = 1 setting in the ARM template. Apparently, if you do not set this value, your bot code (if previously deployed from package via DevOps) will be cleared out. I never noticed this because if you finish the release, this value will be set by your Bot Service Deployment action, and we hadn't cancelled any releases (or had immediately redeployed).
In short, WEBSITE_RUN_FROM_PACKAGE = 1 is required in the ARM template if you are setting any other app settings. Otherwise, bot code previously deployed by DevOps package will be cleared as soon as the provisioning step is completed. Adding this value fixed the issue.
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 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.