× Joomla Facebook Connect support forum

Topic-icon Different permissions for different users?

11 years 4 months ago #29148 by chramb1
Yes, it's Christmas - the kids are playing with their new toys and my wife is learning about new watercolor techniques she can do with the kit I got her... so I get some time to hack code. Here's a good one for you: I need to get different permissions for different users, for a specific reason - and I'll share the reason here, because I suspect this is something you can use for a feature. There appears to be no code for page management anywhere in the product, so I added it, myself. See the code below.

What this code does is pull out a user from the mapping table. This user is expected to be someone who has permissions to manage a fan page, which is the big issue here, as we will see. In this example code, which would be called from, say, a cron job or some other kind of trigger on an event, we get the access token for this user out of the mapping table, set it on the API, and call the accounts API function to get a list of all sites that this user can admin. NOTE HARDCODED COMPARE HERE: my testing page ID is hardcoded in for testing. This should be passed as a parameter or stored in the database.

Once the proper page is found, the page's access token is extracted and the post can be made. This allows posts to be made to pages AS PAGES.

The need here is for this mapping, when authenticated, to request manage_pages and publish_stream permissions. While publish_stream might make sense for most users, if you're not posting on the user's behalf, or using a different permission set, you won't want to ask for it. manage_pages, of course, one would never ask for outside of this usage.

Now, to test this, I "faked it" by adding those permissions to the additional permissions request field in the configuration/Facebook API section. I then logged in as this user, which granted the permissions on the access_token stored in the map, and then I removed those additional permissions from the configuration field. But this is a hack, of course, and would have to be repeated if the user ever logged out from Facebook and a new access_token had to be generated on next login.

The problem, of course, is that you cannot know who's logging in when they do a Facebook connect. But I suspect you COULD store additional permissions on a per-user basis somewhere and then test for them on login. If the test fails, you can then do an additional permission request. Since this is done for an administrator (presumably), the extra dialog is no big deal and expected.

PS: You probably thought about this for 30 seconds and realized the big win here - you could use this to create a feature where a link to an article is posted to a fan page, as the page, when the article goes "published." Think in terms of a category in the article manager that has an article or two set to publish ever day - and when they go live, this triggers a Facebook post. This could make JFBConnect a Facebook promotional engine. It need not be limited to articles - anything that can generate an event can generate a post this way. Brands could use this as a promotional engine in a set-it-and-forget-it manner for the most part.

In my case, this is used, among other places, to post a once-a-day post to a page announcing who has won a contest. "The winner of today's photo of the day contest is so-and-so." It also can post end-of-day summaries like, "we had 42 new users today and 283 new forum posts!"

But... it relies on knowing the ID of the user in the mapping table with publish_stream and manage_pages permissions, and making those automatically acquired on login (and, thus, associated with the access_token in the mapping table) is important here to avoid having to "fake it."

