GitLab issueshttps://gitlab.com/gitlab-org/gitlab/-/issues2020-08-14T15:38:56Zhttps://gitlab.com/gitlab-org/gitlab/-/issues/27290Determine best way to track the moment where full Vue apps are setup2020-08-14T15:38:56ZAndré Luísaluis@gitlab.comDetermine best way to track the moment where full Vue apps are setup### Problem to solve
Currently the performance testing is checking times available through the Timings API:
![Screen_Shot_2019-03-08_at_09.53.14](/uploads/cbee5f94b983064e8742cf79763fafb7/Screen_Shot_2019-03-08_at_09.53.14.png)
We mig...### Problem to solve
Currently the performance testing is checking times available through the Timings API:
![Screen_Shot_2019-03-08_at_09.53.14](/uploads/cbee5f94b983064e8742cf79763fafb7/Screen_Shot_2019-03-08_at_09.53.14.png)
We might want to track also moments after DOMready and even after `window.onload`.
We should find a way to track this globally on several pages but do it in a generic way, to not have to update the performance tests every time we have a new app
We can focus this effort on the MR page example but keep a generic approach.
### Intended users
Developers that develop and make use of the performance automated testing.
### Further details
Context: https://gitlab.com/groups/gitlab-org/-/epics/805
### Proposal
Thinking of having a generic custom event that multiple Vue apps can use to record the moment the full app is setup in a global object so that the performance test script can check that like it does for the timing API.
Question: is one event enough? Should we track several moments and have the performance tool calculate deltas between them? Or leave that for a later improvement?
### What does success look like, and how can we measure that?
Able to identify when an MR worsens the overall perceived performance or Time to Interaction with a full-fledged Vue app.
### Links / referencesBacklogAndré Luísaluis@gitlab.comAndré Luísaluis@gitlab.comhttps://gitlab.com/gitlab-org/gitlab/-/issues/26950Docs: document the difference between the admin user and the server admin2020-08-14T15:39:43ZMarcia RamosDocs: document the difference between the admin user and the server admin### Type of issue
There are 2 types of GitLab admin users:
- "Admin user": the user who has admin permissions for a given GL instance. Logs into the instance via UI and has access to the admin area.
- "Server admin": the user who has a...### Type of issue
There are 2 types of GitLab admin users:
- "Admin user": the user who has admin permissions for a given GL instance. Logs into the instance via UI and has access to the admin area.
- "Server admin": the user who has access to the instance administration via server. Has access to `gitlab.rb` and other admin files not accessible from the UI.
### Problem to solve
Document the difference between the users, clarify who has access to what.
### Further details
Example: the [customization](https://docs.gitlab.com/ee/customization/) settings are accessible for users with admin privilegdes, from the UI. But only the server admin can [update and `reconfigure`](https://docs.gitlab.com/ee/administration/restart_gitlab.html#omnibus-gitlab-reconfigure) GL.
### Proposal
Document this either on https://docs.gitlab.com/ee/user/admin_area/ or https://docs.gitlab.com/ee/administration/ and crosslink both docs.
### Who can address the issue
@gl\-docsteam (either of us)
### Other links/references
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9601#note_144121743Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/26500Mailing list: add model and UI for mailing list settings2021-05-10T00:30:11ZJan Provaznikjprovaznik@gitlab.comMailing list: add model and UI for mailing list settingsSubtask of https://gitlab.com/gitlab-org/gitlab-ce/issues/4272#note_115526454
* adds model for mailing list functionality
* adds basic UI for mailing list setting, I expect that for first iteration we will use email addresses from `gitl...Subtask of https://gitlab.com/gitlab-org/gitlab-ce/issues/4272#note_115526454
* adds model for mailing list functionality
* adds basic UI for mailing list setting, I expect that for first iteration we will use email addresses from `gitlab.yml` so there should not be much to set except enabling/disabling the ML
* adds feature flag for mailing list functionality
Mostly already done by https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17502BacklogRiccardo PadovaniRiccardo Padovanihttps://gitlab.com/gitlab-org/gitlab/-/issues/26057Accommodate offline users after help links switched to docs.gitlab.com site2020-06-19T14:31:26ZMike LewisAccommodate offline users after help links switched to docs.gitlab.com site### Problem to solve
If we update help links from inside GitLab CE/EE to their equivalent paths on docs.gitlab.com (i.e. deprecate the `<instanceDomain>/help` path), this will affect the small subset of users who use GitLab while they a...### Problem to solve
If we update help links from inside GitLab CE/EE to their equivalent paths on docs.gitlab.com (i.e. deprecate the `<instanceDomain>/help` path), this will affect the small subset of users who use GitLab while they are not connected to the internet.
Most solutions to this involve leaving the docs in place on the GitLab instance at /help, allowing such users to visit that copy of the content, instead. That content will be missing some features that we are only able to provide on the site, like the rendering of a table of contents, and working links to other top-level paths outside of /ee or /ce such as /omnibus and /runner.
### Target audience
Users who are able to connect to their GitLab instance but *not* the internet or otherwise cannot access docs.gitlab.com.
### Further details
This helps toward the goal of allowing a single app for the DevOps lifecycle for any kind of user regardless of environment. Given that we are already building /help with the product, with a few changes, we can make the app easier to use for offline users (or prevent a degradation of their experience) while vastly improving the experience for everyone else by further leveraging docs.gitlab.com.
### Proposal
The optimal solution may be
- Allow the admin to toggle the help path
- Allow them to use `<instanceDomain>/help/` instead of `docs.gitlab.com/<edition>/<version>/` .
- But we'd need to account for how to handle future links we add in the UI to other top-level paths like /runner and /omnibus that are not included in /help and only on the doc site. And perhaps avoid relative links in CE/EE docs to these other top level paths, so that users in /help will at least have the option to go online and have a working link.
- Also allow them to use a custom path. This allows them to build the doc site on their network or user's local machine.
- This will require improved build instructions and perhaps the ability to toggle off items that will only work on docs.gitlab.com, such as comments.
### What does success look like, and how can we measure that?
- Positive feedback from GitLabbers who consult with customers or prospects in such offline / highly secure environments.
### Links / references
1. https://gitlab.com/gitlab-org/gitlab-ce/issues/18739
1. https://gitlab.com/gitlab-org/gitlab-ce/issues/56101
Note: We can add further gitlab-docs project needs to the same epic once the [project's move](https://gitlab.com/gitlab-com/gitlab-docs/issues/310) is complete.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/25955Cache and reuse gems for qa directory2019-11-06T04:43:12ZStan HuCache and reuse gems for qa directoryFrom https://gitlab.com/gitlab-org/gitlab-ce/issues/55839, it looks like when RubyGems went down, all the QA-related specs that needed RubyGems also failed (e.g. https://gitlab.com/gitlab-org/gitlab-ce/-/jobs/140316783).
One we can fix ...From https://gitlab.com/gitlab-org/gitlab-ce/issues/55839, it looks like when RubyGems went down, all the QA-related specs that needed RubyGems also failed (e.g. https://gitlab.com/gitlab-org/gitlab-ce/-/jobs/140316783).
One we can fix this is to cache `vendor/qa`, but we might want to consider configuring bundler to use `../vendor` so that we can reuse gems as much as possible?Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/25713Add QA selectors for quick action buttons on Project UI page2019-11-06T04:43:36ZMark LapierreAdd QA selectors for quick action buttons on Project UI pageThe following discussion from gitlab-ce!23366 should be addressed:
- [ ] @sliaquat started a [discussion](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23366#note_123944219): (+2 comments)
> Should we use class selector h...The following discussion from gitlab-ce!23366 should be addressed:
- [ ] @sliaquat started a [discussion](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23366#note_123944219): (+2 comments)
> Should we use class selector here instead of text?
> We would need to add a qa class (say `qa-new-file-button`) [here](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/presenters/project_presenter.rb#L200) and for selector sanity check add this to [qa/qa/page/component/clone_panel.rb](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/qa/qa/page/component/clone_panel.rb):
>
> ```
> base.view 'app/presenters/project_presenter.rb' do
> element :new_file_button
> end
> ```
It looks like they're defined in `app/views/projects/_stat_anchor_list.html.haml` as:
```haml
- anchors = local_assigns.fetch(:anchors, [])
- return unless anchors.any?
%ul.nav
- anchors.each do |anchor|
%li.nav-item
= link_to_if anchor.link, anchor.label, anchor.link, class: anchor.enabled ? 'nav-link stat-link' : "nav-link btn btn-#{anchor.class_modifier || 'missing'}" do
.stat-text= anchor.label
```
So adding selectors isn't as simple as inserting them here into the `.haml`. It looks like we might also need to modify `app/presenters/project_presenter.rb`, which seems to be where the `anchors` data comes from.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/25422Update frontend docs to reflect changes from prettier upgrade2020-10-13T13:30:10ZMike GreilingUpdate frontend docs to reflect changes from prettier upgradeOur gitlab-ce~3412464 style guide docs are a bit out of sync with the current prettier config we've adopted. These need to be updated to reflect the changes since gitlab-ce!22893
example: https://docs.gitlab.com/ee/development/fe_guide...Our gitlab-ce~3412464 style guide docs are a bit out of sync with the current prettier config we've adopted. These need to be updated to reflect the changes since gitlab-ce!22893
example: https://docs.gitlab.com/ee/development/fe_guide/style_guide_js.html#alignmentBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/12386Add milestones, labels, and assignment to an MR in `Resource::MergeRequest.fa...2020-06-05T17:18:05ZMark LapierreAdd milestones, labels, and assignment to an MR in `Resource::MergeRequest.fabricate_via_api!`The following discussion from !14336 should be addressed:
- [ ] @mlapierre started a [discussion](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14336#note_184834737):
> Ideally, this should implement all the options avail...The following discussion from !14336 should be addressed:
- [ ] @mlapierre started a [discussion](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14336#note_184834737):
> Ideally, this should implement all the options available in `fabricate!`, i.e., milestones, labels, and assignment. The only use of those options is in [`create_merge_request_spec.rb`](https://gitlab.com/gitlab-org/gitlab-ee/blob/42aed943f1db5c645ff0a98a80df50dbc1883391/qa/qa/specs/features/browser_ui/3_create/merge_request/create_merge_request_spec.rb), which uses `fabricate_via_browser_ui!`, so this won't cause any problems right now, but it should be updated sooner rather than later so we aren't surprised by the inconsistency later.
/cc @tnikicBackloghttps://gitlab.com/gitlab-org/gitlab/-/issues/12385Update `Repository::ProjectPush` to implement `fabricate_via_api!`2020-06-02T02:10:15ZMark LapierreUpdate `Repository::ProjectPush` to implement `fabricate_via_api!`The `fabricate_via_api!` methods was implemented in `Resource::MergeRequest` in !14336, but it depends on `Repository::ProjectPush`, which does not implement `fabricate_via_api!`.
`fabricate_via_api!` should be implemented in `Repositor...The `fabricate_via_api!` methods was implemented in `Resource::MergeRequest` in !14336, but it depends on `Repository::ProjectPush`, which does not implement `fabricate_via_api!`.
`fabricate_via_api!` should be implemented in `Repository::ProjectPush` so that `Resource::MergeRequest.fabricate_via_api!` doesn't use the UI.Backloghttps://gitlab.com/gitlab-org/gitlab/-/issues/8290Test plan for "Send one email notification for one published code review"2020-08-14T15:45:57ZMark LapierreTest plan for "Send one email notification for one published code review"## Introduction
This test plan is for https://gitlab.com/gitlab-org/gitlab-ee/issues/4326. It extends https://gitlab.com/gitlab-org/gitlab-ee/issues/7275. The feature sends a single email notification for a Review (as opposed to one ema...## Introduction
This test plan is for https://gitlab.com/gitlab-org/gitlab-ee/issues/4326. It extends https://gitlab.com/gitlab-org/gitlab-ee/issues/7275. The feature sends a single email notification for a Review (as opposed to one email per comment as is currently the case).
## Scope
- EE-only
- Unless we can implement a suitable method of automatically verifying the content of emails, that part will have to be tested manually.
## ACC Matrix
| | Secure | Responsive | Intuitive | Reliable |
|------------|:------:|:----------:|:---------:|:--------:|
| MRs | | | | |
| Email | | | | |
For more information see the [Google Testing Blog article about the 10 minute
test plan](https://testing.googleblog.com/2011/09/10-minute-test-plan.html) and
[this wiki page from an open-source tool that implements the ACC
model](https://code.google.com/archive/p/test-analytics/wikis/AccExplained.wiki).
## Capabilities
Email is
* Reliable
- All comments in the Review are included in the email, including non-code comments.
- Comments that are not in the Review are not included in the email.
- All links navigate to the appropriate GitLab content.
## Test Plan
Scenario 1: Email with included and excluded comments
(ideally this would be automated)
- Add code and non-code comments to an MR that _aren't_ part of a review.
- Start a review and add code and non-code comments. Have one resolve a discussion and another unresolve a discussion.
- Submit the review and check that all review comments are included and that all non-review comments are not included.
- Check that resolution status changes are reported.
- Check that a code comment in the email navigates to the correct comment in the MR.
- Repeat for a non-code comment.
[Test Coverage sheet](https://docs.google.com/spreadsheets/d/1RlLfXGboJmNVIPP9jgFV5sXIACGfdcFq1tKd7xnlb74/)https://gitlab.com/gitlab-org/gitlab/-/issues/1413Gotcha with guard clause in overridden methods2020-07-23T16:40:50ZRémy CoutableGotcha with guard clause in overridden methodsThe proper way of handling anonymous rules should be by overriding `#anonymous_rules` in `BasePolicy` subclasses. The default for `#anonymous_rules` is `#rules`.
As mentioned in https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/822...The proper way of handling anonymous rules should be by overriding `#anonymous_rules` in `BasePolicy` subclasses. The default for `#anonymous_rules` is `#rules`.
As mentioned in https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/822#note_19898741, an early `return` does not return from the "overrider" method (be it via inheritance or via `prepend`).
For instance:
```ruby
# app/policies/group_policy.rb
class GroupMemberPolicy < BasePolicy
def rules
return unless @user
target_user = @subject.user
group = @subject.group
return if group.last_owner?(target_user)
can_manage = Ability.allowed?(@user, :admin_group_member, group)
if can_manage
can! :update_group_member
can! :destroy_group_member
elsif @user == target_user
can! :destroy_group_member
end
end
end
# app/policies/ee/group_policy.rb
module EE
module GroupPolicy
def rules
raise NotImplementedError unless defined?(super)
super
owner = @user.admin? || @subject.has_owner?(@user)
master = owner || @subject.has_master?(@user)
if @subject.ldap_synced?
cannot! :admin_group_member
can! :override_group_member if master
end
end
end
end
=> NoMethodError - undefined method `admin?' for nil:NilClass:
app/policies/ee/group_policy.rb:8:in `rules
```
So there's two thing here:
1. Audit our current usage of prepend and make sure we don't have code that don't behave as we'd expect
1. When guard clauses are used in an overridden method, another strategy (documented by https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/963/diffs) should be used:
> create a "hook" method that is empty in CE, and with the EE-specific implementation in EEBacklog