Ability to disable the Download a Copy of the repo button

@Apophis775 Do you have HTTP disabled in your "Enabled Git Access Protocols" for your instance?

Do you think that this button is something that should be disabled if SSH only Git Access is configured?

added ~480950 ~14213 ~155949 labels

I don't seem to have that. This might be in the wrong place, we are using GitLab.com not GitLab community. Sorry about this. Is there a way to transfer this issue to the gitlab.com area or should I make a new one?

My concern, was the someone who just logs into it via the web interface, could click this button: https://imgur.com/a/DYnro

and then just bypass needing SSH to get the repo, making it redundant when the goal for us (at least) using SSH is an extra layer to protect out repo from theft.

@Apophis775 It's an instance wide setting so you won't see it if you're using GitLab.com. The Download button will be available to anyone with an access role above Developer if the project is private. For a public project, that button will be available to anyone.

I still think that the issue belongs here for discussion

@Apophis775 surely if someone has compromised an account (2FA anybody?) then they have access to the code via the GitLab ui anyway. I understand that the download button makes it a bit easier to access the entire repo, but removing it is effectively just "security through inconvenience".

I removed download button by editing the source haml code in /opt/gitlab/embedded/service/gitlab-rails/app/views/projects/buttons/_download.html.haml

Before:

- pipeline = local_assigns.fetch(:pipeline) { project.pipelines.latest_successful_for(ref) }

- if !project.empty_repo? && can?(current_user, :download_code, project)
  .project-action-button.dropdown.inline>
    %button.btn.has-tooltip{ title: s_('DownloadSource|Download'), 'data-toggle' => 'dropdown', 'aria-label' => s_('DownloadSource|Download') }
      = icon('download')
      = icon("caret-down")
      %span.sr-only=  _('Select Archive Format')
    %ul.dropdown-menu.dropdown-menu-align-right{ role: 'menu' }
      %li.dropdown-header
        #{ _('Source code') }
      %li
        = link_to archive_project_repository_path(project, ref: ref, format: 'zip'), rel: 'nofollow', download: '' do
          %i.fa.fa-download
          %span=  _('Download zip')
      %li
        = link_to archive_project_repository_path(project, ref: ref, format: 'tar.gz'), rel: 'nofollow', download: '' do
          %i.fa.fa-download
          %span= _('Download tar.gz')
      %li
        = link_to archive_project_repository_path(project, ref: ref, format: 'tar.bz2'), rel: 'nofollow', download: '' do
          %i.fa.fa-download
          %span= _('Download tar.bz2')
      %li
        = link_to archive_project_repository_path(project, ref: ref, format: 'tar'), rel: 'nofollow', download: '' do
          %i.fa.fa-download
          %span= _('Download tar')

      - if pipeline
        - artifacts = pipeline.builds.latest.with_artifacts
        - if artifacts.any?
          %li.dropdown-header Artifacts
          - unless pipeline.latest?
            - latest_pipeline = project.pipeline_for(ref)
            %li
              .unclickable= ci_status_for_statuseable(latest_pipeline)
            %li.dropdown-header Previous Artifacts
          - artifacts.each do |job|
            %li
              = link_to latest_succeeded_project_artifacts_path(project, "#{ref}/download", job: job.name), rel: 'nofollow', download: '' do
                %i.fa.fa-download
                %span
                  #{ s_('DownloadArtifacts|Download') } '#{job.name}'

After:

- pipeline = local_assigns.fetch(:pipeline) { project.pipelines.latest_successful_for(ref) }

- if !project.empty_repo? && can?(current_user, :download_code, project)
  .project-action-button.dropdown.inline>
    %button.btn.has-tooltip{ title: s_('DownloadSource|Download'), 'data-toggle' => 'dropdown', 'aria-label' => s_('DownloadSource|Download') }
      = icon('download')
      = icon("caret-down")
      %span.sr-only=  _('Select Archive Format')
    %ul.dropdown-menu.dropdown-menu-align-right{ role: 'menu' }

      - if pipeline
        - artifacts = pipeline.builds.latest.with_artifacts
        - if artifacts.any?
          %li.dropdown-header Artifacts
          - unless pipeline.latest?
            - latest_pipeline = project.pipeline_for(ref)
            %li
              .unclickable= ci_status_for_statuseable(latest_pipeline)
            %li.dropdown-header Previous Artifacts
          - artifacts.each do |job|
            %li
              = link_to latest_succeeded_project_artifacts_path(project, "#{ref}/download", job: job.name), rel: 'nofollow', download: '' do
                %i.fa.fa-download
                %span
                  #{ s_('DownloadArtifacts|Download') } '#{job.name}'

