Confidential notes on an issue

It would be good to be able to mark an individual note within a wider issue as confidential. This could be used for a range of purposes, from collaborative drafting of a response to a difficult question in an issue, to making inline notes about security problems discovered in the course of an MR or issue discussion.

Thoughts? /cc @smcgivern

This would likely lead to user confusion and accidental disclosure of private info, I'd be opposed.

Yeah, this makes me nervous.

collaborative drafting of a response to a difficult question in an issue

We can just use a confidential issue for that, or even Slack / Google Docs!

making inline notes about security problems discovered in the course of an MR or issue discussion

I think the MR discussion point is useful. I'm not sure that it's useful enough to outweigh @connorshea's concerns though. Plus, if it is a security issue that is important to keep private, we'll need to create a new issue and an MR on dev anyway.

Thanks for the feedback @smcgivern @connorshea. While we can always jump to third-party tools or separate issues, it'd be nicer if we didn't have to.

I'm fairly used to this feature in tools like RT; accidental disclosure is certainly a concern, but one that thoughtful UI could overcome. The existing 'confidential issue' notifications are quite subtle by comparison (RT has comments and replies, comments get a yellow background in the text box, replies a RED BACKGROUND).

Would this be less scary if we called it a 'draft' note?

I also think we should consider the possible problems this would introduce with regards to cacheability of the page.

@nick.thomas I've not used RT much, but my perception has always been that it's a much more 'heavyweight' issue tracker than GitLab Issues. Could you describe how you see this working a bit more?

Would this be less scary if we called it a 'draft' note?

We save 'draft' notes in local storage, until you submit them. If you want one to collaborate on in private - that seems like a better fit for https://gitlab.com/gitlab-org/gitlab-ce/issues/4199 combined with a confidential issue.

Added ~874211 label

@smcgivern FWIW zendesk has the same functionality.

The use case this came up in was the gitlab-ci-multi-runner repository, where support requests are often handled. A user asks a question, I draft a response, but need to check a few aspects of it before the issue author sees it.

I can either save it as a draft/confidential note, ccing another person to check it, or I can jump onto slack or another medium to ping them - or even create a separate confidential issue, I guess (I expect nobody would ever do that, the workflow overhead is too high).

It just feels natural to me to be able to say 'only team members can see this note'.

There are no caching concerns that I'm aware of, as note text is cached per note, so it's just a matter of eliding confidential ones if you don't have access.

@nick.thomas Zendesk does ... but is more explicitly a support thing.

I guess I see why these are useful for support requests, but I'm not sure they're that useful for other types of issues. Maybe this is just a lack of imagination on my part, though

In essence, I agree with:

While we can always jump to third-party tools or separate issues, it'd be nicer if we didn't have to.

While wanting to avoid:

Every program attempts to expand until it can read mail.

There are no caching concerns that I'm aware of, as note text is cached per note, so it's just a matter of eliding confidential ones if you don't have access.

We might want to cache issue pages at some point in the future, I guess? Although we could only do that for users without access to see the confidential notes anyway, so I think this is probably accurate

mentioned in issue #25891 (closed)

mentioned in issue #27034 (closed)

Just propose sam feature here https://gitlab.com/gitlab-org/gitlab-ce/issues/27034 :). Main idea(from my side) came from GitHub missing features. I noticed that this feature is requested from the maintainers of large OS projects.

That being said, I can understand concerns that @connorshea and @smcgivern are having, since it will not be an easy change in the source code. Caching, api and even already existing code for notes should be refactored(to put this in) :)

I guess it really depends from person to person. Someone likes having everything in one app(space) someone likes using integrations with multiple apps. I'm in the first bucket :)

mentioned in issue #27590 (moved)

I love this idea, I proposed it a year ago (could not find an issue, but nobody wanted this feature either). I noticed also that I often need my private comments for the issue that only I can see. It can be some concerns or useful links that only me interested in.

I found my issue https://gitlab.com/gitlab-org/gitlab-ee/issues/418

mentioned in issue #29208 (closed)

@victorwu please take a look if it's something we can accept if it's implemented by the community (like https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8698).

assigned to @victorwu

@smcgivern : Do you have any problems with this now (compared with your previous comments)? So would this exactly be now applicable to service desk? I.e. if you write a confidential comment, it wouldn't be sent back to the outside support request originator?

I would like this (at least to support the service desk use case). Looking at the MR, is the only user-facing change a checkbox and a different color for the comment background? Could we make the design a bit more blatant to avoid user errors given the costs of making a mistake in these scenarios?

@smcgivern : If you have no problems with the feature, let's get UX to give us a good design.

@victorwu I think that if Service Desk is the main use for this, we should see how it goes first. I still agree with https://gitlab.com/gitlab-org/gitlab-ce/issues/23436#note_17279800, in other words

@smcgivern here are 2 example use cases!

Company by name Sauron has 5 developers in house and they are using GitLab to manage their todos and tasks (development). Company hires freelances to help on some feature X.

Freelancer creates MR.....Sauron developers want to comment something privately so freelancer can't see this :)

---

Managing opens source project on GitLab.

For example Rails is on GitLab not on Github :).

I create Rails MR....Rails team wants to discuss it privately on the MR...so they don't need to use separate communication channels

@dixpac does GitHub have confidential comments? I didn't think they even had confidential issues.

I also think the scope of this feature request is currently limited to issues

@smcgivern they don't....but its heavily requested feature here https://github.com/arthurnn/meta/issues/22 :)

mentioned in issue #30175 (moved)

changed milestone to %Backlog

removed milestone

changed milestone to %Next 2-3 months

@ChadMalchow @aolson @klawrence : If we create this feature (or something similar to it), do you think the sales / marketing / customer success teams would actually use it?

I find that it's really hard to communicate potential customer impact for features. We create separate confidential issues in other projects. And we link to Salesforce. But if we can have everything inline within an issue, but be able to chat about it safely, it could be very powerful imo. Thoughts?

For example, we could create a "thread", just like this one I'm creating now, and it could be private. Or maybe have some other UI that separates it apart from the rest of the public part of the issue.

cc @JobV

I think this sounds very interesting and can improve the internal communication we have. Need more education on how you see this workflow but I am supportive of exploring. Anything that better aligns and seamlessly links systems together (like zendesk, issues and salesforce) I am supportive of. @victorwu

Thanks @ChadMalchow . I think we should do more exploration and involve those teams in the discussion if we were to proceed. Confidential comments is just one way. But there might be something easier to build or something more effective. Let's explore here: https://gitlab.com/gitlab-org/gitlab-ee/issues/3445.

moved to gitlab#6659

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue