Azure Dev Ops integration - pull only

[ells69]

ok

I want to use the Git Integration feature in the Fabric workspace. But if I delete an item in the workspace this then syncs and deleted my code from Azure Dev Ops Repo.

I want it to be one way only and cant see this when setting up the connection to Azure Dev Ops

Is there a way to do this or a better option?

[v-fenling-msft]

Hi, @ells69 

May I ask if you have gotten this issue resolved? If it is solved, please share your solution and accept it as solution, it will be helpful for other members of the community who have similar problems as yours to solve it faster.

If not, please provide more details about the problem you are experiencing and we will do our best to solve the problem you are experiencing.

I hope my suggestions give you good ideas, if you have any more questions, please clarify in a follow-up reply.
Best Regards,
Fen Ling,
If this post helps, then please consider Accept it as the solution to help the other members find it more quickly.

[ells69]

I dont think it has been answered. This is quite project critical. The same code will be pushed \pulled to multiple workspaces.
What I am trying to guard against is someone who is using one worksapce pusheing changes back to source control. This will then get pulled into the other workspaces and could have really bad effects and we would be left with a mess.
I cant believe that if you grant read access only in Dev Ops Source control this can be over written by Fabric.
This makes no sense whatsoever.

Nobody so far has said that if you use an account with read only access in Dev Ops then it will neve get updated. That  surprises me. Just means it is a free for all now to mess up the code in source control.

[ells69]

If there is no way to ensure this is always one way from Source control -> Fabric then this is truly not going to be enabled ever 

[ibarrau]

Hi. That's not the way it works. PowerBi Service or Fabric is like another dev machine that will have changes to commit if you modify something. You should talk with the developers in order to prevent them doing actions over the portal. Keep regular users just as viewers. In case you do something from service that you regrest, remember that Git repos have version control history to roll back a previous version and prevent the change.

I hope that helps,

[ells69]

Wow so you can not stop your source control from being changed! 
So any user can come into the workspace and if they have the relevant permission then they can just change the reports and update the source control. 
I see this as a bad accident waiting to happen. If a user changes the reprort in workspace A they can update the source control. Then users in Workspace B and Workspace C just pull through the changes. That means all three environments can get trashed.
Surely you can disable write back to source control?

[ibarrau]

I don't think it's an accident. If you give them permission you trust the user to work properly. You can prevent users syncronization, but I'm not sure how that will impact once you push a different version and syncroniza with changes a user has mande. Fabric admin can change this settings for a security group of people:

It might prevent change from going to Fabric to repo. I can't tell how that will impact when changes from the portal and from repo get together.

I hope that helps,

[ells69]

Surely that can not be so.
If the user that you use to link to Azure Dev Ops only has read permission then this is a way for him to ignore that and overwrite code under source control.
Sorry I struggle t obelieve that MS would be that bad that they do not check if the user ID used in workspace settings has the right to update in Azure Dev Ops Repository.
This seems like a gapping hole!

Sorry or the long rant but just dont see why they would let you override all of the security in your Azure Dev Ops.

If I make a change in VS Code  I can only push to Azure Dev Ops if I have permission to push. You are saying in Fabric if my accout is used to connect to Azure Dev Ops and I only have read permission then I can juts overwrite source control?

Why would anyone enable this if it can juist overwrite your source control with no control what so ever?