@Apophis775

A more simple solution is just adding false to end of the third line as below.

- if !project.empty_repo? && can?(current_user, :download_code, project) && false

I have tested and it works fine!

Note that this line will always be false because it's a logical and, which is only true if all terms are true. This is basically a very long way to write "the following code will never run" =)

added Create [DEPRECATED] label

@idododu - Thanks for the above help. I have also made same changes but i guess its not working for me.

Question: Is there anything i need to do after making these changes (like compile or reconfigure gitlab), if yes how to do that ?

can anybody help my find the function while refers below? if !project.empty_repo? && can?(current_user, :download_code, project)

is that saved in the database or some configuration files?

I can then make a specific person/group have download permissions

thanks

added devopscreate label

added [deprecated] Accepting merge requests label

added groupsource code label

removed [deprecated] Accepting merge requests label

ZD: https://gitlab.zendesk.com/agent/tickets/133494 (internal use only)

added customer label

Link to request:
- https://gitlab.my.salesforce.com/0014M00001lb3Cg
- https://gitlab.my.salesforce.com/0014M00001kH4By?srPos=0&srKp=001
Why interested:
- Customers are outsourcing development work to outside teams and would like to ensure that their intellectual property is secure. Customers would like to grant permissions to the outside development team, but prevent developers from downloading,cloning, or forking source code.
Current solution for this problem:
- Rely on third party DLP (Data Loss Prevention) service integrations (netskope, etc)
- Infra architecture (secure bashion/VDS solution,AWS workspaces)
- Reliant on NDA's, License compliance
How important to them:
- Very important as this is high impact. Would like to know how other GitLab customers are working around these needs/requirements today (other than whats listed)

cc: @jramsay

@jeffersonj I'm a little confused. Even if the download button is disabled, they can still download it via Git using the Git URL if they have developer permissions?

@jramsay indeed, The current permission model and workflow of the product perhaps does not support this today. I also understand that this is a small piece to the overall goal based on the customer feedback received. Perhaps the proposal belongs in a new issue or epic, happy to create. The overall goal would be to prevent outside developers the ability to download/fork/or clone source code and perhaps a solution would be to force use of the built in webide to allow for code changes, but all within the UI. I am happy to setup a meeting with the customers for additional information and context.

@jeffersonj could you create a new issue with the overarching problem, and what the desired outcome is. I don't understand how a developer can do anything if they don't have access to any of the source code. If a company hires me as an external contracter, I need to be able to see the source code if I am going to contribute improvements. If I can't download the source code and open it in my editor how would I be expected to do my job?

@jramsay Thanks for the review. I will create a new issue regarding the request and provide additional context.

mentioned in issue #215814 (closed)

mentioned in issue #216409 (closed)

mentioned in issue #217268 (closed)

mentioned in issue #218187 (closed)

mentioned in issue #218929 (closed)

mentioned in issue #219682 (closed)

mentioned in issue #220716 (closed)

mentioned in issue #222216 (closed)

mentioned in issue #223635 (closed)

mentioned in issue #225116 (closed)

mentioned in issue #226943 (closed)

mentioned in issue #230641 (closed)

mentioned in issue #232363 (closed)

This would also be helpful for repositories that use Git LFS, since the source code links won't resolve LFS files and the resulting ZIP file will be invalid.

added sectiondev label

mentioned in issue gitlab-org/quality/triage-reports#1434 (closed)

added [deprecated] Accepting merge requests label

This would also be useful for repos that are "open source but not free-for-all contribution", where the maintainers have disabled forking in the repo settings, to prevent meaningless/spurious copies from floating around.

While the clone mechanism inherent to git still allows folks to copy the code, the act of cloning a repo by running a git clone requires quite a bit of intentful effort, whereas having a one-click download option makes this zero-effort. Letting folks toggle a switch in the repo settings that removes that option, in the same way we can already turn off one-click forking, would make a whole lot of sense.

mentioned in issue gitlab-org/quality/triage-reports#1877 (closed)

mentioned in issue gitlab-org/quality/triage-reports#1985 (closed)

mentioned in issue gitlab-org/quality/triage-reports#2050 (closed)

mentioned in issue gitlab-org/quality/triage-reports#2144 (closed)

mentioned in issue gitlab-org/quality/triage-reports#2261 (closed)

