关于Liferay的deactivate user的研究

当用户在控制面板中选择deactivate user的时候：

它会去走到EditUserAction的processAction()方法，在判断清楚动作是Constants.DEACTIVATE之后，它会调用deleteUser()方法：

这段代码如下：

protected void deleteUsers(ActionRequest actionRequest) throws Exception {
            String cmd = ParamUtil.getString(actionRequest, Constants.CMD);
            long[] deleteUserIds = StringUtil.split(
                  ParamUtil.getString(actionRequest, "deleteUserIds"), 0L);
            for (int i = 0; i < deleteUserIds.length; i++) {
                  if (cmd.equals(Constants.DEACTIVATE) ||
                        cmd.equals(Constants.RESTORE)) {
                        int status = WorkflowConstants.STATUS_APPROVED;
                        if (cmd.equals(Constants.DEACTIVATE)) {
                              status = WorkflowConstants.STATUS_INACTIVE;
                        }
                        UserServiceUtil.updateStatus(deleteUserIds[i], status);
                  }
                  else {
                        UserServiceUtil.deleteUser(deleteUserIds[i]);
                  }
            }
      }

可以发现deleteUser不仅仅是只删除用户，它是几种情况的糅合体，不仅仅是Delete,而且Deactivate,Restore都会走到这个方法中，我们因为是DEACTIVATE,所以走的分支是第16行，最终它先获取我们操作的用户的id,然后会调用UserServiceUtil.updateStatus(deleteUserIds[i]，status)方法：

这个方法接下来会利用动态代理机制调用UserServiceImpl的updateStatus(long userId,int status)方法：

这个方法从调试信息中可以看到，我们要操作的用户id是12113，然后状态位要改成5，这个5应该是对应的Deactivate。

最终，这个方法会调用UserLocalServiceImpl.updateStatus(userId,status)方法：

它其实是对用户表User_进行了操作，并且吧其中UserId 为12113（Jessica这个用户）的状态为改成了5(deactivate):

这个表的DDL如下：

特别注意第2个字段(UserId)和最后一个字段(Status).

而当我们进行操作的时候，很容易从Hypersonic数据库的log中看到我们更新这个字段的操作（不过不明白为什么Update要拆分2条，一条是Delete,一条是insert)

总结：

(1)其实当Deactivate用户时候，并没有真正让用户信息从User_表中删除，仅仅是吧Status位置改成Deactivate.

(2)用户的Restore,Deactivate,Delete操作都合并在了deleteUser()方法中。

(3)Hypersonic操作很不智能，Update方法必须被拆分为一个Delete加一个Insert方法