Use feature for admin #17444

kbrock · 2018-05-18T20:32:36Z

Problem:

Users can not create a custom group with admin privileges.
Our best practices say to create a custom group and not use the included Evm ones.
The reason for this request most often is focused on reporting, but also focuses on miq_request privileges.

https://bugzilla.redhat.com/show_bug.cgi?id=1090627
https://bugzilla.redhat.com/show_bug.cgi?id=1545401
Use {report,request}_admin_user? manageiq-ui-classic#3993
use request_admin_user? manageiq-api#385
Extra reference, but not addressed: https://bugzilla.redhat.com/show_bug.cgi?id=1508490
scroll down for ui changes.

Before:

We use the admin's name (admin, tenant admin, and super admin) to grant extra privileges. This is determined using MiqUserRole#admin_user?.
Tenant admin checks are in place to prevent the user from creating an administrator or super administrator (and essentially escalating privileges).
NOTE: special privileges of the administrator role has been whittled down to elevated report and miq_request privileges.

After:

super-administrator role (i.e.: user admin) now uses the the existing everything miq_product_feature to grant the special privilege.
Report functionality previously protected by admin_user? now uses the miq_product_feature miq_report_superadmin to grant special privileges. (This is needed for chargeback and other reports). Introduced report_admin_user? for transition.
MiqRequest functionality previously protected by admin_user? now uses miq_product feature miq_request_superadmin
The administrator role checks admin_user? is deprecated and no longer used. Essentially, this role has been removed.
The tenant-administrator checks have been simplified. Now, a super admin is the only one able to create a super admin.

Future work:

The code currently prevents users from viewing other groups. This needs to be fixed in admin.
A bunch of these checks could be moved further into Rbac.
There are quite a few report / report result checks that are tangled and non trivial to move to rbac.
There are 2 types of checks for report results - tread carefully.

NickLaMuro

I think this looks fine, but admittedly I am not the best person to be making the final say.

I think my only real gripe is that MiqProductFeature seems like a weird place for this to live instead of MiqUserRole, specifically from a name standpoint. I can much more easily understand that "admin" and "superadmin" are roles versus "product features", but maybe that is just me.

There might be implementation details that make it more desirable to put this in MiqProductFeature versus MiqUserRole, so not really worth holding this up for, just an observation.

NickLaMuro · 2018-05-18T20:46:14Z

app/models/miq_group.rb

-  def self.with_current_user_groups(user = nil)
-    current_user = user || User.current_user
-    current_user.admin_user? ? all : where(:id => current_user.miq_group_ids)
+  # paralell to User.with_groups - only show these groups


Typo: parallel

NickLaMuro · 2018-05-18T20:50:40Z

app/models/miq_user_role.rb

+    where.not(:id => MiqUserRole.joins(:miq_product_features)
+                                .where(:miq_product_features => {:identifier => identifier})
+                                .select(:id)
+             )


NickLaMuro · 2018-05-18T20:53:43Z

app/models/user.rb

