►
From YouTube: GitLab 13.10 - Manage
Description
Learn about all of the features that the Manage stage is working on for 13.10
A
A
B
B
So
if
you
remember-
or
you
don't
a
few
milestones
ago,
we
lowered
the
sso
timeline
to
seven
days,
but
because
every
time
the
seven
days
were
up,
it
required
a
user
interaction,
a
user
click
to
re-login.
We
decided
to
leave
it
at
seven
days,
we've
since
improved,
where
we
make
a
request
to
the
idp
behind
the
scenes.
So
there's
no
user
interaction
needed
to
basically
refresh
the
sso
token.
B
It's
all
automatically
done
behind
the
scenes
so
based
on
that
we're
gonna
now
lower
it
to
one
day
so,
every
day
gitlab
will
reach
out
to
the
idp
and
make
sure
that
user
is
still
basically
has
a
valid
session
at
the
idp
level.
So,
for
example,
with
octa
for
us,
if
they
are
not
logged
in,
they
will
have
to
go
through
the
login
action.
B
So,
basically,
if
a
git
operation
is
attempted
against
a
project,
that's
part
of
an
sso
enforced
group
we'll
check
to
see
if
there's
a
valid
sso
session
and
if
there's
not
we'll,
have
to
instruct
the
user
to
go
to
the
ui
and
logged
in.
That's
not
a
perfect
experience,
but
it's
really
not
possible
to
do
that.
Sso
handshake
through
the
git
command
line.
So
basically
it
will
require
the
user
to
go
to
the
ui
if
they
haven't.
You
know
within
24
hours
for
anything
else
to
refresh
their
session.
B
So,
basically,
if
a
specific
group
doesn't
want
to
inconvenience
their
end
users,
they
don't
have
to,
but
in
the
long
term
I
do
see
this
being
something
that
would
be
enabled
by
default
since
a
lot
of
enterprise
customers
have
been
asking
for
this.
The
next
iteration
of
this
will
be
through
to
enforce
sso
on
the
api,
but
that's
not
in
this
milestone,
just
giving
you
guys
some
idea
of
where
we're
headed.
B
So
you,
as
a
group
administrator,
can
say
I
want
all
projects
in
my
entire
hierarchy
to
have
a
five
day.
Soft
delete
right,
and
I
want
to
enforce
that.
We
use
that
as
a
testing
ground
for
a
setting
and
to
develop
the
framework,
but
basically
this
will
allow
anyone
that
has
settings
to
implement
it
in
a
similar
way
and
that
way
it's
consistent
across
all
groups
at
gitlab.
B
So
we,
like,
I
said,
develop
a
poc
and
now
we're
going
to
be
hardening
and
rolling
out
this
first
feature
and
then
also
along
with
this
doing
some
communication
internally
to
let
other
groups
know
that
this
is
available
and
they
can
start
using
it.
So
super
exciting
to
see
this
come
to
fruition
and
last
performance
and
security
are
always
focuses
for
the
access
team.
So
some
of
our
capacity
is
allotted
to
go
toward
that
and
that's
it
for
access.
I
see
some
questions.
C
B
B
It's
actually
preferred
by
enterprises
that
do
sso
enforcement,
because
it
does
basically
ensure
that
they're
still
a
valid
user
in
their
idp.
Now,
if
in
their
idp,
they
have
that
timeout
set
to
longer
right.
Let's
say
they
have
it
set
to
five
days,
we'll
just
reach
out
to
the
idp
to
see
if
there's
still
a
valid
session,
and
if
there
is
basically
that
interaction
will
be
invisible
to
the
user.
B
C
A
Yeah,
I
think
I
have
similar
questions
melissa.
Basically,
it
sounds
great
that
that
we'll
probably
be
able
to
more
quickly
adapt
to
any
kind
of
changes
where
a
user's
permission
may
have
may
have
been
updated
since
the
last
time
they
authenticated,
and
so
now
it's
kind
of
a
maximum
lag
time
of
like
24
hours
set.
Now
that's
that
sounds
great
for
a
lot
of
I'm
sure.
It's
a
comfort
for
a
lot
of
folks
out
there
who
might
have
users
who
have
changing
permissions
on
onboarding
off-boarding.
A
B
C
B
D
C
We
are
going
to
continue
down,
continue
progressing
against
the
new
gitlab
migration
feature,
and
what
we
plan
to
do
in
1310
is
to
complete
the
migration
of
epics
right
now
we
have
the
actual
epic,
the
district
description
and
title
coming
across.
We
have
the
parents,
the
labels
and
the
word
award
emojis
coming
across.
C
We
have
put
a
beta
warning
and
can
ask
for
feedback
here,
because
this
is
definitely
work
in
progress.
It
is
not
mature
enough
to
where
you
know.
I
really
don't
expect
a
lot
of
real
usage
to
come
out
of
this.
It's
mostly
going
to
be
people
testing
the
waters
and
seeing
what
it
is,
while
kind
of
watching
how
it's
being
developed
so
we'll
make
sure
to
stay
on
top
of
documentation.
C
You
know
like
have
the
user
understand
exactly
what's
coming
across?
What's
not
while
this
is
still
being
developed,
so
once
you
do
connect
to
the
other
instance
of
gitlab,
you
see
something
like
this
to
where
you
have
kind
of
all.
The
groups
that
you
have
access
to
at
another
instance
showing
here
and
you
can
select
sort
of
where
you
want
to
migrate
them
in
this
particular
instance,
hit
import
and
the
group
will
get
migrated.
C
So,
in
addition
to
completing
the
epics,
we
expect
to
make
further
progress
against
the
epic
called
parity
with
group
export
input.
This
is
the
epic
that
once
completed
is
going
to
have.
You
know
is
going
to
mean
that
all
the
functionality
exists
in
the
existing
group.
Export
import
will
now
exist
in
the
group
migration
feature
and
we
will
be
able
to
deprecate
the
group
export
import
once
we
reach
once
we
complete
this
particular
epic.
This
epic,
you
know,
has
probably
another.
C
You
know
10
15
issues
in
it
to
be
completed,
so
I
expect
this
to
to
happen
over
the
next
two
milestones,
at
least,
but
I
expect
to
make
a
good
dent
in
the
remainder
of
of
this
parity,
epic
in
1310,
so
that
is
definitely
going
to
be
where
we
continue
working
on
migrating
objects,
other
than
epics
that
belong
on
that
that
belong
in
a
group
such
as
milestones,
group
labels
and
any
other
object
that
lives
in
the
group.
So
that's
going
to
be
kind
of
the
flavor
for
1310.
C
In
addition
to
that,
we
are
going
to
continue
paying
attention
to
the
ux
improvements
all
along,
so
the
track
that
I
talked
about
is
mainly
backhand
kind
of
making
the
feature
more
deep
and
more
kind
of
more
more
featureful.
But
in
addition
to
that,
we're
also
changing
the
user
experience
of
someone
who
is
using
this
feature
so
that
they
can
more
easily
see,
what's
being
migrated,
select
what
to
migrate.
C
So
this
experience
is
going
to
be
vastly
improved
over
what
we've
had
before,
and
the
one
thing
that
I
want
to
highlight
for
1310
is
the
ability
to
have
a
selectable
page
size
for
our
list,
so
the
list
of
groups
that
I'm
showing
here
is
short
for
me.
But
imagine
if
you
were
a
big
company
and
you
had
hundreds
of
different
groups,
our
pagination
defaults
to
20
items
per
page,
and
you
know
if
you
had
1000
groups,
it
means
you
have
to
visit
50
different
pages
in
order
to
migrate
them
all.
C
So
what
we
want
to
do
is
help
out
a
little
bit
with
that.
We
want
to
introduce
a
new
concept
that
doesn't
currently
exist
in
gitlab
and
we're
working
with
the
pajamas
with
the
foundations
team
to
sort
of
define
this
so
that
it
could
be
used
elsewhere,
where
we
have
lists,
and
the
concept
is
such
that
we
will
be
able
to
click
on
this
drop
down.
That
says,
20
items
per
page
and
select
50
or
100
as
choices
for
the
for
the
page.
100
is
currently
a
backhand
limitation
in
in
our
api.
C
C
A
Yeah
thanks
harris.
I
I
can't
wait
for
my
epic
award
emojis
to
carry
over
super
excited
for
all
my
thumbs
up
and
stars,
and
maybe
a
few
thumbs
down
we'll
have
to
see.
But
question
you
mentioned
was
behind
the
feature
flag
that
was
turned
on.
Is
that
on
by
default
for
our
self-managed
customers,
or
should
they
expect
to
see
this
in
in
139
in
13,
at
10
or.
C
A
A
D
I
had
a
comment.
I
really
like
the
pagination
option
to
have
more
than
20
items
on
a
page.
We
have
similar
limitations
in
optimize
in
our
value
stream
analytics
page.
We
currently
just
limit
the
number
of
issues
that
are
displayed
there
to
20
and
we
have
open
issues
to
increase
that
to
50
and
add
pagination,
and
so
I
will
definitely
let
the
team
know
about
the
work
that
you're
doing
there
cool.
B
C
D
D
We
have
done
most
of
the
work
of
wrapping
up
the
horizontal
navigation,
so
we
will,
in
1310,
be
removing
the
vertical
navigation
and
next
one
I'm
really
excited
about
we.
This
is
one
that
rolled
over,
so
I
have
talked
about
it
before,
but
currently
we
have
for
each
stage
in
a
value
stream.
We
have
a
list
of
issues
or
merge
requests
and
the
time
it
takes
to
complete
those
items.
D
And
then
over
here
you
see,
we
have
the
median
time
we're
also
going
to
be
adding
the
average
time
it
takes
to
move
things
through
a
stage,
and
so
that
will
be
a
column
within
the
table.
I
just
mentioned,
and
then
value
stream
analytics
comes
with
a
set
of
default
stages
to
understand
what
those
default
stages
are
actually
measuring.
You
have
to
go
in
and
edit
the
stage,
so
we're
going
to
add
some
tool,
tips
that
make
it
really
easy
for
you
to
understand
what
those
stages
mean
and
we
are
adding
an
overview
tab.
D
D
And
then
we're
going
to
start
work
on
refactoring
project
level,
value
stream
analytics.
So
what
I've
been
showing
you
here
is
the
group
level
feature
if
you
go
to
the
project
level
feature
you'll
notice
that
it
doesn't
have
anywhere
near
as
much
functionality,
so
we're
going
to
be
refactoring
the
code
to
use
the
group
level
code
and
reach
parity
on
these
two
features.
D
D
So
what
gitlab
features
you
have
adopted
for
different
groups,
and
you
can
add
whatever
groups
you
want
to
to
this
table,
so
we
will
be
we're
getting
very
close
to
launching
that
and
then
another
one
that
I'm
really
excited
about
is
adding
this
table
to
the
group
level,
which
makes
it
a
lot
more
accessible.
So
our
gitlab.com
users
will
be
able
to
access
it,
and
anyone
with
reporter
or
higher
access
to
a
group
will
be
able
to
see
the
feature
adoption
for
their
group.
D
Next,
we
are
starting
to
pick
up
work
on
dora
metrics.
The
four-door
metrics
have
become
an
industry
standard
for
measuring
how
quickly
and
reliably
you
can
deliver
software,
and
there
is
a
lot
of
demand
from
our
customers
to
show
these
in
value
stream
analytics.
The
release
team
has
also
been
implementing
these
in
the
cicd
metrics.
D
We
currently
have
the
deploy
number
of
deploys
and
the
deployment
frequency,
but
it
doesn't
really
align
with
the
definition
fedora
and
so
the
first
change
we're
making
is
currently
we
measure
this
based
on
when
a
deployment
is
started,
we're
changing
this
to
actually
already
in
thirteen
nine.
We
change
this
to
be
based
on
when
a
deployment
is
completed.
So
you
know
it
was
actually
successful
and
completed
within
that
time
frame
that
you've
selected
and
the
next
change
we'll
be
making
is
to
limit
this
to
production
environments
deployments
to
production
environments.
D
B
Yeah,
so
I
I
think
the
devops
report
is
really
cool
in
just
showcasing
the
value
that
people
are
getting
from
gitlab
and
I
was
wondering
the
columns
like
issues.
Mrs
approvals,
all
of
those
I
built
are
those
hard-coded
and
basically
can
groups
go
in
and
add
themselves
if
they
wanted
to
or
how
does
that
work.
D
Yeah
so
right
now
you
need
to
be
an
admin
and
come
in
and
add
a
group
and
they
they
are
boolean
values.
Unfortunately,
I
don't
have
a
good
demo
set
up
to
show
the
positive
view
like
this
is
showing
that
nothing
has
been
adopted
for
any
group.
But
let's
say
that
my
group
7
had
has
been
using
issues.
Then
this
would
be
a
filled
in
circle
and
then
that's
based
on
within
the
last,
so
in
the
last
calendar
month.
Did
that
group
use
at
least
one
issue
create
one
issue.
D
There's
a
lot
of
this
is
very
much
an
nbc
and
there's
we
have
a
a
really
exciting
vision
for
where
this
is
going
to
go.
So
this
is
a
super
basic
form.
I
think
one
of
the
next
iterations
we'll
make
here
is
to
add
the
devops
stages
as
the
the
columns
at
the
top
and
then
have
more
fine-grained
features
within
each
of
those
stages.
B
Yeah,
I
think
this
one
would
be
something
that
would
be
interesting
to
see
if
there's
interest
from
other
groups
and
crowds
of
course
sourcing.
I
don't
know
how
difficult
that
could
be,
but
if
somebody
like,
for
example,
with
me
from
access,
I'm
interested
in
showcasing
something
access
related
here.