Mark SCIM-created accounts as provisioned by group
What does this MR do?
Related to #283935 (closed)
Mark all SCIM created accounts with the group they were provisioned by. This helps us identify accounts that were created by a group via SCIM automation versus accounts created manually by a user. We can use this information later to drive behavior through the app.
Database
Migrate
== 20201123161611 AddProvisionedByGroupToUserDetails: migrating ===============
-- column_exists?(:user_details, :provisioned_by_group_id)
-> 0.0018s
-- add_column(:user_details, :provisioned_by_group_id, :integer, {:limit=>8})
-> 0.0010s
-- transaction_open?()
-> 0.0000s
-- foreign_keys(:user_details)
-> 0.0031s
-- execute("ALTER TABLE user_details\nADD CONSTRAINT fk_190e4fcc88\nFOREIGN KEY (provisioned_by_group_id)\nREFERENCES namespaces (id)\nON DELETE CASCADE\nNOT VALID;\n")
-> 0.0016s
-- execute("SET statement_timeout TO 0")
-> 0.0002s
-- execute("ALTER TABLE user_details VALIDATE CONSTRAINT fk_190e4fcc88;")
-> 0.0023s
-- execute("RESET ALL")
-> 0.0002s
-- transaction_open?()
-> 0.0000s
-- index_exists?(:user_details, :provisioned_by_group_id, {:name=>"index_user_details_on_provisioned_by_group_id", :algorithm=>:concurrently})
-> 0.0022s
-- add_index(:user_details, :provisioned_by_group_id, {:name=>"index_user_details_on_provisioned_by_group_id", :algorithm=>:concurrently})
-> 0.0031s
== 20201123161611 AddProvisionedByGroupToUserDetails: migrated (0.0244s) ======
Rollback
== 20201123161611 AddProvisionedByGroupToUserDetails: reverting ===============
-- remove_foreign_key(:user_details, {:column=>:provisioned_by_group_id})
-> 0.0054s
-- transaction_open?()
-> 0.0000s
-- indexes(:user_details)
-> 0.0023s
-- remove_index(:user_details, {:algorithm=>:concurrently, :name=>"index_user_details_on_provisioned_by_group_id"})
-> 0.0012s
-- column_exists?(:user_details, :provisioned_by_group_id)
-> 0.0020s
-- remove_column(:user_details, :provisioned_by_group_id)
-> 0.0004s
== 20201123161611 AddProvisionedByGroupToUserDetails: reverted (0.0155s) ======
Queries
NOTE: The explain analyze were only run on my local GDK which doesn't have a lot of data. The column provisioned_by_group_id
doesn't yet exist in prod so it's not possible to run the explain analyze in #database-lab. For example, the explains below show a sequence scan on user_details
, even though there is clearly an index on provisioned_by_group_id
.
Group#provisioned_user_details
:
Explain: https://explain.depesz.com/s/XSWU
SELECT
"users".*
FROM
"users"
INNER JOIN "user_details" ON "users"."id" = "user_details"."user_id"
WHERE
"user_details"."provisioned_by_group_id" = 90
Group#provisioned_users
:
Explain: https://explain.depesz.com/s/ewy5
SELECT
"user_details".*
FROM
"user_details"
WHERE
"user_details"."provisioned_by_group_id" = 90
User.provisioned_by_group
:
Explain: https://explain.depesz.com/s/G5LW
SELECT
"user_details".*
FROM
"user_details"
WHERE
"user_details"."user_id" = 1
LIMIT 1
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry - [-] Documentation (if required)
-
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. - [-] Tested in all supported browsers
- [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
- [-] Label as security and @ mention
@gitlab-com/gl-security/appsec
- [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
- [-] Security reports checked/validated by a reviewer from the AppSec team