@@ -25,14 +25,15 @@ class User < ApplicationRecord
  belongs_to :current_group, :class_name => "MiqGroup"
  has_and_belongs_to_many :miq_groups
  scope      :superadmins, lambda {
-    joins(:miq_groups => :miq_user_role).where(:miq_user_roles => {:name => MiqUserRole::SUPER_ADMIN_ROLE_NAME })
+    joins(:miq_groups => {:miq_user_role => :miq_product_features})
+      .where(:miq_product_features => {:identifier => MiqProductFeature::SUPER_ADMIN_FEATURE })


First off, totally fine with this query, and it probably doesn't need to change.

But am kinda curious where it is being used. Since we aren't setting a .select on this, do we get all the columns back on this, or does Rails always add a table_name.* by default instead of just a SELECT *?

(might be the former now that I think about it)

Anyway, you really aren't changing how this worked much before, so you probably don't have to worry about it.

NickLaMuro · 2018-05-18T20:56:55Z

lib/rbac/filterer.rb

-        if user_or_group.disallowed_roles
-          scope = scope.with_allowed_roles_for(user_or_group)
+        # hide creating admin group / roles from tenant administrators
+        if !user_or_group.miq_user_role&.admin_user?


<rant> God... this is the ugliest syntax addition to Ruby I have ever seen... bleh </rant>

More of a serious, but minor question: Is there an extra query being hit here now by calling out to miq_user_role?

yes. But I figure features need to be brought back for the rest of the UI, so I've been looking the other way

NickLaMuro · 2018-05-18T21:36:23Z

app/models/user.rb

-  def self.with_current_user_groups(user = nil)
-    user ||= current_user
-    user.admin_user? ? all : includes(:miq_groups).where(:miq_groups => {:id => user.miq_group_ids})
+  # paralell to MiqGroup.with_groups - only show users with these groups


Typo: parallel

NickLaMuro · 2018-05-18T21:48:45Z

app/models/user.rb

@@ -171,7 +175,8 @@ def self.lookup_by_identity(username)
  end

  def self.authorize_user(userid)
-    return if userid.blank? || admin?(userid)
+    # Don't authorize users with userid == "admin"
+    return if userid.blank? || userid == "admin"


Few things:

At the very least, can we .freeze this string? Or use an existing constant?

Is there a reason this doesn't go through MiqUserRole or MiqProductFeature? I guess for simplicity and reducing risk? (cool with that being the case, just making sure)

NickLaMuro · 2018-05-18T21:52:37Z

lib/rbac/filterer.rb

        end

-        if MiqUserRole != klass
+        if MiqUserRole == klass
+          scope


What is the rational behind adding this conditional in and pushing scope_by_ids inside the else? Just don't see the context/rational from the diff.

think I'll roll it back - yea, probably an unneeded change

Not sure you need to go that far, was just curious what the rational was.

NickLaMuro · 2018-05-18T21:56:51Z

app/models/miq_group.rb

@@ -60,8 +60,8 @@ def settings=(new_settings)
    super(indifferent_settings)
  end

-  def self.with_allowed_roles_for(user_or_group)
-    includes(:miq_user_role).where.not({:miq_user_roles => {:name => user_or_group.disallowed_roles}})
+  def self.with_roles_excluding(disallowed_roles)


Are all of the callers for this updated? I don't see any changed here.

Thankfully these ones got hidden due to recent commits. Just noticed where these were being used, so this question and others like it can be ignored.

NickLaMuro · 2018-05-18T21:57:14Z

app/models/miq_user_role.rb

-
-  def self.with_allowed_roles_for(user_or_group)
-    where.not(:name => user_or_group.disallowed_roles)
+  def self.with_roles_excluding(disallowed_roles)


Are all of the callers for this updated? I don't see any changed here. (repeat question)

NickLaMuro · 2018-05-18T21:57:32Z

app/models/user.rb

@@ -50,8 +50,8 @@ class User < ApplicationRecord

  scope :with_same_userid, ->(id) { where(:userid => User.find(id).userid) }

-  def self.with_allowed_roles_for(user_or_group)
-    includes(:miq_groups => :miq_user_role).where.not(:miq_user_roles => {:name => user_or_group.disallowed_roles})
+  def self.with_roles_excluding(disallowed_roles)


Are all of the callers for this updated? I don't see any changed here. (repeat question)

kbrock · 2018-05-23T20:22:12Z

@bascar / @gtanzillo new thoughts:

Currently we have a single "administrator" Role. the name of the role makes it an admin.

This is not transferrable to other roles, so instead of using name, we're going to use a product feature. Also, we are getting away from a single admin concept.

If you look at the product features granted to admins, they fall in 2 different areas. It makes sense to split up the admin role into 2 types of functionality: reports and requests.

Additionally, there currently are provisions to prevent tenant admins from creating an administrator user. While it makes sense to limit creation of a super admin, the admin does not have significant added privileges, so this no longer seems necessary. Instead it prevents non super admins from creating super admins.

Current functionality granted to Administrators

NOTE: While super administrators do get all administrator functionality, they are different roles

reports
- advanced search (delete filters, global search)
- other user's saved reports
- export other reports
- fetch other user's saved reports
- other user's report results
- other user's time profiles
- other user's charge back reports
- other groups' reports
- report results from other users
- overwrite on report imports
- view other user groups / (potential create user issue)
requests
- delete other user's miq_request messages
- find service requests from other users (API)
- find requests from other users
- provision requests from other users
- automation requests from other users

Not sure if this can address

https://bugzilla.redhat.com/show_bug.cgi?id=1508490

kbrock · 2018-05-25T17:27:09Z

This made the following changes:

move hardcoded admin logic over to rbac

the role name used to determine if it were https://bugzilla.redhat.com/show_bug.cgi?id=1090627

Admins have 2 types of escalated privileges report and request This separates the types (with 2 different product features)

miq-bot · 2018-05-29T15:23:20Z

Checked commits kbrock/manageiq@9c9a52f~...f6c02e8 with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0
14 files checked, 0 offenses detected
Everything looks fine. 🏆

gtanzillo

This looks awesome 👍 I just have the one small question/comment

gtanzillo · 2018-05-30T19:55:42Z

app/models/miq_group.rb

@@ -15,11 +15,11 @@ class MiqGroup < ApplicationRecord
  has_many   :miq_widget_sets, :as => :owner, :dependent => :destroy
  has_many   :miq_product_features, :through => :miq_user_role

-  virtual_column :miq_user_role_name, :type => :string,  :uses => :miq_user_role
+  virtual_delegate :name, :to => :miq_user_role, :allow_nil => true, :prefix => true


How come you changed this to just :name? It seems ambiguous as it can be misconstrued as the name of the group when it's really the name of the groups role.

This did not change

The :name refers to Role#name. The prefix => true tacks on the association name so the attribute name will be called miq_user_role_name (same as it originally was)

ZitaNemeckova · 2018-06-01T09:35:05Z

This broke UI master :)

