More Qs on User Syncronization with emApp

I have made it about half way down the road with embedding G2 in my app. Where i am now getting hung up is on user sync with the users I have currenly in my system, as well as those in G2. I have it working for guest users, who are just browsing a gallery.

Basically, I'm working on getting the owner of G2 gallery logged into G2 so they can do admin (after they've successfully logged into my app). After that I'll tackle new G2 user creation.

I am confused about this user syncronization. I have about 15 users of my app, and 4 of those users have galleries. I have their G2 username in my DB.

If, when a user logs into my system, they have a G2 username I'm trying to log them into G2 so they can manage their photos. I don't really need on-the-fly user creation, but it appears i might have to recreate my gallery users for some reason?

if i try

$g2User = 6;
$ret = GalleryEmbed::init(array( 'g2Uri' => $g2_Config['g2Uri'], 
'activeUserId'=>$gUser, 
'loginRedirect' => $g2_Config['loginredirect'], 
'embedUri' => $g2_Config['embedUri'], 
'fullInit' =>'false'));

knowing that "6" is a gallery userID, it blows up (ERROR_MISSING_OBJECT), which is probably correct because it is supposed to be my app's userID which is not mapped to anything in G2.

Q: Does the following

GalleryEmbed::createUser($emAppUserId, array('username' => $emAppUser['username'],'language' => $emAppUser['language'], ...));

do some magic to attach my userID to a G2 userID? What of those gallery users that already exist? How are they 'mapped'? And what are the rest of the parameters to GalleryEmbed::createUser (the ... above) - are all these calls documented someplace? A search for GalleryEmbed::createUser turns up 2 docs - that above is the most detailed reference. Do i need to spec a password, too?

From the docs:

Right - so I loop my users calling GalleryEmbed::createUser, passing my userID, my username, and some other parameters (tbd), and a 'map' is created someplace (where, in the G2 db?)? After this is done, I go back as superadmin and change ownership of all the 'old' (non-synced) albums to their correct new (synced) account name?

Example:

A user on my system has a username of

(because my system uses email address for usernames) and a userID of '27'.

Their G2 username (because I upgraded the g1 gallery to g2) is 'name1234' - because g1 didn't allow email addrs to be used as usernames. Lets say their g2 user id is '12'.

I have in my database 27,name1234@mailhost.com,name1234 (and other stuff) but not G2's id (12). How is the createUser call properly constructed?

is it possible to instead use GalleryEmbed::updateUser() to get the proper 'mapping' (and where do I find out what the updateUser parameters are)?

Any insight would be appreciated.

This is apparently true.

Based on the GalleryEmbed::createUser() args, the answer could be no. However, I spec'd a generic password for all of them so that all users have a password. See the program below.

Apparently yes.

I'm not sure about this at this point, I think they will have to go away...

I created the following progam to do the initial user sync between my program and G2:

<?

require_once('fullpath/gallery/embed.php');

$dblink = @mysql_connect ("localhost")
			or die ("Could not connect");

$db = "mydb";

$data = array();
	
$g2_Config['path'] = dirname(__FILE__) . '/';
$g2_Config['g2Uri'] = '/gallery/';
$g2_Config['loginredirect'] = '/login.php';
$g2_Config['embedUri'] = '/admin/gallery2.php';

$g2user = "";
$g2DefPW = "abg2pw";

$sql = "select id,username,first_name,last_name,email,enableGallery from blog_sub";
		
$ret = GalleryEmbed::init(array('baseUri' => $baseUri, 'g2Uri' => $g2user, 'activeUserId' => $emAppUserId));
if ($ret) {
     /* Error! */
     echo("gallery init error:" . $ret->getAsHtml());
} else {
	
	// call the db for users
	$result = mysql_db_query($db,$sql);
	
	// loop the users
	while ($row = mysql_fetch_array($result)) {
		if ($row["enableGallery"]) {
			// this user should get a gallery, check them and create them if needed
			
			$emAppUserId = $row["id"];
			$emAppFullname = $row["first_name"] . " " . $row["last_name"];
		
			$ret2 = GalleryEmbed::isExternalIdMapped($emAppUserId, 'GalleryUser');
     		if ($ret2 && $ret2->getErrorCode() & ERROR_MISSING_OBJECT) {
				/* The user does not exist in G2 yet. Create in now on-the-fly */
         		$ret = GalleryEmbed::createUser($emAppUserId, array('username' => $row['username'],
                                                             'email'=>$row['email'],
                                                             'fullname'=>$emAppFullName,
                                                             'password'=>$g2DefPW));
                                                             
				if ($ret) {
					/* An error during user creation. Not good, print an error or do whatever is appropriate 
					* in your emApp when an error occurs */
					print "An error occurred during the on-the-fly user creation <br>";
					print $ret->getAsHtml();
					exit;
				} else {
					echo("created g2 user " . $row["username"] . "<br>");
				}
					
			 } else {
				/* check to see how bad the error was */
				if ($ret2) {
					print "An error occurred while checking if a user already exists<br>";
					print $ret2->getAsHtml();
				} else {
					echo("user " . $row["username"] . " has g2 mapping<br>");
				}
				
			 }
			 
		} // end if enableGallery
		 
 	} // ends the user loop

}

