►
From YouTube: Demo !27058 /Change license classification dropdown selection to `deny` and `allow` in policy tab UI
Description
Video demo for :
https://gitlab.com/gitlab-org/gitlab/-/issues/198340
A
I'm
going
to
give
a
quick
demo
of
the
classifications
compliance
classification,
name,
changes
that
have
happened
in
the
UI
at
a
high
level,
we're
essentially
changing
the
convention
of
approved
and
blacklisted,
to
allowed
and
denied,
and
in
the
cases
where
we
have
in
the
UI,
where
we
want
to
take
action
on
the
license
policy,
the
actionable
terminology
is
allow
or
deny.
So
if
you
mark
a
license
policy
as
a
lot
it.
If
you
mark
it
to
allow
it,
then
the
new
state
will
be
allowed.
A
If
he
marked
to
deny
it,
the
new
state
will
be
denied.
So
we
had
some
of
that
already
implement
in
the
UI,
but
this
issue
is
a
follow
up
to
fix
that
in
other
areas
of
the
UI
like
the
modal's
and
the
drop
downs
for
the
I
guess
what
used
to
be
called
a
license
management
screen
so
we'll
go
through.
That
first
thing
we'll
do
is
to
get
a
quick
look
at
the
actual
merge
request
to
look
at
what
was
changed
and
the
refactor
is
very
simple.
A
A
So
now
I'm
going
to
go
through
a
demo
of
this
branch
that
that
represents
this.
Mr,
so,
let's
see
here
we
have
our
local
instance
and
I'll
refresh
the
page
here,
and
this
is
the
license.
Compliance
page
as
mewed
has
a
maintainer
type
role.
If
you
go
to
policies,
this
is
essentially
what
we've
changed
here
to
have,
allow
and
denied
representing
it
as
the
current
state
of
the
license
policy
and
then
and
then
in
the
drop-down,
giving
them
the
option
of
marking
or
taking
the
action
of
allowing
it
or
denying
this
license
policy.
A
So
that
was
the
subtle
difference.
Allow
and
deny
should
be
the
strings
that
represent
taking
action
on
this
on
the
license
policy
and
allowed
and
denied
represent
the
current
state
after
an
action
was
taken.
So
this
is
the
maintainer
view
and
then
I
also
have
here
not
incognito
window.
Just
so
I
could
log
in
as
a
different
user
in
a
different
session,
a
non
maintainer
user
role
and
you'll
still
see
here
that
we
have
allowed
and
denied
as
expected
another
place,
we
see
these
states
are
in
merit
requests.
A
So
here's
a
merge
request
for
the
same
project,
I'm
going
to
refresh
the
page.
So
we
know
it's
working
so
you'll
see
we'll
wait
for
the
license
compliance
report
or
the
EM.
Our
widget
here
to
load
you'd
spend
it
out,
and
you
could
see
here
now
we're
taking
action
on
this.
So
the
checkbox
checkmark
means
that
this
license
is
currently
allowed.
Now
we
wanted
to
die,
it
is
where
we
see
the
text
from
the
modal
get
to
deny
it
and
then
you'll
see
after
it's
been
denied.
A
You
want
to
take
action
on
it
if
you
want
to
allow
it
so
now
it's
allowed
once
the
checkbox
changes.
This
means
that
the
grey
circle
means
that
no
action
has
been
taken
for
that
license.
So
what
we
see
here
are
licenses
that
are
detected
as
per
the
license.
Scan
but
doesn't
necessarily
have
a
license
policy
set
for
it.
Yet
so
we
click
on
it
now
you
see
that
we
can
either
deny
or
allow
it,
and
that
in
turn,
creates
a
new
license
policy
for
that
license.
That
was
protected,
but
had
no
policy
for
so.
A
If
we
go
back
to
license
compliance,
you'll
see
the
new
up
here.
This
new
policy
is
added
as
allowed
and
that's
pretty
much
it
so
really.
This
merchants
request
was
this
demo
was
to
show
that
the
changes
in
the
merge
request
didn't
break
anything
as
far
as
we
know,
and
it
was
only
centered
around
renaming
the
costume
things-
the
values
that
the
constants
represent
have
not
changed.
So
I
wanted
to
point
that
out.
A
So
the
follow-up
issues
to
finish
cleaning
this
up
would
be
to
either
we
do
have
a
new
license.
Compliance
endpoint,
that's
created
as
part
of
the
new
license
compliance
work
that
Moe
had
worked
on
or
we
could
update
the
legacy
end
point
which
I
would
advise
against
too,
because
that
we
are
deprecating
that
so
the
ideal
Pro
follow-up
issue
would
be
to
have
the
license
management
screen.
The
one
with
the
policies
over
here
migrated
to
use
the
new
license.
A
Compliance
endpoint,
which
has
the
updated,
allowed
denied
statuses
for
the
license
policy,
and
it
was
kind
of
a
mouthful,
but
hopefully
that
makes
sense
so
with
that
said,
as
far
as
we
know,
we
just
cleaned
up
the
codebase
in
terms
of
the
variable
names
to
make
it
a
little
bit
clearer
and
consistent
yeah,
and
then
you
updating
the
unit
tests.
All
we
really
do
with
the
unit
tests
to
make
sure
they
spoke
pass,
is
just
search
and
replace,
but
renamed
the
constant
names
they
see
approved
to
allowed
the
unit
test.