Azure DevOps: Change Project Process from Scrum to Basic - azure

I want to change an Azure DevOps project's Process from Scrum to Basic.
I read that:
Previously it was not possible to change between System Project Processes (eg. Scrum->Basic) in Azure Devops. Rather, it was only possible to switch between System & Inherited Processes of the same parent System Process.
But that it is now possible to switch between all Processes.
Documented Process A
According to this web page, I should be able to:
Organization Settings -> Boards -> Process -> Projects -> Scrum ->
Select "..." next to the Scrum Project -> Select "Basic" -> Save
However, this is what happens instead:
Organization Settings -> Boards -> Process -> Projects -> Scrum ->
There is no "..." next to any Projects
Documented Process B
Whilst I could not find the "Change process" option above, I could find the option mentioned on this web page:
Organization Settings -> Boards -> Process -> Processes -> Select
"..." next to the Basic Process -> "Change team projects to use Basic"
So I wonder whether this has replaced the the Documented Process A above OR whether it is in addition to it?
However, when I tried this I just get an error:
There are currently no projects available to change to the Basic
process.
AND this web page states that
Only those projects created from the Agile process or one that
inherits from Agile appear under the Available projects column.
Which seems like it is referring to the days when we could not switch between System Processes.
Other checks
I don't think this is related to permissions because I have "Basic" access, am the Project Administrator and I am also in the "Project Collection Administrators" group, which the documentation says gives me the permissions required to change a project's Process.
I have no Work Items either.
I have tried with combinations of System Project processes and inherited Project Processes. No change, still can't move to any Process based upon Basic.
The referenced web page's example is for Basic-to-Agile. I couldn't find any documented examples of the reverse: Agile->Basic, Scrum->Basic, etc. So I am wondering if this just doesn't work yet with Basic as the target?
I have submitted a Microsoft Support request without response so I am reaching out here.

There's no any limit about change one process to another. It seemed the method you tried was incorrect.
For example, here I has an project under Scrum process. Located to Scrum--> choose Projects-->then choose the ... icon for the project you want to change-->select Change process.
And then, you will see the selection about choosing process, choose one process that you want to change and save it:
Now, open the process which you chosen change just now and you will see the change has been succeed now.
You can refer this similar change way from Change a project process from Scrum to Agile

This worked for me:
First create an inherited process under Basic, say BasicEx, with all the same Work Item Types as under Scrum (this meant I had to add Bug, Feature, Impediment, Product Backlog Item), and first move to this process.
Then delete all the 4 manually created Work Item types (which will delete all associated work items, so if you want to preserve them, change them to Issue type first).
Then move the project to use the Basic process.
Then finally delete the BasicEx process.

Currently Azure DevOps supports change from inherited process template to another inherited template (with the same base process), and change only the following ways:
From Scrum to Agile.
From Agile to Scrum.
From Basic to Agile.
This is the reason you don't success to change from Scrum to Basic.
More information you can find here.

Related

Access Core Data from extension without provisioning profile on macOS?

I'd like to add a Quick Look extension to my program, but in order to be useful, it would have to access the Core Data stack, which seems to require me to add an App Group and a provisioning profile to the project.
Until now, it has been possible for anyone to download the project from Github and compile and run it out of the box. All project targets are set to Team: None and Sign to Run Locally. If I add my provisioning profile to the project, this will no longer work. They will have to create and add their own provisioning profile and change the Signing & Capabilities settings on each of the 26 targets (there seems to be no way to do them all at once). And the profile will have to be renewed every year.
My question is, is there any way around this? Is such a major change really necessary for what amounts to accessing a file inside the program's own bundle (and another in its Application Support folder?)
EDIT: As was pointed out to me on the Apple Developer forum, you don't need a provisioning profile as long as you prefix the group name with the development team identifier. This still won't make it build out of the box, though. You will still need a developer account and set a team on every target.
I had missed that you are supposed to have a team identifier as the prefix for the group name. That still doesn't solve the problem that my project will no longer build out of the box for anyone who downloads it from Github, but it answers the question asked in the subject line.

Gitlab: how to allow user to create project under a group namespace

