kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity
gitlab-org--gitlab-foss/app/views/projects/protected_branches/_protected_branch.html.haml

29 lines
2.1 KiB
Text
Raw Normal View History

Refactor of Protected Branch Edit List
2016-08-03 14:02:42 -04:00
%tr.js-protected-branch-edit-form{ data: { url: namespace_project_protected_branch_path(@project.namespace, @project, protected_branch), branch_id: protected_branch.id } }
Modify the frontend for wildcard protected branches. 1. Allow entering any branch name for a protected branch. - Either pick from a list of options, or enter it manually - You can enter wildcards. 2. Display branches matching a protected branch. - Add a `ProtectedBranches#show` page that displays the branches matching the given protected branch, or a message if there are no matches. - On the `index` page, display the last commit for an exact match, or the number of matching branches for a wildcard match. - Add an `iid` column to `protected_branches` - this is what we use for the `show` page URL. - On the off chance that this feature is unnecessary, this commit encapsulates it neatly, so it can be removed without affecting anything else. 3. Remove the "Last Commit" column from the list of protected branches. - There's no way to pull these for wildcard protected branches, so it's best left for the `show` page. - Rename the `@branches` instance variable to `@protected_branches` - Minor styling changes with the "Unprotect" button - floated right like the "Revoke" button for personal access tokens 4. Paginate the list of protected branches. 5. Move the instructions to the left side of the page.
2016-06-16 03:33:30 -04:00
%td
= protected_branch.name
- if @project.root_ref?(protected_branch.name)
%span.label.label-info.prepend-left-5 default
%td
- if protected_branch.wildcard?
- matching_branches = protected_branch.matching(repository.branches)
= link_to pluralize(matching_branches.count, "matching branch"), namespace_project_protected_branch_path(@project.namespace, @project, protected_branch)
- else
- if commit = protected_branch.commit
= link_to(commit.short_id, namespace_project_commit_path(@project.namespace, @project, commit.id), class: 'commit_short_id')
= time_ago_with_tooltip(commit.committed_date)
- else
(branch was removed from repository)
%td
Backport changes from gitlab-org/gitlab-ee!581 to CE. !581 has a lot of changes that would cause merge conflicts if not properly backported to CE. This commit/MR serves as a better foundation for gitlab-org/gitlab-ee!581. = Changes = 1. Move from `has_one {merge,push}_access_level` to `has_many`, with the `length` of the association limited to `1`. This is _effectively_ a `has_one` association, but should cause less conflicts with EE, which is set to `has_many`. This has a number of related changes in the views, specs, and factories. 2. Make `gon` variable loading more consistent (with EE!581) in the `ProtectedBranchesController`. Also use `::` to prefix the `ProtectedBranches` services, because this is required in EE. 3. Extract a `ProtectedBranchAccess` concern from the two access level models. This concern only has a single `humanize` method here, but will have more methods in EE. 4. Add `form_errors` to the protected branches creation form. This is not strictly required for EE compatibility, but was an oversight nonetheless.
2016-08-16 01:09:13 -04:00
= hidden_field_tag "allowed_to_merge_#{protected_branch.id}", protected_branch.merge_access_levels.first.access_level
= dropdown_tag( (protected_branch.merge_access_levels.first.humanize || 'Select') ,
Add custom css class to each dropdown to fix failing spec
2016-08-03 23:32:57 -04:00
options: { toggle_class: 'js-allowed-to-merge', dropdown_class: 'dropdown-menu-selectable js-allowed-to-merge-container',
Backport changes from gitlab-org/gitlab-ee!581 to CE. !581 has a lot of changes that would cause merge conflicts if not properly backported to CE. This commit/MR serves as a better foundation for gitlab-org/gitlab-ee!581. = Changes = 1. Move from `has_one {merge,push}_access_level` to `has_many`, with the `length` of the association limited to `1`. This is _effectively_ a `has_one` association, but should cause less conflicts with EE, which is set to `has_many`. This has a number of related changes in the views, specs, and factories. 2. Make `gon` variable loading more consistent (with EE!581) in the `ProtectedBranchesController`. Also use `::` to prefix the `ProtectedBranches` services, because this is required in EE. 3. Extract a `ProtectedBranchAccess` concern from the two access level models. This concern only has a single `humanize` method here, but will have more methods in EE. 4. Add `form_errors` to the protected branches creation form. This is not strictly required for EE compatibility, but was an oversight nonetheless.
2016-08-16 01:09:13 -04:00
data: { field_name: "allowed_to_merge_#{protected_branch.id}", access_level_id: protected_branch.merge_access_levels.first.id }})
Revert "Revert "Merge branch '18193-developers-can-merge' into 'master' "" This reverts commit 530f5158e297f3cde27f3566cfe13bad74ba3b50. See !4892. Signed-off-by: Rémy Coutable <remy@rymai.me>
2016-07-18 04:16:56 -04:00
%td
Backport changes from gitlab-org/gitlab-ee!581 to CE. !581 has a lot of changes that would cause merge conflicts if not properly backported to CE. This commit/MR serves as a better foundation for gitlab-org/gitlab-ee!581. = Changes = 1. Move from `has_one {merge,push}_access_level` to `has_many`, with the `length` of the association limited to `1`. This is _effectively_ a `has_one` association, but should cause less conflicts with EE, which is set to `has_many`. This has a number of related changes in the views, specs, and factories. 2. Make `gon` variable loading more consistent (with EE!581) in the `ProtectedBranchesController`. Also use `::` to prefix the `ProtectedBranches` services, because this is required in EE. 3. Extract a `ProtectedBranchAccess` concern from the two access level models. This concern only has a single `humanize` method here, but will have more methods in EE. 4. Add `form_errors` to the protected branches creation form. This is not strictly required for EE compatibility, but was an oversight nonetheless.
2016-08-16 01:09:13 -04:00
= hidden_field_tag "allowed_to_push_#{protected_branch.id}", protected_branch.push_access_levels.first.access_level
= dropdown_tag( (protected_branch.push_access_levels.first.humanize || 'Select') ,
Add custom css class to each dropdown to fix failing spec
2016-08-03 23:32:57 -04:00
options: { toggle_class: 'js-allowed-to-push', dropdown_class: 'dropdown-menu-selectable js-allowed-to-push-container',
Backport changes from gitlab-org/gitlab-ee!581 to CE. !581 has a lot of changes that would cause merge conflicts if not properly backported to CE. This commit/MR serves as a better foundation for gitlab-org/gitlab-ee!581. = Changes = 1. Move from `has_one {merge,push}_access_level` to `has_many`, with the `length` of the association limited to `1`. This is _effectively_ a `has_one` association, but should cause less conflicts with EE, which is set to `has_many`. This has a number of related changes in the views, specs, and factories. 2. Make `gon` variable loading more consistent (with EE!581) in the `ProtectedBranchesController`. Also use `::` to prefix the `ProtectedBranches` services, because this is required in EE. 3. Extract a `ProtectedBranchAccess` concern from the two access level models. This concern only has a single `humanize` method here, but will have more methods in EE. 4. Add `form_errors` to the protected branches creation form. This is not strictly required for EE compatibility, but was an oversight nonetheless.
2016-08-16 01:09:13 -04:00
data: { field_name: "allowed_to_push_#{protected_branch.id}", access_level_id: protected_branch.push_access_levels.first.id }})
Modify the frontend for wildcard protected branches. 1. Allow entering any branch name for a protected branch. - Either pick from a list of options, or enter it manually - You can enter wildcards. 2. Display branches matching a protected branch. - Add a `ProtectedBranches#show` page that displays the branches matching the given protected branch, or a message if there are no matches. - On the `index` page, display the last commit for an exact match, or the number of matching branches for a wildcard match. - Add an `iid` column to `protected_branches` - this is what we use for the `show` page URL. - On the off chance that this feature is unnecessary, this commit encapsulates it neatly, so it can be removed without affecting anything else. 3. Remove the "Last Commit" column from the list of protected branches. - There's no way to pull these for wildcard protected branches, so it's best left for the `show` page. - Rename the `@branches` instance variable to `@protected_branches` - Minor styling changes with the "Unprotect" button - floated right like the "Revoke" button for personal access tokens 4. Paginate the list of protected branches. 5. Move the instructions to the left side of the page.
2016-06-16 03:33:30 -04:00
- if can_admin_project
%td
Update layout and JS for create protected branch. Also updates protect branch list
2016-08-01 17:08:36 -04:00
= link_to 'Unprotect', [@project.namespace.becomes(Namespace), @project, protected_branch], data: { confirm: 'Branch will be writable for developers. Are you sure?' }, method: :delete, class: 'btn btn-warning'
Copy permalink