I have created a workflow which lets Admin publish document.
It's a basic workflow.
What I want is to bypass process for Admin, currently what is happening is that Administrator have to create/approve/publish , Administrator can publish changes directly by not following these steps.
Any help is appreciated.
Thanks.
We have done it by adding this condition.
This is not possible using basic workflow. You can do it either by using advanced workflow (since v7) or by customizing EditMenu.ascx.cs (and underlying classes) + probably CMSDocumentManager. If you want to use workflow just for versioning purposes, use "Automatically publish changes" option on 'General' tab of basic workflow.
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 developing Release pipeline for deploying artefacts using TFS 2017 Update3 Release Management. There are various tasks like "Windows Machine File Copy" and "Run Power Shell on Target machines" which needs admin credentials to be passed as input parameters. These admin credentials have Administrative access on target nodes. I'm using Windows service accounts for these. We have an organisational security policy to rotate passwords every month.
With that in mind, it is hectic to update hundreds of TFS release definitions for new password every month.
Do you have a better idea to handle this? Please give detailed answers.
Thanks in advance.
You could use a variable group to store values that you want to make available across multiple build and release definitions. Variable groups are defined and managed in the Library tab of the Build & Release hub. In this way, you can just edit the variable group:
https://learn.microsoft.com/en-us/vsts/pipelines/library/variable-groups?view=vsts
If you want to automate the process you use the solution defined here. This details how to use the TFS API to poke the definitions.
Alternatively you could create your own PowerShell task that sources the password from some alternative source like Azure Key vault or even hard code it into the json task definition itself (don't do this).
You can vote to improve this story here.
I wrote a custom version of the PowerShell task that uses the identity of the agent as part of the WinRM session which greatly simplifies our release definition process.
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.
I'm using Jenkins for CI in a multi-user Linux environment, with Cobertura for tracking code coverage. CVS is used for version control. With each "cvs commit" a build is triggered. A build includes running unit-tests and generating code coverage.
The issue is the following. When code coverage report is created, a line-by-line coverage for all the unit-tested source files is created too. That is fine and very useful while writing and running unit tests, but it also allows everyone with access to the network to view the project source files.
My question is how can I restrict this line-by-line coverage report to be visible only to, let's say a group of Jenkins users or similar, and not visible to the rest.
I saw that Jenkins allows different "security realms" to be configured. Currently I use "Jenkins' own user database". I see that there's also "Unix user/group database" which sounds like it might solve my problem, but I just wanted to ask for other people experiences and opinion before I experiment with that option.
Thanks in advance!
It can be better to export report artifacts to some other location which supports access control. It can be a wiki or Apache instance, etc. Much better to protect Jenkins instance instead of spending valuable time on protecting some piece of it.
No such feature means there is no need in it.
Jenksing does not provide fine-grained authorization. Moreover, Cobertura report is just a set of static htmls, so you may investigate web-container configuration in order to find some way to define filters, etc.
I would say the safest possible solution is to use another jenkins instance for handling sensitive information. You can put it behind Apache with HTTPS configured and sleep well. BTW, there is JobImport plugin https://wiki.jenkins-ci.org/display/JENKINS/Job+Import+Plugin to avoid duplication if any.