mentioned in issue gitlab-org/quality/triage-reports#2336 (closed)

mentioned in issue gitlab-org/quality/triage-reports#2403 (closed)

mentioned in issue gitlab-org/quality/triage-reports#2503 (closed)

mentioned in issue gitlab-org/quality/triage-reports#2569 (closed)

This would be a nice feature to have.

Example setup:

Disable HTTPS Git access (already a feature).
Use firewall rules to restrict SSH access to the GitLab server.
Remove the download button.

In this setup, the only way the entire repo could be cloned/copied in a single-click is to clone via SSH. The firewall rules could be used to (almost) ensure the clone is going to a "trusted" device. Of course, the user could download to an untrusted device from there... but, at least we aren't suggesting it by providing a button to do so. Perhaps auditing tools could be installed on the trusted device, or even more (cumbersome) security measures.

You've provided a feature to disable HTTPS/SSH Git access... this seems almost like an extension of that.

well kind of but not really. we have a jumpbox all users are only allowed access to commit / checkout from that device. We still however would like them to be able to use the web ui to view projects, without being able to download code via the web, basically. We restricted gitlab ssh to the single jumpbox host. so being able to clone via ssh is fine, but we dont want them to be able to download files, or clone via https, since we cannot restrict https top the jump box as it is a shell system. we must allow https to all users ip on the vpn.

Hi @outbackdingo, sorry to say this, but that still sounds kinda sketchy. Do you know that one could as well just tunnel through the jump box or use UI automation tools to fetch the whole codebase using the UI? As long as one can get it on their screens, there is a way to exfiltrate/steal it entirely. And people that want to actually steal it will use one of the nonobvious ways to do it because they don't want it to be logged either...

It looks more like you need more trustworthy developers... There is no solution to not trusting your people. The ways around such a limitation are endless. And at the end of the day, it only hurts those with legitimate interests in using such a feature.

I think such a feature would only provide a false sense of protection. And will lead to a worse user experience.

If you really fear someone stealing your codebase, here are things that actually help without hurting all needing it for legitimate interests:

Get an NDA with your developers that lists exactly what they're allowed to reuse/keep for other projects.
Split your codebase into multiple repositories and make sure that nobody has access to more than the ones they need.
Fire the non-trustworthy developers and hire trustworthy ones instead. If you cannot trust your developers you have much bigger problems than them stealing your code...
Create a good working environment, what you're currently trying to do looks extremely like cornerstones of a toxic and micromanaged working environment. The good developers won't stay there for long and you'll be left with all the shitty and non-trustworthy ones...
Put the GitLab webserver logs into a siem and classify this activity as high-risk, and get alerts about it. But as I said you most likely only catch the legitimate interests. Like people making a copy to try doing a risky merge or to fix a broken git checkout...

We have done all of the above and I'm not the one who "ordered" it.... :) I think the object is to prevent all code from leaving the company, prevent loss by theft/loss of personal/business laptops and to make it more difficult for someone to download the whole repo, or parts thereof for varied reasons.

...

On Thu, Nov 25, 2021 at 3:46 PM Klaus Frank (@agowa338) gitlab@mg.gitlab.com wrote:

Klaus Frank commented:

Hi @outbackdingo, sorry to say this, but that still sounds kinda sketchy. Do you know that one could as well just tunnel through the jump box or use UI automation tools to fetch the whole codebase using the UI? As long as one can get it on their screens, there is a way to exfiltrate/steal it entirely. And people that want to actually steal it will use one of the nonobvious ways to do it because they don't want it to be logged either...

It looks more like you need more trustworthy developers... There is no solution to not trusting your people. The ways around such a limitation are endless. And at the end of the day, it only hurts those with legitimate interests in using such a feature.

I think such a feature would only provide a false sense of protection. And will lead to a worse user experience.

If you really fear someone stealing your codebase, here are things that actually help without hurting all needing it for legitimate interests:

Get an NDA with your developers that lists exactly what they're allowed to reuse/keep for other projects. Split your codebase into multiple repositories and make sure that nobody has access to more than the ones they need. Fire the non-trustworthy developers and hire trustworthy ones instead. If you cannot trust your developers you have much bigger problems than them stealing your code... Create a good working environment, what you're currently trying to do looks extremely like cornerstones of a toxic and micromanaged working environment. The good developers won't stay there for long and you'll be left with all the shitty and non-trustworthy ones... Put the GitLab webserver logs into a siem and classify this activity as high-risk, and get alerts about it. But as I said you most likely only catch the legitimate interests. Like people making a copy to try doing a risky merge or to fix a broken git checkout...