?>

obviously, paths and the DB info will have to be changed for a particular system. But this has worked, and it has a trap in there so that it can be rerun as needed to keep user in sync in the future.

1. you might want to change the useralbum module for that.
createUser() is not directly responsible for creating an album for the user. it's the useralbum module that does that on GalleryEntity::save events of entities of type GalleryUser.

2. The joomla and other integrations do the same and they are GPL. maybe you can copy some code.

3. Don't you like XHTML strict?

Please let us know what information is missing at http://codex.gallery2.org/index.php/Gallery2:Embedding . You or I could then update the docs there.

no, i'd never do that.

don't change the core API when you can easily achieve the same goal in your modular code.
just change the attributes of that album after it has been created.

an album inherits the theme of its parent album. same for other theme attributes like thumbnail size etc.
in the current svn version (g2.2-svn), there's an admin setting to switch from defaulting the theme of a new album to the global default settings vs. to the parent.

you can change the theme of an album once it has been created with $album->setTheme($themeId);

@XHTML strict:
well, no need to do be strict. your application sets the HTML document header. you can make it loose too.

Oh so close. after the above block that gets the album id, i added the following:

list ($ret, $album) = GalleryCoreApi::loadEntitiesById($albumId);
if ($ret) {
	print $ret->getAsHtml();
	exit;
}

$themeId = 'classic';
		
$s = $album->setTheme($themeId);
				
var_dump($album);

not quite working. the theme has not changed in the interface. when i look at the var_dump on the $album object, i see the theme listed in two places:

object(GalleryAlbumItem)#57 (23) {
  ["theme"]=>
  string(7) "classic"
  ["orderBy"]=>
  string(0) ""
  ["orderDirection"]=>
  string(3) "asc"
  ["canContainChildren"]=>
  int(1)
  ["description"]=>
  string(0) ""
  ["keywords"]=>
  string(0) ""
  ["ownerId"]=>
  int(463)
  ["summary"]=>
  string(0) ""
  ["title"]=>
  string(10) "timtest104"
  ["viewedSinceTimestamp"]=>
  int(1160441282)
  ["originationTimestamp"]=>
  int(1160441282)
  ["pathComponent"]=>
  string(10) "timtest104"
  ["parentId"]=>
  int(7)
  ["id"]=>
  int(464)
  ["creationTimestamp"]=>
  int(1160441282)
  ["isLinkable"]=>
  int(0)
  ["linkId"]=>
  NULL
  ["linkedEntity"]=>
  NULL
  ["modificationTimestamp"]=>
  int(1160441282)
  ["serialNumber"]=>
  int(2)
  ["entityType"]=>
  string(16) "GalleryAlbumItem"
  ["onLoadHandlers"]=>
  NULL
  ["_persistentStatus"]=>
  array(2) {
    ["flags"]=>
    int(0)
    ["originalValue"]=>
    array(21) {
      ["theme"]=>
      string(0) ""
      ["orderBy"]=>
      string(0) ""
      ["orderDirection"]=>
      string(3) "asc"
      ["canContainChildren"]=>
      int(1)
      ["description"]=>
      string(0) ""
      ["keywords"]=>
      string(0) ""
      ["ownerId"]=>
      int(463)
      ["summary"]=>
      string(0) ""
      ["title"]=>
      string(10) "timtest104"
      ["viewedSinceTimestamp"]=>
      int(1160441282)
      ["originationTimestamp"]=>
      int(1160441282)
      ["pathComponent"]=>
      string(10) "timtest104"
      ["parentId"]=>
      int(7)
      ["id"]=>
      int(464)
      ["creationTimestamp"]=>
      int(1160441282)
      ["isLinkable"]=>
      int(0)
      ["linkId"]=>
      NULL
      ["modificationTimestamp"]=>
      int(1160441282)
      ["serialNumber"]=>
      int(2)
      ["entityType"]=>
      string(16) "GalleryAlbumItem"
      ["onLoadHandlers"]=>
      NULL
    }
  }
}

the first bit was changed to 'classic' as expected, but this ["originalValue"]=>array appears to be the culprit...? Or am i hitting the wrong?

Excellent! Thank you for the guidence - here is the updated code block:

// get a write lock
list ($ret, $lockId) = GalleryCoreApi::acquireWriteLock($albumId);
if ($ret) {
	print $ret->getAsHtml();
	exit;
}

// load the album
list ($ret, $album) = GalleryCoreApi::loadEntitiesById($albumId);
if ($ret) {
	print $ret->getAsHtml();
	exit;
}

// change props
$s = $album->setTheme($themeId);

// save the album
$s = $album->save();

// release the lock
$ret = GalleryCoreApi::releaseLocks($lockId);
if ($ret) {
	print $ret->getAsHtml();
	exit;
}

I'll put this all back together as a complete script and post the whole thing as a unit again for other's reference.