Skip to content

Spike: Rearchitect Security Configuration frontend

Why are we doing this work

The existing Security Configuration page is currently implemented twice: once for GitLab Ultimate users, and again for non-Ultimate users.

The decision to have a separate, static implementation of the page for non-Ultimate users was taken so as to minimise the effort/time to make something available for non-Ultimate - i.e., it's an MVC.

Having two implementations increases the maintenance burden in the long term, so this issue is about investigating a different frontend architecture that would accommodate sharing code/implementations between the two versions.

What's the goal of the spike?

To determine whether the proposed architectures will make it easier to:

Relevant links

Non-functional requirements

  • [-] Documentation:
  • [-] Feature flag:
  • [-] Performance:
  • Testing: See #322462 (closed)

Proposals

1. Using scanner-specific rows

Since this is a spike, the plan isn't concrete. But in general, the approach to investigate will move user-facing strings to the frontend, and to move away from the feature abstraction and use concrete scanner-specific rows. The old implementation is column-centric, leading to various code smells; this rearchitecturing will be row/scanner-centric.

2. Using scanner-specific cells

This is closer to what the CE implementation does already, though for both the Status and Manage cells. This was the approach taken in !55623 (closed).

Next steps

  • Open follow-up issue(s) to implement new architecture (unless the effort can just be done and finished off as part of this issue)

Auto-Summary 🤖

Discoto Usage

Points

Discussion points are declared by headings, list items, and single lines that start with the text (case-insensitive) point:. For example, the following are all valid points:

  • #### POINT: This is a point
  • * point: This is a point
  • + Point: This is a point
  • - pOINT: This is a point
  • point: This is a **point**

Note that any markdown used in the point text will also be propagated into the topic summaries.

Outcomes

Outcomes define the decisions or resolutions of a discussion. Once outcomes are defined, sub-topics and points are collapsed underneath the outcomes.

Outcomes are declared in a similar manner as points:

  • #### OUTCOME: This is an outcome
  • * outcome: This is an outcome
  • + Outcome: This is an outcome
  • - oUTCOME: This is an outcome
  • outcome: This is an outcome

Note that multiple outcomes may be declared for each topic.

Topics

Topics can be stand-alone and contained within an issuable (epic, issue, MR), or can be inline.

Inline topics are defined by creating a new thread (discussion) where the first line of the first comment is a heading that starts with (case-insensitive) topic:. For example, the following are all valid topics:

  • # Topic: Inline discussion topic 1
  • ## TOPIC: **{+A Green, bolded topic+}**
  • ### tOpIc: Another topic

Quick Actions

Action Description
/discuss sub-topic TITLE Create an issue for a sub-topic. Does not work in epics
/discuss link ISSUABLE-LINK Link an issuable as a child of this discussion

Discussion-Size Indicators

The relative size of the discussion occurring within a topic and its sub-topics is indicated via braille dots.

More dots means that more points or sub-topics exist within a given topic.

Examples:

  • TOPIC ⣿⣿⡆ A large discussion occurred here
  • TOPIC ⣇ A smaller discussion occurred here

Last updated by this job

Edited by 🤖 GitLab Bot 🤖