— Reply to this email directly or view it on GitLab. You're receiving this email because you have been mentioned on gitlab.com. If you'd like to receive fewer emails, you can unsubscribe from this thread or adjust your notification settings.

mentioned in issue #371702

@tlinz Can I ask whether Upstream would accept JiHu to contribute to this feature? Our idea is to add a feature flag or a rails console command to disable this "Download" button.

Hi @lpeng1991, I appreciate that you want to contribute.

However, in my opinion, this feature would not substantially improve the security as one could still download the file via the UI one by one with a web scraper. However, it would lead to a bad developer experience when turned on by the admin. So, it is harming those with good intentions and only makes the lives of those with bad intentions slightly more uncomfortable.

In my opinion, we have two features that do contribute to making the download button less problematic than this issue suggests:

Admins can require 2FA to log in to the UI.
Admins can limit access to only certain IP addresses.

So I think we should not implement this feature.

Let me add @stkerr for a second opinion.

Its nkt designed to be a "security" feature, its designed to be a limiting factor of remote git tree cloning, we determined rhat all code should only be checked out from cli on a jump station, this button prevents it being downloaded to a remote desktop.

...

On Tue, Sep 27, 2022, 8:53 PM Torsten Linz (@tlinz) gitlab@mg.gitlab.com wrote:

Torsten Linz https://gitlab.com/tlinz commented on a discussion #17032 (comment 1116148497):

In my opinion, this feature would not substantially improve the security as one could still download the file via the UI one by one with a web scraper. However, it would lead to a bad developer experience when turned on by the admin. So, it is harming those with good intentions and only makes the lives of those with bad intentions slightly more uncomfortable.

In my opinion, we have two features that do contribute to making the download button less problematic than this issue suggests:

Admins can require 2FA https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html to log in to the UI.

Admins can limit access to only certain IP addresses https://docs.gitlab.com/ee/user/group/access_and_permissions.html#restrict-group-access-by-ip-address .

So I think we should not implement this feature.

Let me add @stkerr https://gitlab.com/stkerr for a second opinion.

— Reply to this email directly or view it on GitLab #17032 (comment 1116148497). You're receiving this email because of your account on gitlab.com. Unsubscribe https://gitlab.com/-/sent_notifications/REDACTED/unsubscribe from this thread · Manage all notifications https://gitlab.com/-/profile/notifications · Help https://gitlab.com/help

@lpeng1991 @tlinz in general, we don't block contributions folks want to make, so if your users would find value in it, I don't see an issue with us merging a feature flag to disable it. I don't foresee us utilizing this on GitLab.com at any point. I agree with Torsten though that I'm not sure if this would actually solve the need, since it would still be possible to retrieve the code.

Note that having this feature would be also very beneficial without any security issues in mind! In particular, it would prevent the following situation:

Download a tarball of the git repository (using the button).
Immediately try to build the software from there, which might fail for various reasons.

A typical reason for a failed build is a missing configure script, which must be first created with a call to ./autogen.sh, and which needs other tools not necessary if you download a 'real' tarball. In general, 'good' repositories don't contain generated files (or as little as possible), while a source code tarball has all those files.

@tlinz @stkerr Thanks for your opinion.

From JiHu side, we have seen customer cases doing this via editing the source code, so we most likely will try to implement this feature.

We will investigate the problems of implementing this in Jihu-only approach, and maybe come to you later

Hi @lpeng1991,

as @stkerr wrote, we don't block contributions. So feel free and invited to contribute it to GitLab. You don't have to go the route of implementing it as Jihu-only feature.

Out of curiosity, those customers that edited the source code to suppress the button, what is their use case?

@tlinz We have customers scenario that they only allow employees to pull codes via git client and can install tools to monitor operations from git client. Then the download operations from the web UI is sth out of their control.

Customers with such strict compliance are actually looking for more fine-grained access control to the repository function, which currently GitLab cannot provide. So they will implement external tools to help achieve that.

@lpeng1991 As @Taucher2003 mentioned here, are we considering incorporating project level switches into this feature?

From the customer requirements that I received, they all want to disable it at instance-level?

So I think group-level and project-level implementation could be further MVC based on customer feedbacks.

/cc @tlinz

@tlinz @stkerr @lpeng1991 I have strong concerns about two UX aspects of this proposal.

Viability of just hiding the download button

