►
A
A
So
over
here
I
have
my
group
and
let's
walk
through
removing
a
user
from
this
group.
So
if
I'm
an
enterprise
company,
then
I'm
probably
using
some
kind
of
provisioning
system,
whether
that's
sso
or
ldap,
so
for
the
purpose
of
this
job
to
be
done,
we're
going
to
assume
that
I've
seen
some
accounts
deprovisioned
in
my
sso,
and
I
want
to
go
in
and
remove
those
users
from
get
lab.
A
A
A
The
first
thing
that
you'll
notice
is
this
doesn't
have
any
connection
to
my
sso,
so
the
deprovision
status
in
my
sso
doesn't
flow
over
here
to
get
lab.
So
I
have
to
do
some
kind
of
cross
checking
or
comparison
between
my
sso
or
my
ldap,
and
what
I'm
seeing
here
in
gitlab,
so
a
logical
first
step
might
be
well.
A
You
know
that's
five
years
of
inactivity
on
that
user
and
this
first
pain
point
that
I'm
bringing
up
I'm
kind
of
cheating,
because
we
heard
this
from
a
customer
recently,
but
last
activity
doesn't
include
last
login,
the
you,
the
the
customer
that
we
talked
to
noticed
that
one
of
the
users
that
said
never
had
actually
logged
in
that
very
weak.
So
this
screen
isn't
tracking
last
login,
which
means
you
can't
rely
on
last
activity
to
know.
A
A
A
And
then
this
is
just
a
small
thing,
but
this
email
column
and
it
could
be
different
for
different
customers.
But
why
is
why
are
most
of
these
private?
This
isn't
a
very
useful
thing
to
show
in
the
ui.
If
all
these
emails
are
private
and
it
doesn't
show
me
as
a
user.
How
would
I
change
that?
If
I
wanted
to
see
emails
here,
what
is
causing
those
to
be
private
and
how
could
that
be
changed
so
that
I
could
see
these
people's
email
addresses
something?
A
A
I
can't
I
can't
see
that
information
for
these
users.
I
can't
see
what
project
they're
a
member
of
that
was
invited,
and
I
can't
see
what
group
this
user
was
a
member
of
who
was
invited
so
far.
I
think
there's
a
big
opportunity
for
last
login
and
also
bringing
some
consistency
to
these
users.
Some
visibility
into
what's
going
on
with
these
different
invites,
and
why?
A
We
can
set
aside
the
the
sso
d
provisioning
here
that
we're
not
showing
that
status
right
now
in
gitlab.
If
you
want
to
remove
users,
the
investigation
has
to
happen
manually.
You
have
to
go
in
and
try
to
figure
out
which
users
actually
need
to
be
removed,
since
that
status
is
not
bringing
in.
So
assuming
that
the
user
had
the
the
I,
as
the
user
have
done,
that
I've
figured
out
which
users
I
want
to
remove,
which
would
require
a
lot
of
cross-referencing
and
maybe
exporting
of
user
lists.
In
my
sso,
I
want
to
remove.
A
A
There
might
be
ways
for
me
to
go
investigate
that
in
other
areas
of
the
product,
but
from
this
screen
it's
not
possible
to
remove
a
user
that
was
invited
by
a
group
or
a
project.
I
would
get
the
same
message
here
and
again,
that's
just
not
clear,
and
it's
also
the
flexibility
isn't
there
this.
Ideally,
this
ui
would
allow
me
to
remove
this
user
whether
that
means
it
would
show
me
the
group
that
I
would
need
to
remove
or
the
group
that
I
would
need
to
contact
to
get
this
user
out.
A
A
A
A
A
A
I
feel
like
when
you're
dealing
with
something
as
serious
as
removing
a
user.
We
really
need
to
drive
home
confidence
and
reassurance
that
you
did
the
right
thing
and
here's
exactly
what
just
happened.
This
doesn't
tell
me
really
what
happened.
I
could
assume
that
this
means
everything
I
wanted
and
wished
for
came
true,
but
it's
not
actually
telling
me
so
this
alert
could
really
be
more
robust.
A
A
A
A
I
think
this
cta
could
be
a
little
more
clear.
Instead
of
remove
user,
it
could
be
remove
user
from
namespace.
It's
not
like.
We
have
a
ton
of
actions
here
we
could.
If
space
or
scalability
of
this
ui
is
an
issue,
we
could
find
ways
to
make
that
more
clear.
I
think
remove
user
isn't
quite
clear
enough
because
it
it
requires
me
to
get
to
the
dialogue
to
know
what
I'm
removing
them
from
in
order
to
get
to
the
dialogue.
A
I
also
have
to
have
confidence
that
I'm
not
taking
a
final
action
here,
but
that
there
will
be
a
confirmation,
so
I
have
to
take
the
bet
that
I'm
gonna
get
a
confirmation
in
order.
Okay,
so
I
did
and
now
I
can
read,
but
I
think
there's
an
opportunity
to
make
that
more
clear
up
front
of
what
I'm
removing
them
from.
A
I
also
think
for
investigative
purposes,
I've
talked
to
a
few
users
who,
when
they're
doing
when
they're
cleaning
up
their
seats,
they're
wanting
to
investigate
it's,
not
it's
never
just
oh
I
I
know
exactly
who
to
remove
the
ui
shows
me
right
here.
Usually
you
have
to
go
in
you
have
to
investigate
okay.
Why
is
this
person
inactive?
What
is
activity
showing
me?
Are
they
still
using
gitlab
and
they'll?
Ask
around
they'll
look
around
in
the
ui
they'll
figure
out.
A
A
A
A
You
can
make
an
argument
for
terrible,
because
there
are
actually
some
actions
that
you
literally
can't
do
like
removing
a
member
invited
via
a
group
I
went
with
poor,
which
is
defined
as
experience
is
viewed
as
a
poor
experience
and
is
difficult
to
complete
ease,
difficult
experience.
Bad,
I
would
say,
that's
pretty
fitting.
I
would
say
it's
not
impossible
to
remove
a
group
invited
user.
It
just
can't
be
done
from
this
part
of
the
product.
A
It
just
can't
be
done
from
this.
Ui
f
would
be
too
many
users
are
unable
to
complete
the
job.
Experience
is
viewed
as
extremely
bad
and
extremely
difficult
to
complete
yeah.
You
can
make
an
argument
for
that.
But
overall,
if
I
don't
run
into
that
problem
of
group
invites
and
I'm
just
removing
users,
I
think
you
could
argue
that
this
is
more
on
the
side
of
a
d
where
I
actually
can
remove
users.
A
The
the
alert
dialogue
that
pops
up
when
I'm
removing
a
user
does
tell
me
that
this
is
final
and
thorough,
but
I
definitely
think
there
are
a
lot
of
things
on
here
that
can
make
investigating
and
increase
making
investigating
easier
increase.
The
user's
confidence
increase
their
reassurance
after
an
action
is
taken
that
this
is
covering
everything
that
they're
looking
for
in
terms
of
being
compliant
to
their
company's
policies.