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.
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.
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)
As far as I can tell from the current interface provided for setting up e-mail alerts for builds in visual studio team services, there is no way to set a condition on the status of the previous build.
I expect this is relevant to many development teams as teams will typically have a build server churning out builds frequently throughout the day and will want e-mail alerts of a failure. Following a failed build, it is useful to also have a success email for the next build. However, you don't want an e-mail for every successful build as you are only interested in this after a failure, the rest is just white noise.
So is there any way to create alerts conditional upon the previous build in visual studio team services, or more specifically to just get success e-mails after a failed build?
There isn't any way to do this with the alerts feature in VSTS for now. You can submit a feature request on VSTS User Voice.
And the alternative way to achieve this feature would be create an application/service to track the build event and send out email notification base on the build status you want via VSTS Rest API or TFS API.
For whatever range of poor reasons...a user schedule workflow has been uploaded to our YouTrack server instance that now automatically generates seemingly hundreds of new issues a minute.
As you might imagine, the web server is totally unresponsive, meaning that we cannot disable or detach the workflow from the project. The workflow editor's attempts to remove the workflow fail with connection timeouts.
How can the workflow be disabled without accessing the usual admin pages? Is there a workflow file somewhere in the server's directory that can be deleted (I can't find one) while the service is stopped? Is there a "run in safe-mode" option for YouTrack?
We're running YouTrack 5 fwiw.
Thanks in advance.
In YouTrack 6.0 we've implemented special Java start parameter (-Djetbrains.youtrack.workflow.detachModified=true), it will work starting from next bug fix release.
This option will detach all the workflows from all the projects on start, except the unmodified supplied ones.
Please, consider https://youtrack.jetbrains.com/issue/JT-27785, the Fix version of this issue will be changes as soon as we release next bug fix.
Workflows are stored inside YT db, so the best variant for you is to contact YT support. It'll be able to modify the db.