1) ReportController#schedule_edit reset rbac testing
     Failure/Error: users_in_current_groups = User.with_current_user_groups.distinct.sort_by { |u| u.name.downcase }
     
     NoMethodError:
       undefined method `with_current_user_groups' for #<Class:0x000000000a44fa98>
     # ./app/controllers/application_controller.rb:764:in `build_user_emails_for_edit'
     # ./app/controllers/report_controller/schedules.rb:433:in `schedule_build_edit_screen'
     # ./app/controllers/report_controller/schedules.rb:252:in `schedule_edit'
     # ./spec/controllers/report_controller/schedules_spec.rb:21:in `block (3 levels) in <top (required)>'
  2) MiqPolicyController::Alerts test click on toolbar button alert edit
     Failure/Error: expect(response.status).to eq(200)
     
       expected: 200
            got: 500
     
       (compared using ==)
     # ./spec/controllers/miq_policy_controller/alerts_spec.rb:118:in `block (4 levels) in <top (required)>'
  3) MiqPolicyController::Alerts test click on toolbar button alert copy
     Failure/Error: expect(response.status).to eq(200)
     
       expected: 200
            got: 500
     
       (compared using ==)
     # ./spec/controllers/miq_policy_controller/alerts_spec.rb:123:in `block (4 levels) in <top (required)>'
  4) MiqPolicyController::Alerts alert edit #alert_build_edit_screen it should select correct record when editing an existing alert
     Failure/Error: users_in_current_groups = User.with_current_user_groups.distinct.sort_by { |u| u.name.downcase }
     
     NoMethodError:
       undefined method `with_current_user_groups' for #<Class:0x000000000a44fa98>
     # ./app/controllers/application_controller.rb:764:in `build_user_emails_for_edit'
     # ./app/controllers/miq_policy_controller/alerts.rb:288:in `alert_build_edit_screen'
     # ./spec/controllers/miq_policy_controller/alerts_spec.rb:46:in `block (5 levels) in <top (required)>'
  5) MiqPolicyController::Alerts alert edit #alert_build_edit_screen it should skip id when copying all attributes of an existing alert
     Failure/Error: users_in_current_groups = User.with_current_user_groups.distinct.sort_by { |u| u.name.downcase }
     
     NoMethodError:
       undefined method `with_current_user_groups' for #<Class:0x000000000a44fa98>
     # ./app/controllers/application_controller.rb:764:in `build_user_emails_for_edit'
     # ./app/controllers/miq_policy_controller/alerts.rb:288:in `alert_build_edit_screen'
     # ./spec/controllers/miq_policy_controller/alerts_spec.rb:40:in `block (5 levels) in <top (required)>'
  6) ApplicationController#build_user_emails_for_edit listing users's emails which belongs to current user's groups and some of them was already selected
     Failure/Error: users_in_current_groups = User.with_current_user_groups.distinct.sort_by { |u| u.name.downcase }
     
     NoMethodError:
       undefined method `with_current_user_groups' for #<Class:0x000000000a44fa98>
     # ./app/controllers/application_controller.rb:764:in `build_user_emails_for_edit'
     # ./spec/controllers/application_controller_spec.rb:291:in `block (4 levels) in <top (required)>'
     # ./spec/controllers/application_controller_spec.rb:290:in `block (3 levels) in <top (required)>'
  7) ApplicationController#build_user_emails_for_edit finds users with groups which belongs to current user's groups
     Failure/Error: user_ids = User.with_current_user_groups.collect(&:userid)
     
     NoMethodError:
       undefined method `with_current_user_groups' for #<Class:0x000000000a44fa98>
     # ./spec/controllers/application_controller_spec.rb:264:in `block (3 levels) in <top (required)>'
  8) ApplicationController#build_user_emails_for_edit listing users's emails which belongs to current user's groups
     Failure/Error: users_in_current_groups = User.with_current_user_groups.distinct.sort_by { |u| u.name.downcase }
     
     NoMethodError:
       undefined method `with_current_user_groups' for #<Class:0x000000000a44fa98>
     # ./app/controllers/application_controller.rb:764:in `build_user_emails_for_edit'
     # ./spec/controllers/application_controller_spec.rb:273:in `block (4 levels) in <top (required)>'
     # ./spec/controllers/application_controller_spec.rb:272:in `block (3 levels) in <top (required)>'