What say you?
  public function fbtest()
  {
    $db =& JFactory::getDBO();

    $fb_user_id = 999999999;

    $db->setQuery("SELECT access_token FROM jos_jfbconnect_user_map WHERE fb_user_id=$fb_user_id");

    $access_token = $db->loadResult();

    require_once(JPATH_ADMINISTRATOR . DS . 'components' . DS . 'com_jfbconnect' . DS . 'assets' . DS . 'facebook-api' . DS . 'facebook.php');

    $facebook = new JFBConnectFacebookLibrary();

    $fbClient = $facebook->getFbClient();
    $fbClient->setAccessToken($access_token);

    $result = $facebook->api('/' . $fb_user_id . ''/?fields=accounts');

    foreach ($result['accounts']['data'] as $page)
    {
      if (strtolower($page['id']) == '358473437989126')
      {
        $pageid = $page['id'];
        $page_access_token = $page['access_token'];
      }
    }

    $attachment = array(
        'picture' => 'http://www.element67.com/templates/ih2012/img/logo400.png',
        'link' => 'http://www.element67.com/somelink.html',
        'message' => "This is the message that gets posted",
        'caption' => 'This is the caption',
        'description' => "This is the description of this post",
        'actions' => array(array('name' => 'Enter a Contest!', 'link' => 'http://www.element67.com/contests/')),
        'access_token' => $page_access_token
    );

    $result = $facebook->api('/me/feed', $attachment, true);

    echo "" . print_r($result, true) . "";
  }
The topic has been locked.
Support Specialist
11 years 4 months ago #29178 by alzander
Whew... first off, very happy that you're digging into JFBConnect and hopefully, it's a pretty easy process. We're always trying to make things as simple and elegant as possible, but there's some rough edges in there I'm sure you've encountered. I'll try to touch on your points as you made them and help where I can:

manage_pages permission

But this is a hack, of course, and would have to be repeated if the user ever logged out from Facebook and a new access_token had to be generated on next login.

Once granted, you don't need to ask this permission again. The access token you get from Facebook from that point forward should work with that permission, even if you remove it from the permission requests in JFBConnect. As long as you don't revoke that permission from within Facebook, it will continue to work for your app/site.
Future users just won't be asked for it, which sounds like what you want. So, you shouldn't need to keep re-adding that as a permission, logging in, and then removing it once you've done it for you're 'key' user once.

PS: You probably thought about this for 30 seconds and realized the big win here - you could use this to create a feature where a link to an article is posted to a fan page, as the page, when the article goes "published."

Yeah, publish to Page has been a feature we've been tossing around for (probably) a year or so now. The main reason we haven't implemented it is complexity and user-issues. The possibility for accidents is huge as someone may publish, and unpublish articles to test, create 'dummy' articles for whatever reason, and countless other scenarios. With auto-post, things can get out without the proper checks. We honestly know this because other extensions do the auto-publish thing, break, and then users have blamed us... we get an irate forum post about once a month about it.. seriously... and it *can't* have been JFBConnect...

After Open Graph Actions (out now) and Joomla 3.0 support is released (soon), that will *likely* be one of our next big features. I can't guarantee it as things change, but there honestly are so many 'big' features we can implement, and this is slowly creeping up as we take care of the other stuff.

On a side note, I'd say that Open Graph Actions are much better for automatic promotion than auto-Page publishing. Open Graph Actions goes out to a user and possibly their friends, which is more 'trusted'. Page posts, especially if automated, become very sterile. If you want your Page to be trafficked, you should create a great comment intro for the article and link to it.. it's more personalized to your Fan Page than the first line (or so) of the article, which may not really draw the user in like a good, FB audience specific intro.

Bringing it together
So, you already have the permission now, you don't need to 'fake it' anymore, which means your job is pretty much done with the code you posted. We'd have a lot more work for the prettiness and flexibility aspect, but we're pretty good at that by now. Our recommendations above still stand, but there is enough desire for this type of feature that it will happen.

Hope that all explains. You're code looks great and I'm assuming does exactly what you're looking for. Would love your feedback on any improvements or suggestions for us.

Best of luck,
Alex
The topic has been locked.
11 years 4 months ago #29180 by chramb1
So to get the permissions, the "hack" of adding them, logging in, and then removing them works - it's not pretty, of course. And in the unlikely event that a new user registers while this is being done, that might be odd, but it is what it is.

On the page vs. actions issue, I do have to disagree a bit. We have two usage scenarios where this is definitively not the case. First, on Model Insider, autoposting the winner of the daily/weekly/monthly photo contests reaches all users interested in knowing who won. An action wouldn't do that unless they're also friends with the winner, since the action goes on the user's page, not the site's page.

And second, in the case of RockyHorror.org (we run the world's largest Rocky Horror Picture Show community site), we have about 10,000 users on the site but over 26,000 fans on Facebook. These are people who are casual fans of the movie but would never join the community web site that's running our custom Joomla platform. We delight in reaching them, because that's 26,000 pairs of eyeballs who buy our t-shirts and often click through when we promote a quiz or something interesting on our site that doesn't require a login. So posting to the page reaches about 30% of our fans (Facebook nominally gives you 18% visibility, but we've managed to increase that to close to 30% due to a very motivated fan base that likes/shares way above the average engagement rate).

Most people view our Facebook pages as news/entertainment sources, so posting to the page to promote things really does work. Actions work too, of course, but our pages are where people expect to get a nugget of fun a couple times a day ;)
The topic has been locked.
Support Specialist
11 years 4 months ago #29208 by alzander

So to get the permissions, the "hack" of adding them, logging in, and then removing them works - it's not pretty, of course. And in the unlikely event that a new user registers while this is being done, that might be odd, but it is what it is.

True, but from what you stated above, you'd only need this for an admin user and likely only for one Page... so, once done, you'd never need to do it again.

As for your points of Open Graph Actions vs auto-posts, you're correct for your case. The 'general' case (of most of our users) is that they're just starting out and likely don't have anything like the audience you do. Even the 'larger' sites the use JFBConnect many times still use JomSocial (or some other profile extension) and have lots of traffic on-site. The Page isn't as big of a deal. You're an exception, which is awesome.

The nice thing is that JFBConnect gets you about 95% of the way there and the other steps you've already implemented for your case. It is something we're planning to add, but still don't know when.. the fact that you already have it doing what you want is the important thing for now.

Hope that all explains, and we really do appreciate your feedback. Any suggestions or ideas for making things easier or better are always welcome!

Alex
The topic has been locked.