Some users of the gitlab server are registered as developer under a given group. I would like these users to be able to create repositories under the namespace of the group.
As currently set, the users do not even have the "Namespace" field under the "Project path" field when creating new projects.
Is this possible ?
1st option you have is to change by yourself the namespace after the developer created the project:
project -> settings/gear icon -> edit project -> transfer project
2nd possible thing is to edit project_security_spec.rb or ability.rb
(i'm not familiar with that good enough to explain more...)
You could create an external service that uses the GitLab API to create the project. Using this method, you also have the chance to directly initialize the project with a README and so on.
(Don't know about the GitLab Version for this question is very old - but I came here with the same problem - so here is the answer for today)
Give the users the role "Maintainer" -> see: https://gitlab.com/help/user/permissions

SharePoint 2010 modify web.config file with http handlers

I am deploying a SharePoint 2010 web part that uses the microsoft .net charting tool to build charts. I need the chart handler added to the sharepoint web.configs automatically. I've been told that when you create the wsp the package can be told that when the program is installed it needs to modify the web.config to add these handlers.
I have seen a couple options out there:
-WebConfigModifications
-Safe controls
I don't know which, if any, that I should be using. I don't know for sure if this will be a first time installation for the application (we're moving sharepoint environments at the same time we are updating this. I think that it will be a first time installation on that new environment but can't be sure.)
And I definitely do not know how to implement this correctly. I would appreciate any advice.
Also it may be important to know that I do not have any privileges on the server. I can't even deploy myself.
For example, this seems like good info: http://platinumdogs.me/2009/07/08/using-the-mschart-controls-in-sharepoint-moss-2007/ Except that I can't just write to the webconfig and restart IIS. It has to be automated and not a direct edit to the file.
Thanks all!
I would recommend that you use a Feature Receiver attached to your WSP to create the appropriate SPWebConfigModification entries when your solution's features are activated. Likewise, the SPWebConfigModification entries should be removed when your solution's features are deactivated.
Step 1: Create a Feature Receiver
MSDN has an overview of how to add a Feature Receiver: http://msdn.microsoft.com/en-us/library/ee231604.aspx
Note you'll want to handle both the FeatureActivated and FeatureDeactivating events.
Step 2: Use Feature Receiver events to add or remove SPWebConfigModifications
In those two events, you'll need to programmatically add or remove one or more SPWebConfigModification entries. These affect SharePoint's web.config file, but unlike a manual edit of the config file, they are stored in SharePoint's content database. This means that if the web.config is reset for any reason (and it happens), SharePoint can and will reapply the modifications, thus preserving your changes.
MSDN has an overview of programmatically creating and removing SPWebConfigModifications: http://msdn.microsoft.com/en-us/library/office/bb861909(v=office.14).aspx
It is very important that the FeatureDeactivating event properly clean up all modifications made during FeatureActivated, or you will end up with a proliferation of duplicate config entries. This means you need to really understand how to use the Path and Name properties of the SPWebConfigModification.
This article gives a good overview of how Path and Name are combined to create an XPath expression pointing to the node to be added or removed: http://smindreau.wordpress.com/2013/06/12/finally-the-way-to-add-web-config-modifications-to-sharepoint/
Step 3: Test, test, TEST!
Lastly, test activating and deactivating your solution's feature in your local development environment to make sure everything is working properly. Note that the modifications will be applied via a timer job, so you may need to wait a minute or two to see the changes show up. Be sure the feature deactivation cleans up your modifications! (If you get into a mess in your development environment with duplicate modifications, you can always wipe the slate clean with a little PowerShell action.)

How to change the project owner in GitLab

How can I change the project owner in GitLab?
There are options in project settings, but in the "transfer" field, it does not recognize any username or anything. Is it possible to change the owner-permissions and root-privileges?
TL;DR
Move your project to a new group where both you and the other user are owners, then the other user must transfer it to his own namespace.
Background
The other answers obviously do not work to transfer a project to a different user, although the comments section of one is enough for someone to figure it out. Also there is this issue on GitLab itself that provides some insights.
My Situation
I installed and now administer a few instances of GitLab for a few small developer teams as well as one for my personal projects. Resultingly, I have run into numerous questions about this. I keep coming back to this question only to realize that it was never actually answered correctly.
The Namespace Problem
The issue that you face when doing this is that there can only be one owner of a project, but to transfer a project you have to own the namespace that you are transferring it to. To my knowledge there is no other way to move a project. For completeness, I'll add that the namespace here is, e.g., "gitlab.com/my-user-name/..." or "gitlab.com/my-group-name/...".
Solution
Because one user cannot "own" another namespace (not even admins), the only option to set up a scenario where two users own the same namespace is with a group. Perform the following steps to accomplish this.
Create a new group.
Add the user that you want to transfer your project to as an owner member of that group.
Transfer your project to that group (a namespace you manage because you are an owner).
Login as the other user, then transfer the group project to the "other user" namespace.
At this point you will be left as a master in the project. You can now remove yourself from the project entirely if desired.
You can add another owner to the project via:
Project -> Members -> Add members -> Select Owner as permission
Next you have to remove yourself from the project:
Project -> Members -> Click the red button behind your username
Now you left the project, and the user you entered before is now the owner.
You can basically create a group then add the project to a group, then from the group member setting add a new owner and you can leave the group yourself.
See screenshots
It is also possible to export the project and import it under a different user. This preserves commits and branches.
Settings -> Advanced -> Export Project
Then to import:
New Project -> Import Project -> Gitlab Export
If you need to do this for many projects, it's pretty convenient to do it via API:
import gitlab
gl = gitlab.Gitlab('https://gitlab.com', private_token='...')
gitlab_project = gl.projects.get("the-project-of-yours")
target_group = gl.groups.get("target-group-where-to-land")
gitlab_project.transfer_project(target_group.id)
https://docs.gitlab.com/ee/api/projects.html#transfer-a-project-to-a-new-namespace
https://docs.gitlab.com/ee/api/groups.html#transfer-project-to-group
https://github.com/python-gitlab/python-gitlab/blob/master/gitlab/v4/objects/projects.py#L461
In current version (10.2.4) you should do following:
Go to "Project" -> "Settings" -> Expand "Advanced settings" -> Scroll down to "Transfer project"
It involves multiple steps, but its possible.
Create a group and transfer project to the group
Invite new user to the group
Login with new user and transfer project to new user from group
However I think it is easier to maintain if you leave your repository in the group
Transfer menu are always at
Project => Settings => Advanced
In Gitlab 8.8.3 you are able to transfer a project.
Be careful. Changing the project's namespace can have unintended side effects ;)
Go to Project -> Settings -> Project Settings -> Scroll down to Transfer project
In GitLab Community Edition 9.3.5 if you are administrator you should go to Settings -> Members and change de role of the member you want.
For example, search John Doe, set the developer role, and now John Doe will be developer and won't be owner anymore.

Best practices for applying changes to a SharePoint application

I feel like I need a better defined framework for updating my SharePoint (MOSS 2007) application with custom code changes. I am creating wsp solution files with features and new types and such, but once those get tested and deployed, I feel like it's a bit of a leap of faith, and that makes me nervous and occasionally reluctant to deploy changes. After deployment, it's difficult to correlate the current state of the SharePoint application with the specific code that is deployed on that SharePoint server. What features are actually installed and on which sites? Which features are activated or deactivated? Which version of this custom field or content type is really there? Things like this. If an error crops up, I have to rely on my assumptions about what code is there and actually running, or I have to spend time digging through deployed assemblies and the 12 hive -- not impossible, but pretty unpleasant.
What steps should I take to improve my ability to unambiguously determine the state of the application and find the code that truly represents that state? Are there third-party tools that can help with this?
I feel your pain... Application Developyment Lifecycle with SharePoint 2007 leaves me with a bitter taste in my mouth.
To answer your question. We built our own deployment utility that does a few things for us.
Checks state of key Timer Jobs (too many times we would do a deployment to find one WFE that did not get deployment)
Checks state of key Services on all our web front ends (again we want to know health of farm before we start kicking off timer jobs).
Shows file version and date of selected assemblies from GAC (does this across all Web Front Ends). We have seen problems before where assemblies did not get installed correctly across the farms.
Updates web.config settings based on an custom XML scheme we provide. We ran into some problems with web.config updates so we have thought about creating a utility to validate the web.config (specifically make sure there are no duplicate entries for specific keys).
Push content type updates (first time content types are deployed via feature it works great, but as soon as you need to update that content type it gets tough).
Checks status of WSP package after deployment or upgrade.
This utility uses the SharePoint API to do most of this work. Some of it is done by checking WMI Events.
Unfortunately the SharePoint development experience is lacking in this regard. As long as you are "namespacing" all features deployed using solution packages, you can use solution management from central admin to keep track of versions, and what gets deployed to which site collection.
Features are scoped from all levels from the farm to an individual web; so maintenence from that level is a little tough. I just try to organize all deployed code from the (top down) solution level.
It gets even more complicated when deploying custom timer jobs, event handlers, etc; I really hope that version next will address a lot of these common developer concerns.
Isn't the only way that you have a planned/controlled deployment process and a version management system like TFS
In the current project I am involved in we have:
Continuous builds
Daily Builds on a development server
When we release something to test we merge the code to the Main bransch in the version management system (TFS)
When tested and ready for production then we merge the main bransch to the release bransch
Using this structured way we always knows what is deployed in what environment and can also track all changes based on environment or changes in requirements(are also tracked in TFS)

Resources