Fixed in ManageIQ/manageiq-ui-classic#4023 (Merged)

Fixes mangeiq-ui-classic master failures Introduced by ManageIQ/manageiq#17444

We introduced feature miq_request_superadmin in f6c02e8 / ManageIQ#17444 The feature miq_request_approval already existed. Merging the 2 together. This fixes an inconsistency between API and UI The issue existed before this feature was introduced so this works with 17444 to fix the BZ ManageIQ#17444 https://bugzilla.redhat.com/show_bug.cgi?id=1608554

In ManageIQ#17444 and related PRs References to generic admin_user and used request_admin_user/others This removes the method for good

We introduced feature miq_request_superadmin in f6c02e8 / ManageIQ#17444 The feature miq_request_approval already existed. Merging the 2 together. This fixes an inconsistency between API and UI The issue existed before this feature was introduced so this works with 17444 to fix the BZ ManageIQ#17444 https://bugzilla.redhat.com/show_bug.cgi?id=1608554

In ManageIQ#17444 and related PRs References to generic admin_user and used request_admin_user/others This removes the method for good

We introduced feature miq_request_superadmin in f6c02e8 / ManageIQ#17444 The feature miq_request_approval already existed. Merging the 2 together. This fixes an inconsistency between API and UI The issue existed before this feature was introduced so this works with 17444 to fix the BZ ManageIQ#17444 https://bugzilla.redhat.com/show_bug.cgi?id=1608554

The fix here simply matches up the `if` checks used in: - `Api::ReportsController#reports_search_conditions` - `MiqReport.for_user` to both use `User#report_admin_user?` * * * Further background info: This bug is the result of a collision between the following two PRs: - ManageIQ/manageiq#15472 - ManageIQ/manageiq#17444 The first PR, ManageIQ/manageiq#15472, introduces: `Api::ReportsController#reports_search_conditions` Which uses `unless User.current_user.admin?` to check if it should use the `where_clause` from the `MiqReport.for_user` for the search conditions (passed into a `ActiveRecord` `.where` farther up the stack). The idea for this initial check is building this where clause only makes sense if it isn't an `all`, otherwise where it is used will cause an error in Postgres syntax because of `... WHERE ()` being passed This, however, doesn't match the `user.admin_user?`(at the time of ManageIQ/manageiq#15472) check that is done in `.for_user` method, which means it would be called for users that don't match the `admin` username, but still are part of either of the following roles - `"EvmRole-super_administrator"` - `"EvmRole-administrator"` The bug in question: https://bugzilla.redhat.com/show_bug.cgi?id=1650531 tested this with a custom role, which doesn't match either of those two roles, so the `User#admin?` check and `User#admin_user?` check happened to be equivalent in `5.9` (see comment ManageIQ#4 in BZ link), but not `5.10`. But, if the replication steps had instead said to: - Create a user, "User1", that is part of the "EvmGroup-administrator" group This would have also failed in the same way on `5.9` as it does on `5.10` currently. This fails on 5.10, though, because in ManageIQ/manageiq#17444, the `admin_user?` method changes to `report_admin_user?`, and it's functionality also now checks if the role is valid for querying the group role's product features the user has access to, and it only has an eject for the role that happens to be `admin?`. Meaning that the `admin` "super user" still has no problem with this query, but any other user that could still count as a `report_admin_user?` would (both users in the `EvmGroup-administrator` role and just having the proper features enabled)

