jkoudys / concrete5-lazyusermigrate Goto Github PK

Not implemented - createUser() is a function now, so it should be pretty straightforward to call this from a JSON execution. Should probably only take 3 lines to do.

New exporter for those who wish to use JSON instead.

This tool is intended for admins who want to keep one site's users synced with another, so it's a little silly to write the output to the page when they're most likely running this from cron. Replace this with c5 logging.

When you experience a PHP Parse error: syntax error, unexpected T_OBJECT_OPERATOR in /tools/userexport.json.php on line 7 update the code to this:

<?php
defined('C5_EXECUTE') || die('Access Denied.');
$nh = Loader::helper('navigation');
Loader::model('user_list');

$users = array();
$userList = new UserList;
$usersList = $userList->get();
foreach($usersList as $user) {
  $attributes = array();
  foreach(UserAttributeKey::getAttributes($user->getUserID()) as $key=>$uak) {
    if(is_string($uak)) {
      $attributes[] = array($key => $uak);
    } else if(is_object($uak)) {
      // Put special cases for custom attribute objects here
      switch(get_class($uak)) {
      default:
        break;
      }
    }
  }
  $groups = array();
  foreach((array) $user->getUserObject()->getUserGroups() as $gID=>$group) {
    $groups[] = array($gID => $group);
  }
  $users['Users'][] = array(
    'name' => $user->getUserName(),
    'email' => $user->getUserEmail(),
    'raw_pass' => $user->getUserPassword(),
    'attributes' => $attributes,
    'groups' => $groups );
}
header('Content-type: application/json');
echo json_encode($users);
exit;
?>

This was created as a fileset for /tools to ease in the writing and installation, but there are advantages to it being a single-page RESTful service. Were it a single page, it could be managed easily in the sitemap, as well as having (advanced) user permissions so certain users could be given the ability to run imports. This may be a more unusual case, since generally only the admin will be the one bulk-loading migrated users.

If the controller had a mini-router in on_start() to render GETs on the view (ie a GET will be equivalent to userexport.xml or userexport.json), a POST could update your existing users database by inserting new users that don't exist yet, and a PUT could either replace the users that exist in the 'to' site with the users from the 'from' (or potentially even disable all the old users, so you're swapping out your current user DB with the migrated one.)

URLs could be a bit nicer than when this is a tool too, e.g.
http://mysite.com/lum/users/json
a GET, would get all your users as json, and POST your users as:
http://mynewsite.com/lum/users/?xml=http://mysite.com/lum/users/xml

A really big plus would be that if this were a single page, I could put in configurable parameters to apply transforms to the imported/exported data. This would be a pretty easy way to say "always turn attribute 'name' to 'full_name'" or move them from group 'staff' to 'employee'. Aside from editing the code, there's not really a nice way to do this for /tools

Overall, it's a bit of work to do, and might actually be less usable to people than the tools, so I won't be committing much work to this right now.
could grab all your users as JSON

By default, groups should load by name, as we can assume if two groups of the same name exist in both systems, you'll want to keep the users in the same one. We'll also need an element off the root-element to map group ID to group ID.

e.g. if a user's in the "Staff" group on one site and the "Employee" group on the second, we'll need some way to map that. Ideally it should allow a mix of ID to name mappings, id to id, name to name and id to id.

If you have to export a lot of users (as in >100) you could be faced with a problem. The solution is to change the get parameter coming from /concrete/core/models/user_list.php

    // Returns an array of userInfo objects based on current filter settings
    public function get($itemsToGet = 100, $offset = 0) {

Optionally you can also specify the offset ofcourse.

<?php
defined('C5_EXECUTE') || die('Access Denied.');
$nh = Loader::helper('navigation');
Loader::model('user_list');

$users = array();
$userList = new UserList;
$usersList = $userList->get(1000); // <== CHANGE HERE
foreach($usersList as $user) {
  $attributes = array();
  foreach(UserAttributeKey::getAttributes($user->getUserID()) as $key=>$uak) {
    if(is_string($uak)) {
      $attributes[] = array($key => $uak);
    } else if(is_object($uak)) {
      // Put special cases for custom attribute objects here
      switch(get_class($uak)) {
      default:
        break;
      }
    }
  }
  $groups = array();
  foreach((array) $user->getUserObject()->getUserGroups() as $gID=>$group) {
    $groups[] = array($gID => $group);
  }
  $users['Users'][] = array(
    'name' => $user->getUserName(),
    'email' => $user->getUserEmail(),
    'raw_pass' => $user->getUserPassword(),
    'attributes' => $attributes,
    'groups' => $groups );
}
header('Content-type: application/json');
echo json_encode($users);
exit;
?>

There are quite a few attributes, especially those provided by add-ons, which will be of an object type that doesn't nicely convert to a string with the controller's value() function. Rather than extending on a case-by-case basis,we should just serialize the returned object and load that directly. Probably will be flakey as anything for a few add-ons, but those fail-cases should be special-cased, rather than any and all objects.