diff --git a/app/assets/javascripts/notes/components/noteable_discussion.vue b/app/assets/javascripts/notes/components/noteable_discussion.vue
index 1f31720ff406f44f026d52cd58a2fded33636297..3462ee72dd3947904871a9c899756e2278f7ea9a 100644
--- a/app/assets/javascripts/notes/components/noteable_discussion.vue
+++ b/app/assets/javascripts/notes/components/noteable_discussion.vue
@@ -89,6 +89,9 @@ export default {
currentUser() {
return this.getUserData;
},
+ isLoggedIn() {
+ return Boolean(gon.current_user_id);
+ },
autosaveKey() {
return getDiscussionReplyKey(this.firstNote.noteable_type, this.discussion.id);
},
@@ -314,7 +317,7 @@ export default {
@cancelForm="cancelReplyForm"
/>
-
+
diff --git a/changelogs/unreleased/24190-archived-project-warning-message-on-discussion-thread.yml b/changelogs/unreleased/24190-archived-project-warning-message-on-discussion-thread.yml
new file mode 100644
index 0000000000000000000000000000000000000000..16f851e6bdb39b51b90d30a92edeb8d6b4ae529e
--- /dev/null
+++ b/changelogs/unreleased/24190-archived-project-warning-message-on-discussion-thread.yml
@@ -0,0 +1,5 @@
+---
+title: Display login or register widget only if user is not logged in
+merge_request: 22211
+author:
+type: fixed
diff --git a/doc/development/packages.md b/doc/development/packages.md
index 7ae3cd53e660296d560495a67c10a5fe5bb75eb0..4ea71afac800b2d54a73c5abb1a96547bc5bf8bc 100644
--- a/doc/development/packages.md
+++ b/doc/development/packages.md
@@ -110,7 +110,7 @@ File uploads should be handled by GitLab Workhorse using object accelerated uplo
the workhorse proxy that checks all incoming requests to GitLab will intercept the upload request,
upload the file, and forward a request to the main GitLab codebase only containing the metadata
and file location rather than the file itself. An overview of this process can be found in the
-[development documentation](uploads.md#workhorse-object-storage-acceleration).
+[development documentation](uploads.md#direct-upload).
In terms of code, this means a route will need to be added to the
[GitLab Workhorse project](https://gitlab.com/gitlab-org/gitlab-workhorse) for each level of remote being added
@@ -183,7 +183,7 @@ These changes represent all that is needed to deliver a minimally usable package
1. Empty file structure (API file, base service for this package)
1. Authentication system for 'logging in' to the package manager
1. Identify metadata and create applicable tables
-1. Workhorse route for [object storage accelerated uploads](uploads.md#workhorse-object-storage-acceleration)
+1. Workhorse route for [object storage direct upload](uploads.md#direct-upload)
1. Endpoints required for upload/publish
1. Endpoints required for install/download
1. Endpoints required for remove/delete
diff --git a/doc/development/uploads.md b/doc/development/uploads.md
index e3ff62f1d2f1a21be5e53306595f1c42d929e6dc..3eda06677536d043bbabf435e033bb910832463b 100644
--- a/doc/development/uploads.md
+++ b/doc/development/uploads.md
@@ -42,7 +42,7 @@ We have three challenges here: performance, availability, and scalability.
Rails process are expensive in terms of both CPU and memory. Ruby [global interpreter lock](https://en.wikipedia.org/wiki/Global_interpreter_lock) adds to cost too because the ruby process will spend time on I/O operations on step 3 causing incoming requests to pile up.
-In order to improve this, [workhorse disk acceleration](#workhorse-disk-acceleration) was implemented. With this, Rails no longer deals with writing uploaded files to disk.
+In order to improve this, [disk buffered upload](#disk-buffered-upload) was implemented. With this, Rails no longer deals with writing uploaded files to disk.
```mermaid
graph TB
@@ -76,13 +76,13 @@ graph TB
There's also an availability problem in this setup, NFS is a [single point of failure](https://en.wikipedia.org/wiki/Single_point_of_failure).
-To address this problem an HA object storage can be used and it's supported by [workhorse object storage acceleration](#workhorse-object-storage-acceleration)
+To address this problem an HA object storage can be used and it's supported by [direct upload](#direct-upload)
### Scalability
Scaling NFS is outside of our support scope, and NFS is not a part of cloud native installations.
-All features that require Sidekiq and do not use object storage acceleration won't work without NFS. In Kubernetes, machine boundaries translate to PODs, and in this case the uploaded file will be written into the POD private disk. Since Sidekiq POD cannot reach into other pods, the operation will fail to read it.
+All features that require Sidekiq and do not use direct upload won't work without NFS. In Kubernetes, machine boundaries translate to PODs, and in this case the uploaded file will be written into the POD private disk. Since Sidekiq POD cannot reach into other pods, the operation will fail to read it.
## How to select the proper level of acceleration?
@@ -90,9 +90,9 @@ Selecting the proper acceleration is a tradeoff between speed of development and
We can identify three major use-cases for an upload:
-1. **storage:** if we are uploading for storing a file (i.e. artifacts, packages, discussion attachments). In this case [object storage acceleration](#workhorse-object-storage-acceleration) is the proper level as it's the less resource-intensive operation. Additional information can be found on [File Storage in GitLab](file_storage.md).
-1. **in-controller/synchronous processing:** if we allow processing **small files** synchronously, using [disk acceleration](#workhorse-disk-acceleration) may speed up development.
-1. **Sidekiq/asynchronous processing:** Async processing must implement [object storage acceleration](#workhorse-object-storage-acceleration), the reason being that it's the only way to support Cloud Native deployments without a shared NFS.
+1. **storage:** if we are uploading for storing a file (i.e. artifacts, packages, discussion attachments). In this case [direct upload](#direct-upload) is the proper level as it's the less resource-intensive operation. Additional information can be found on [File Storage in GitLab](file_storage.md).
+1. **in-controller/synchronous processing:** if we allow processing **small files** synchronously, using [disk buffered upload](#disk-buffered-upload) may speed up development.
+1. **Sidekiq/asynchronous processing:** Async processing must implement [direct upload](#direct-upload), the reason being that it's the only way to support Cloud Native deployments without a shared NFS.
For more details about currently broken feature see [epic &1802](https://gitlab.com/groups/gitlab-org/-/epics/1802).
@@ -122,7 +122,7 @@ By uploading technologies we mean how all the involved services interact with ea
GitLab supports 3 kinds of uploading technologies, here follows a brief description with a sequence diagram for each one. Diagrams are not meant to be exhaustive.
-### Regular rails upload
+### Rack Multipart upload
This is the default kind of upload, and it's most expensive in terms of resources.
@@ -148,7 +148,7 @@ sequenceDiagram
deactivate w
```
-### Workhorse disk acceleration
+### Disk buffered upload
This kind of upload avoids wasting resources caused by handling upload writes to `/tmp` in rails.
@@ -202,7 +202,7 @@ sequenceDiagram
end
```
-### Workhorse object storage acceleration
+### Direct upload
This is the more advanced acceleration technique we have in place.
@@ -212,9 +212,8 @@ In this setup an extra rails route needs to be implemented in order to handle au
you can see an example of this in [`Projects::LfsStorageController`](https://gitlab.com/gitlab-org/gitlab/blob/cc723071ad337573e0360a879cbf99bc4fb7adb9/app/controllers/projects/lfs_storage_controller.rb)
and [its routes](https://gitlab.com/gitlab-org/gitlab/blob/cc723071ad337573e0360a879cbf99bc4fb7adb9/config/routes/git_http.rb#L31-32).
-NOTE: **Note:**
-This will fall back to _Workhorse disk acceleration_ when object storage is not enabled
-in the GitLab instance. The answer to the `/authorize` call will only contain a file system path.
+**note:** this will fallback to _disk buffered upload_ when `direct_upload` is disabled inside the [object storage setting](../administration/uploads.md#object-storage-settings).
+The answer to the `/authorize` call will only contain a file system path.
```mermaid
sequenceDiagram
@@ -262,11 +261,3 @@ sequenceDiagram
deactivate sidekiq
end
```
-
-## What does the `direct_upload` setting mean?
-
-[Object storage setting](../administration/uploads.md#object-storage-settings) allows instance administators to enable `direct_upload`, this in an option that only affects the behavior of [workhorse object storage acceleration](#workhorse-object-storage-acceleration).
-
-This option affect the response to the `/authorize` call. When not enabled, the API response will not contain presigned URLs and workhorse will write the file the shared disk, on the path is provided by rails, acting like object storage was disabled.
-
-Once the request reachs rails, it will schedule an object storage upload as a Sidekiq job.
diff --git a/spec/javascripts/notes/components/noteable_discussion_spec.js b/spec/javascripts/notes/components/noteable_discussion_spec.js
index 5e359759afc28a5d1c5fb7851dfece9c81bf36bd..3151fb38a10b473c5c87b0ae11333fe90d8ba0e8 100644
--- a/spec/javascripts/notes/components/noteable_discussion_spec.js
+++ b/spec/javascripts/notes/components/noteable_discussion_spec.js
@@ -5,8 +5,15 @@ import ReplyPlaceholder from '~/notes/components/discussion_reply_placeholder.vu
import ResolveWithIssueButton from '~/notes/components/discussion_resolve_with_issue_button.vue';
import NoteForm from '~/notes/components/note_form.vue';
import '~/behaviors/markdown/render_gfm';
-import { noteableDataMock, discussionMock, notesDataMock } from '../mock_data';
+import {
+ noteableDataMock,
+ discussionMock,
+ notesDataMock,
+ loggedOutnoteableData,
+ userDataMock,
+} from '../mock_data';
import mockDiffFile from '../../diffs/mock_data/diff_file';
+import { trimText } from '../../helpers/text_helper';
const discussionWithTwoUnresolvedNotes = 'merge_requests/resolved_diff_discussion.json';
@@ -15,6 +22,7 @@ const localVue = createLocalVue();
describe('noteable_discussion component', () => {
let store;
let wrapper;
+ let originalGon;
preloadFixtures(discussionWithTwoUnresolvedNotes);
@@ -167,4 +175,55 @@ describe('noteable_discussion component', () => {
expect(button.exists()).toBe(true);
});
});
+
+ describe('signout widget', () => {
+ beforeEach(() => {
+ originalGon = Object.assign({}, window.gon);
+ window.gon = window.gon || {};
+ });
+
+ afterEach(() => {
+ wrapper.destroy();
+ window.gon = originalGon;
+ });
+
+ describe('user is logged in', () => {
+ beforeEach(() => {
+ window.gon.current_user_id = userDataMock.id;
+ store.dispatch('setUserData', userDataMock);
+
+ wrapper = mount(localVue.extend(noteableDiscussion), {
+ store,
+ propsData: { discussion: discussionMock },
+ localVue,
+ sync: false,
+ });
+ });
+
+ it('should not render signed out widget', () => {
+ expect(Boolean(wrapper.vm.isLoggedIn)).toBe(true);
+ expect(trimText(wrapper.text())).not.toContain('Please register or sign in to reply');
+ });
+ });
+
+ describe('user is not logged in', () => {
+ beforeEach(() => {
+ window.gon.current_user_id = null;
+ store.dispatch('setNoteableData', loggedOutnoteableData);
+ store.dispatch('setNotesData', notesDataMock);
+
+ wrapper = mount(localVue.extend(noteableDiscussion), {
+ store,
+ propsData: { discussion: discussionMock },
+ localVue,
+ sync: false,
+ });
+ });
+
+ it('should render signed out widget', () => {
+ expect(Boolean(wrapper.vm.isLoggedIn)).toBe(false);
+ expect(trimText(wrapper.text())).toContain('Please register or sign in to reply');
+ });
+ });
+ });
});