The fix here simply matches up the `if` checks used in: - `Api::ReportsController#reports_search_conditions` - `MiqReport.for_user` to both use `User#report_admin_user?` * * * Further background info: This bug is the result of a collision between the following two PRs: - ManageIQ/manageiq#15472 - ManageIQ/manageiq#17444 The first PR, ManageIQ/manageiq#15472, introduces: `Api::ReportsController#reports_search_conditions` Which uses `unless User.current_user.admin?` to check if it should use the `where_clause` from the `MiqReport.for_user` for the search conditions (passed into a `ActiveRecord` `.where` farther up the stack). The idea for this initial check is building this where clause only makes sense if it isn't an `all`, otherwise where it is used will cause an error in Postgres syntax because of `... WHERE ()` being passed This, however, doesn't match the `user.admin_user?`(at the time of ManageIQ/manageiq#15472) check that is done in `.for_user` method, which means it would be called for users that don't match the `admin` username, but still are part of either of the following roles - `"EvmRole-super_administrator"` - `"EvmRole-administrator"` The bug in question: https://bugzilla.redhat.com/show_bug.cgi?id=1650531 tested this with a custom role, which doesn't match either of those two roles, so the `User#admin?` check and `User#admin_user?` check happened to be equivalent in `5.9` (see comment ManageIQ#4 in BZ link), but not `5.10`. But, if the replication steps had instead said to: - Create a user, "User1", that is part of the "EvmGroup-administrator" group This would have also failed in the same way on `5.9` as it does on `5.10` currently. This fails on 5.10, though, because in ManageIQ/manageiq#17444, the `admin_user?` method changes to `report_admin_user?`, and it's functionality also now checks if the role is valid for querying the group role's product features the user has access to, and it only has an eject for the role that happens to be `admin?`. Meaning that the `admin` "super user" still has no problem with this query, but any other user that could still count as a `report_admin_user?` would (both users in the `EvmGroup-administrator` role and just having the proper features enabled) Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1650531

kbrock added bug enhancement core core/rbac labels May 18, 2018

NickLaMuro reviewed May 18, 2018

View reviewed changes

kbrock mentioned this pull request May 21, 2018

[WIP] Remove hardcoded role privileges #17401

Closed

kbrock force-pushed the super_admin_feature branch from c3e49cc to e702067 Compare May 21, 2018 14:55

NickLaMuro mentioned this pull request May 21, 2018

Add MiqPreloader.polymorphic_preload_for_child_classes #17457

Closed

kbrock mentioned this pull request May 21, 2018

[WIP] Use feature for admin ManageIQ/manageiq-ui-classic#3968

Closed

kbrock mentioned this pull request May 24, 2018

Use {report,request}_admin_user? ManageIQ/manageiq-ui-classic#3993

Merged

kbrock force-pushed the super_admin_feature branch from e702067 to a3dfb97 Compare May 24, 2018 23:16

kbrock mentioned this pull request May 25, 2018

use request_admin_user? ManageIQ/manageiq-api#385

Merged

kbrock added 5 commits May 29, 2018 10:16

use :role instead of :name for role specs

9c9a52f

move disallowed_roles calculation to rbac

83ad831

User#with_current_user_groups -> with_groups

fd13a8a

move hardcoded admin logic over to rbac

use features to check if a role is an admin role

db76d96

the role name used to determine if it were https://bugzilla.redhat.com/show_bug.cgi?id=1090627

separate report and request admins

f6c02e8

Admins have 2 types of escalated privileges report and request This separates the types (with 2 different product features)

kbrock force-pushed the super_admin_feature branch from a3dfb97 to f6c02e8 Compare May 29, 2018 15:13

kbrock assigned gtanzillo May 29, 2018

gtanzillo approved these changes May 30, 2018

View reviewed changes

gtanzillo added this to the Sprint 87 Ending Jun 4, 2018 milestone May 31, 2018

