GitLab Next

@mikegreiling had the following idea regarding the new expandable sections within settings:

When using the new expandable settings sections, they do not remain open after submitting a form.

For instance if you go into "Sharing & Permissions" and change something, then click "save", you end up back at a list of sections without the "Sharing & Permissions" one expanded.

We should add some logic to have sections auto-expand when that section was just recently modified. Or perhaps we can use cookies to remember which sections were expanded or contracted the last time this user visited the page.

Checklist:

• GitLab admin settings:

  • visibility
  • account
  • signup
  • signin
  • terms
  • help
  • pages
  • ci-cd
  • influx
  • prometheus
  • performance-bar
  • background
  • spam
  • abuse
  • logging
  • repository-storage
  • repository-check
  • registry
  • koding
  • plantuml
  • usage
  • email
  • gitaly
  • terminal
  • realtime
  • performance
  • ip-limits
  • outbound
  • mirror
  • geo (ee-only)
  • external-auth (ee-only)
  • elasticsearch (ee-only)
  • slack (ee-only)
  • third-party-offers
  • pseudonymizer (ee-only)

• Groups settings:

  • general
  • permissions
  • advanced

• Groups CI/CD settings:

  • secret variables
  • runners

• Project settings:

  • general
  • permissions
  • issues (ee-only)
  • merge-request
  • service-desk (ee-only)
  • advanced
  • export-project

• Project repository settings:

  • push-rules (ee-only)
  • pull-remote (ee-only)
  • push-remote
  • protected-branches
  • protected-tags
  • deploy-keys
  • deploy-tokens

• Project CI/CD settings:

  • general-pipeline
  • auto-devops
  • runners
  • variables
  • pipeline-triggers
  • protected-environments (ee-only)

First-Pass Solution

We can use hash strings on the URL that one is forwarded to after a form is submitted. When a hash string corresponds to the ID of a collapsable section it will automatically be expanded.

Future Solutions

We need to find a way to save the changes without reloading the page. Reloading the page and showing a flash message on top of the reloaded page is too disruptive for the user. It's too much even if we changed it so the page reloads, scrolls down to the section and exapnds it. We should aim for the following:

That doesn't solve the following issue though:

For some sections, I don't think it's immediately clear that if you make a change, whether it's saving it to the system, especially if it's a long section and you don't see the Save button on screen. (You have to scroll.)

There's a separate issue that adresses this: gitlab-org/gitlab-ce#49603