As multiple others have already written, there are already multiple ways that users can circumvent this. When we are introducing the VS Code Web IDE, we will actually make that even easier for them, they can just select hit CMD + a and click on "Download" to get all files.

Even if we were to also disable that as well, the next problem would already come with remote development, where users would have access to a terminal, where they could e.g. easily zip all files and just download the zip file.

With so many different easy workarounds already being brought up in this issue alone, just hiding the download button feels a lot like security theater. If the compliance problems mentioned above are the reason for developing this feature, we could actually be creating problems for these companies, as we would be communicating a wrong sense of security to customers with this half-baked solution, leading to them still being in violation of their compliance guidelines without knowing about it.

/cc @ericschurter

Feature flag to hide UI elements

I'm strongly against using feature flags to control specific UI elements. Feature flags should not be used as a long-term strategy to give customers different UIs, and our documentation is very clear on this https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#the-benefits-of-feature-flags:

If we use Feature Flags as a configuration, we are doing it wrong and are indeed in violation of our principles. If something needs to be configured, we should intentionally make it configuration from the first moment.

Open questions

If the actual problem here are compliance guidelines, we need to first understand these better before we can make a call on what functionality we would need to restrict, and how much other functionality we would need to disable for these customers, e.g. would restricting download functionality automatically also disable remote development for these customers?

/cc @sarahwaldner As you were also involved in https://gitlab.com/gitlab-org/gitlab/-/issues/373752#note_1152910126, which seems like a very similar problem.

It feels like this yet again misses the point: yes, people can get the files in many ways, but why do they want to get those files:

they want to download a release. The download button is the absolute worst thing for them to click in that case.
they want to view the code. The download button is irrelevant, the code's right there for them to browse.
they want to work on the code themselves. Again, the download button's basically irrelevant because either they fork the project and work on the code using the web IDE or, if forking is turned off or they just want to work on it on their own computer, they're going to be using git anyway. Either manually in a terminal or by using editor plugins for working with git repositories.

In all of these cases, the download button might be a nice-to-have for some, but it's the kind of nice-to-have that adds nothing that wasn't already possible, and it would be great to be able to just --in the repo settings-- disable it. At best it doesn't improve on the methods that a user/contributor already has available, but at worst people think it's the button they need to click to get "the thing" instead of the source code, without reading the popout label, then end up with source that is detached from git and/or instructions on how to work with that source... And then they file issues asking why things don't work.

I have no idea why the download button even exists other than feature parity with competitors, but: just because I can't see a use-case for it doesn't mean there aren't any, so I for one wouldn't ask for it to be removed just because I don't need it. However, I can think of lots of use-cases in which presenting the user with a download button ranges from "adding no value" to "actually causing problems for code owners" so having a switch in the repo settings that lets us turn it off would be an excellent feature.

