自适应用户管理 [英] Adaptive User Management

问题描述

我已经基于Google的人员查看器"模板构建了一个评论应用程序，该模板允许管理人员为其直接报告创建和编辑评论.

I have built a review app based on Google's "people viewer" template that allows managers to create and edit reviews for their direct reports.

• 该应用程序包含目录模型以及三个角色:管理员，HR，最终用户.
• 该应用程序包含一个用户设置模型，该模型允许创建和存储类似于人际交往能力"模板的用户设置.
• 该应用程序包含一个评论模型，该模型将包含每位员工的评论.由于一个员工可以进行多个评论，因此这将是一对多的关系，可以链接到目录模型，也可以链接到用户设置模型.

评论应由经理的经理链可读.为此，我创建了一个服务器脚本，假设EmployeeEmail将另外存储在审阅中.但是也许还有更好的选择?

The reviews should be readable by managers chain of manager. For this I have created a server script, assuming that the EmployeeEmail will be additionally stored in the review. But maybe there is a better alternative?

function getDirectReportsChainForUser_(query) {
  var userQuery = app.models.Directory.newQuery();
  userQuery.filters.PrimaryEmail._equals = query.parameters.PrimaryEmail;

  userQuery.prefetch.DirectReports._add();
  userQuery.prefetch.DirectReports.DirectReports._add();

  var users = userQuery.run();

  if (users.length === 0) {
   return [];
  }

  var user = users[0];
  var directs = user.DirectReports;
  var records = [];
  for (var i = 0; i <= directs.length; i++) {
    records.push(directs[i].PrimaryEmail);
  }
  // The following lines are based on the asumption that the EmployeeEmail 
  // will be stored in the review in case that there is no better alternative. 
  //The question that then remains is how to recursively add the DirectReports 
  //of the DirectReports to the array???
  var reviewQuery = app.models.Reviews.newQuery();
  reviewQuery.filters.EmployeeEmail._in = records; 
 return reviewQuery.run();
}

经理应该能够定义一个或多个代表是否也可以阅读其单位的评论.我的想法是通过目录和审阅模型之间的多对多关系来解决此问题，但是我不确定如何实现它?

The manager should be able to define whether one or more of his deputies can read the reviews for his unit, too. My idea was to solve this issue through a many-to-many relation between the directory and review model, but I am not sure how to implement it?

此外，一旦经理或其代理人离职，管理员就应该有可能解除连接并将评论重新连接到后继者.因此，我正在考虑在管理页面中集成多选.这可行吗?

Furthermore, once a manager or his deputy departures, it should be possible for the Admin to dissolve the connection and to reconnect the reviews to a successor. Therefore I was thinking about integrating a multiselect in the admin page. Would this be feasible?

推荐答案

在这里，我至少看到两个不同的问题:

Here I see at least two distinct questions:

除了将主要电子邮件字段添加到数据模型之外，还有更好的方法将目录模型的记录与普通数据模型相关联

is there better way to associate directory model's record and ordinary data model than just adding primary email field to the data model

不，目前无法在数据(SQL/驱动器表)和目录模型之间建立关系.

Nope, at this time it is not possible to establish relations between data (SQL/Drive Tables) and directory models.

如何递归获取用户的所有直接报告

how to recursively get all direct reports for a user

App Maker的目录模型是 G Suit Admin SDK的目录API的包装仅展示其强大功能的一小部分.添加目录模型时，App Maker会自动插入相应的Apps脚本高级服务:

App Maker's Directory Model is a wrapper on top of G Suit Admin SDK's Directory API that exposes just a small subset of its powerful features. When you add Directory Model App Maker automatically plugs in correspondent Apps Script advance service:

由于我们已经配置了Directory API，因此我们可以释放其全部功能，并且只需一次调用即可轻松获取所有经理的下属(如果需要支持分页，则可以多个).为此，我们将使用 Users.List 具有managerId查询参数的API方法(唯一允许我们查询树中所有下属的方法).以下是从完整的搜索文档(没有这些参数的查询将无法正常工作或无法以我们所需的方式工作):

Since we already have configured Directory API we can unleash its full power and easily fetch all manger's subordinates with a single call (or multiple if you have a need to support paging). In order to do that we will use Users.List API method with managerId query parameter (the only one that allows us to query all subordinates down the tree). Here are reference for the minimal set of search query parameters quoted from the full search documentation (without those parameters query would not work or wouldn't work in a way we need):

• managerId :直接或在管理链上的用户经理的ID.
• 域:域名.使用此字段只能从一个域获取字段.要返回客户帐户的所有域，请改用customer查询参数. customer或domain参数必须提供.
• viewType :是否获取用户的仅管理员或域范围内的公共视图.有关更多信息，请参阅将用户作为非管理员(admin_view是默认值，因此我们需要用domain_view覆盖它).
• 查询:用于搜索用户字段的查询字符串.有关构造用户查询的更多信息，请参见搜索用户.

• managerId: The ID of a user's manager either directly or up the management chain.
• domain: The domain name. Use this field to get fields from only one domain. To return all domains for a customer account, use the customer query parameter instead. Either the customer or the domain parameter must be provided.
• viewType: Whether to fetch the administrator-only or domain-wide public view of the user. For more information, see Retrieve a user as a non-administrator (admin_view is default value so we need to override it with domain_view).
• query: Query string for searching user fields. For more information on constructing user queries, see Search for Users.

/**
 * Fetches all reviews associated with all subordinate employees (both direct
 * and indirect reports).
 */
function getAllReportsEmails(managerId) {
  var emails = [];
  var result = AdminDirectory.Users.list({
    domain: 'ENTER HERE YOUR DOMAIN (exapmle.com)',
    query: 'managerId=' + managerId,
    viewType: 'domain_public',
    maxResults: 100
  });

  if (result.users) {
    emails = result.users.map(function (user) {
      return user.primaryEmail;
    });
  }

  return emails;
}


/**
 * Fetches all reviews associated with all subordinate employees (both direct
 * and indirect reports).
 */
function getAllReportsReviewsForManager_(query) {
  var userQuery = app.models.Directory.newQuery();
  // For better security I would recommend to use
  // Session.getActiveUser().getEmail() instead of parameter
  // passed from the client.
  userQuery.filters.PrimaryEmail._equals = Session.getActiveUser().getEmail();

  var users = userQuery.run();

  if (users.length === 0) {
   return [];
  }

  var manager = users[0];
  var managerId = manager._key;
  var allReportsEmails = getAllReportsEmails(managerId);

  var reviewQuery = app.models.Reviews.newQuery();
  reviewQuery.filters.EmployeeEmail._in = allReportsEmails; 

  return reviewQuery.run();
}

这篇关于自适应用户管理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！