[SaaS UserCap FE]: Add "User cap" setting to Membership area in group Settings > General
Description
Add a "User cap" setting to group Settings > General > Membership.
Feature flag
This feature will be implemented under the saas_user_caps
FF
Design
Availability & Testing
Tests should be added to account for the behavior of the saas_user_caps
feature flag and associated features.
Feature tests should be added to test the User Cap settings option.
- Behavior when User Cap setting is left untouched (default behavior)
- Behavior when User Cap setting is changed
- Behavior when User Cap is set to an invalid value (frontend validation in addition to backend sanitization of the value)
Designs
- Show closed items
Activity
-
Newest first Oldest first
-
Show all activity Show comments only Show history only
- Andrei Stoicescu added frontend label
added frontend label
- Andrei Stoicescu set weight to 2
set weight to 2
- Andrei Stoicescu added to epic &5803 (closed)
added to epic &5803 (closed)
- Andrei Stoicescu marked this issue as related to #332596 (closed)
marked this issue as related to #332596 (closed)
- Andrei Stoicescu mentioned in issue #328680 (closed)
mentioned in issue #328680 (closed)
- Amanda Rueda added grouputilization + 1 deleted label
added grouputilization + 1 deleted label
- Amanda Rueda added devopsfulfillment sectionfulfillment labels
added devopsfulfillment sectionfulfillment labels
- Amanda Rueda added workflowblocked label
added workflowblocked label
- Amanda Rueda changed milestone to %14.3
changed milestone to %14.3
- Andrei Stoicescu changed the description
Compare with previous version changed the description
- Amanda Rueda changed title from [UserCap FE]: Add "User cap" setting to Membership area in group Settings > General to [SaaS UserCap FE]: Add "User cap" setting to Membership area in group Settings > General
changed title from [UserCap FE]: Add "User cap" setting to Membership area in group Settings > General to [SaaS UserCap FE]: Add "User cap" setting to Membership area in group Settings > General
- Amanda Rueda changed milestone to %14.4
changed milestone to %14.4
- Maintainer
I don't think this issue should be blocked by #332596 (closed) - I think the backend work to support this issue (adding a new column for the setting) was added in #332590 (closed) - now we just need to toggle that setting on/off via the form?
The only aspect that may still be blocked is the feature flag not existing yet, but it could be added as part of the FE work?
1 Collapse replies - Developer
@aalakkad @sheldonled can you confirm if this issue is now workflowready for development ?
- Maintainer
@amandarueda yes, we're good to go here!
The feature flag was added here: !66264 (merged)
So this issue can focus only on the UI work
1
- Amanda Rueda removed workflowblocked label
removed workflowblocked label
- Amanda Rueda added workflowready for development label
added workflowready for development label
- 🤖 GitLab Bot 🤖 added [deprecated] Accepting merge requests label
added [deprecated] Accepting merge requests label
- 🤖 GitLab Bot 🤖 mentioned in issue gitlab-org/quality/triage-reports#4513 (closed)
mentioned in issue gitlab-org/quality/triage-reports#4513 (closed)
- Amanda Rueda removed the relation with #332596 (closed)
removed the relation with #332596 (closed)
- 🤖 GitLab Bot 🤖 mentioned in issue gitlab-org/quality/triage-reports#4603 (closed)
mentioned in issue gitlab-org/quality/triage-reports#4603 (closed)
- Dan Davison added quad-planningcomplete-action label
added quad-planningcomplete-action label
- Dan Davison changed the description
Compare with previous version changed the description
- Sheldon Led assigned to @sheldonled
assigned to @sheldonled
- Sheldon Led added workflowin dev label and removed workflowready for development label
added workflowin dev label and removed workflowready for development label
- 🤖 GitLab Bot 🤖 removed [deprecated] Accepting merge requests label
removed [deprecated] Accepting merge requests label
- Ammar Alakkad marked this issue as related to #330028 (closed)
marked this issue as related to #330028 (closed)
- Ammar Alakkad mentioned in issue #330028 (closed)
mentioned in issue #330028 (closed)
- Developer
I'll take this issue over, given it's a blocker to #330028 (closed) and hasn't been worked on yet.
Collapse replies - Developer
/cc @sheldonled
- Maintainer
Thank you @aalakkad
- Ammar Alakkad assigned to @aalakkad and unassigned @sheldonled
assigned to @aalakkad and unassigned @sheldonled
- Developer
Async issue update
- Development hasn't started yet
- Hopefully it will be sent to initial review early next week
- Developer
@amandarueda I couldn't find which docs link to use for the "approved by admin" link, could you help me with that (or point me in the right direction)?
If the link should be to a docs page that hasn't been created yet, would you like me to create a docs issue to capture it?
Collapse replies - Developer
@aalakkad it looks like our docs related to user cap feature is limited: https://docs.gitlab.com/ee/user/admin_area/settings/sign_up_restrictions.html#user-cap
We'll need more content built for SaaS, though the approval step should have already been documented for SM.
Also, please be aware, that "approved by an admin" is only appropriate language for SM, for SaaS, it should read "approved by an owner".
- Ammar Alakkad mentioned in merge request !72006 (merged)
mentioned in merge request !72006 (merged)
- Amanda Rueda changed epic to &6862 (closed)
changed epic to &6862 (closed)
- Ammar Alakkad added workflowin review label and removed workflowin dev label
added workflowin review label and removed workflowin dev label
- Ammar Alakkad mentioned in merge request !72280 (merged)
mentioned in merge request !72280 (merged)
- Amanda Rueda added missed:14.4 label
added missed:14.4 label
- Amanda Rueda changed milestone to %14.5
changed milestone to %14.5
- Developer
- Ammar Alakkad added workflowstaging label and removed workflowin review label
added workflowstaging label and removed workflowin review label
- Ammar Alakkad closed
closed