(If you want it removed for security reasons then yes: removing the download button is a waste of time, it buys you nothing. But as has been pointed out by quite a few people, that's not why a lot of folks want to disable it)

Reviewing this issue it looks like we'd benefit from stepping back and doing a little more problem validation.

Removing the download button doesn't actually prevent someone with access to the repo download the source code, and it sounds like some intent of this feature (for some folks) is to actually address a broader UX challenge. When "download" is misused by someone who intends to contribute (should have cloned) OR download a release (should be on /-/releases).

Before we proceed with this change let's have the PM team take a look at some validation to better understand the problems this change is intending to solve and see if we have the right solution(s) identified.

@hsutor I assume you agree from an Auth perspective there is no real access/control benefit of disabling the download button if the user already has repo access? Sounds like Jihu has some use cases that may not be addressed so it could be worth following up with @lpeng1991 to learn more.

@tlinz could you consider prioritizing some further validation work to understand if the download button is causing any anti-patterns? I can see why someone may mistake "Download" for Clone / Download a release, but honestly haven't seen that confusion firsthand myself. Could be worth a deeper dive.

@cbalane FYI something to consider here for Release discoverability. On GitHub for example there is a releases module that lets me quickly access the latest release. We don't have the equivalent so it could be confusing for someone who's used to how GitHub presents it.

FWIW I don't think we should merge this change without further validation work. I agree with @mvanremmerden concerns about merging this change as-is. That said this is a great starting point for further discussion on how to address these needs so thanks to all who have provided feedback/raised the issue.

FYI @sarahwaldner @uchetta @ogolowinski @vkarnes @clenneville

Thank you @justinfarris I agree we need more problem validation here.

Moreover, I want to point that adding the ability to disable a button also goes against convention over configuration and we need to strive to provide a default experience that solves majority of the problems faced by our users.

@mvanremmerden @sarahwaldner @justinfarris @Pomax @lemzwerg Thanks for your feedbacks. And JiHu side agrees to hold the contribution until further validation completed.

But please take into consideration of our customer scenario #17032 (comment 1120229142) in the discussion. Also, we have another feature issue related to this feature.

Thanks @lpeng1991 - @hsutor will consider that customer scenario in her implementation.

@lpeng1991 I reviewed the customer use case and I think it is best for groupsource code to have on their roadmap, not ~"group::authentication and authorization", because each individual team is in charge of the permissions related to their area. so @tlinz I want to make sure this customer request is not lost: #17032 (comment 1120229142)

@lpeng1991, this issue has very little customer demand. So it will be hard for me to prioritize discovery work on it. It seems to me that the security aspect of the ask is very questionable. I do see that @Pomax view could be more relevant if it turns out to be true that we send users into a dead end with this button. But this would need further research.

Looking at your specific case:

We have customers scenario that they only allow employees to pull codes via git client and can install tools to monitor operations from git client. Then the download operations from the web UI is sth out of their control.

If all they do is monitor, then maybe you could simply add log of the download activities - if that isn't already there. That would put the UI download activity on par with git clone activity.

cc: @sarahwaldner

As you agreed not to work on it for now, let me move this back to the backlog to avoid confusion.

@tlinz Also consider adding the won't do label and closing it if it is not in line with vision

Thanks. Let me do that. This was my first intuition after all.

@lpeng1991 please comment and reopen if you disagree.

removed Create [DEPRECATED] [deprecated] Accepting merge requests labels

assigned to @lpeng1991

Assigning @lpeng1991 to this issue and assuming a %15.6 target.

@lpeng1991 please ping me with any MR.

@sean_carroll We have an ongoing MR !101879 (closed)

@hannahstewart please see this issue being worked on by JiHu

It has overlap with Separate `view code` permission from `download ... (#376180 - closed)

@sean_carroll I just came across this and realized you tagged the wrong Hannah

Oh dear, thank you @hsutor

marked this issue as related to #376180 (closed)

changed milestone to %15.6

added JiHu contribution backend featureenhancement frontend labels

@tlinz JiHu is planning to implement this feature as a feature flag, is this solution acceptable or is there another good idea?

Removing the backend to get it off the GitLab backend teams planning board.

That's enouph for me, Thanks!

发自我的手机

-------- 原始邮件 -------- 发件人： "Torsten Linz (@tlinz)" gitlab@mg.gitlab.com 日期： 2022年10月18日周二晚上7:36 收件人： mengzawj@hotmail.com 主题： Re: GitLab | Ability to disable the Download a Copy of the repo button (#17032 (closed))

Torsten Linzhttps://gitlab.com/tlinz commented#17032 (comment 1139614192):

Removing the backendhttps://gitlab.com/gitlab-org/gitlab/-/issues?label_name=backend to get it off the GitLab backendhttps://gitlab.com/gitlab-org/gitlab/-/issues?label_name=backend teams planning board.

— Reply to this email directly or view it on GitLab#17032 (comment 1139614192). You're receiving this email because of your account on gitlab.comhttps://gitlab.com. Unsubscribehttps://gitlab.com/-/sent_notifications/REDACTED/unsubscribe from this thread · Manage all notificationshttps://gitlab.com/-/profile/notifications · Helphttps://gitlab.com/help

Sorry, if I wasn't clear. This might still be backend work but I wanted to remove the backend as we do the planning to prevent it from showing up in our planning board.

So nothing changes except that label.

removed backend label

mentioned in issue #378385

mentioned in merge request !101879 (closed)

mentioned in merge request !103147 (merged)

changed milestone to %15.7

added missed:15.6 label

This work will need documentation, so I'm adding documentation, docsfeature, and Technical Writing labels.

added Technical Writing docsfeature documentation labels

changed milestone to %15.8

added missed:15.7 label

changed milestone to %Backlog

closed

added won't do label

mentioned in merge request gitlab-com/www-gitlab-com!119087 (merged)

Ability to disable the Download a Copy of the repo button

Description

Proposal

Links / references

Designs

Child items ...

Activity

Viability of just hiding the download button

Feature flag to hide UI elements

Open questions

Ability to disable the Download a Copy of the repo button

Description

Proposal

Links / references

Relates to

Activity

Viability of just hiding the download button

Feature flag to hide UI elements

Open questions