gtanzillo merged commit f197805 into ManageIQ:master May 31, 2018

kbrock deleted the super_admin_feature branch May 31, 2018 19:51

ZitaNemeckova added a commit to ZitaNemeckova/manageiq-ui-classic that referenced this pull request Jun 1, 2018

Use with_groups instead of with_current_user_groups

a066286

Fixes mangeiq-ui-classic master failures Introduced by ManageIQ/manageiq#17444

ZitaNemeckova mentioned this pull request Jun 1, 2018

Use with_groups instead of with_current_user_groups ManageIQ/manageiq-ui-classic#4023

Merged

kbrock mentioned this pull request Jun 5, 2018

Explicitly shortcut "everything" for privileges #17526

Merged

kbrock mentioned this pull request Aug 8, 2018

Allow tenant admins to see all groups within the scope of their tenant #17768

Merged

kbrock mentioned this pull request Aug 13, 2018

Converge request user roles to match API and UI #17849

Merged

2 tasks

kbrock added a commit to kbrock/manageiq that referenced this pull request Aug 13, 2018

Remove admin_user

c3024bc

In ManageIQ#17444 and related PRs References to generic admin_user and used request_admin_user/others This removes the method for good

kbrock added a commit to kbrock/manageiq that referenced this pull request Aug 13, 2018

Remove admin_user

24a10b0

In ManageIQ#17444 and related PRs References to generic admin_user and used request_admin_user/others This removes the method for good

kbrock mentioned this pull request Aug 13, 2018

Remove admin_user? method #17850

Merged

kbrock added a commit to kbrock/manageiq that referenced this pull request Aug 13, 2018

Remove admin_user

c122274

In ManageIQ#17444 and related PRs References to generic admin_user and used request_admin_user/others This removes the method for good

kbrock added a commit to kbrock/manageiq that referenced this pull request Aug 13, 2018

Remove admin_user

b932836

In ManageIQ#17444 and related PRs References to generic admin_user and used request_admin_user/others This removes the method for good

kbrock mentioned this pull request Aug 14, 2018

[Gaprindashvili] Backport Admin report and request roles #17858

Closed

6 tasks

kbrock added a commit to kbrock/manageiq that referenced this pull request Aug 16, 2018

Remove admin_user

e94374b

In ManageIQ#17444 and related PRs References to generic admin_user and used request_admin_user/others This removes the method for good

NickLaMuro mentioned this pull request Dec 5, 2018

Fix invalid count query ManageIQ/manageiq-api#520

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use feature for admin #17444

Use feature for admin #17444

kbrock commented May 18, 2018 •

edited

Loading

NickLaMuro left a comment

NickLaMuro May 18, 2018

NickLaMuro May 18, 2018

NickLaMuro May 18, 2018

NickLaMuro May 18, 2018

NickLaMuro May 18, 2018

kbrock May 21, 2018

NickLaMuro May 18, 2018

NickLaMuro May 18, 2018

NickLaMuro May 18, 2018

kbrock May 21, 2018

NickLaMuro May 21, 2018

NickLaMuro May 18, 2018

NickLaMuro May 18, 2018

NickLaMuro May 18, 2018

NickLaMuro May 18, 2018

kbrock commented May 23, 2018 •

edited

Loading

kbrock commented May 25, 2018

miq-bot commented May 29, 2018

gtanzillo left a comment

gtanzillo May 30, 2018

kbrock May 31, 2018 •

edited

Loading

ZitaNemeckova commented Jun 1, 2018 •

edited

Loading

Use feature for admin #17444

Use feature for admin #17444

Conversation

kbrock commented May 18, 2018 • edited Loading

Problem:

Before:

After:

Future work:

NickLaMuro left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kbrock commented May 23, 2018 • edited Loading

Current functionality granted to Administrators

kbrock commented May 25, 2018

miq-bot commented May 29, 2018

gtanzillo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kbrock May 31, 2018 • edited Loading

Choose a reason for hiding this comment

ZitaNemeckova commented Jun 1, 2018 • edited Loading

kbrock commented May 18, 2018 •

edited

Loading

kbrock commented May 23, 2018 •

edited

Loading

kbrock May 31, 2018 •

edited

Loading

ZitaNemeckova commented Jun 1, 2018 •

edited

Loading