16 Replies Latest reply: May 23, 2012 3:12 PM by Shane Rogers RSS

    Input needed for CMR: User Identification and Permissions

    Karl Rumelhart

      One of the important priorities we have for our next version of CMR is to make the reports more actionable by identifying the people behind some of the numbers.  For example, with the Profile chart you might see that 80% of users have selected an avatar and be led to wonder, "Who are the folks who don't yet have an avatar?"   If you knew, you could reach out and suggest (politely ) that they get one.   Or on the User Adoption Chart it is interesting to see that you have a bunch of Active users who aren't Participating, but even more interesting if you knew who they are so you can engage with them. 

       

      OK, sounds good.  But one of the tricky things we have come up against is that in some communities, external communities in particular, is it quite common for users to restrict access to parts of their profile.  We need to make sure, for example, that this CMR feature not become a backdoor way for a Group owner to see email addresses that she is not otherwise entitled to see, and handle other scenarios like that.  

       

      But not everything is completely clear cut here and I would value some advice from you guys.

       

      First question:  How much is enough information to identify a user?  In particular, would it be enough to just export a list of the User IDs of the folks who don't have an avatar or are Active but not Participating or whatever?  (This would avoid the permissions issue since User ID is always public.)  Or would that be lame and you would feel that unless we export full names and email addresses we haven't really met the use case?

       

      Second question: To be very concrete, let's focus on the Profile Chart, which is a global-only chart.  Suppose that here we are able to list any (or every) user -- first name, last name and email -- and whether or not they have filled in their various profile elements.    There are several options

      • Don't list any names or emails, just user IDs
      • Include only those names and emails that would normally be visible, hide the others
      • Include all names and emails no matter what under the assumption that this is being exposed to someone in an administrative capacity

      Keep in mind the set of people who would be able to see this: anyone with Admin privileges, System Manage privileges or someone who has been specifically granted the 'Global CMR Permission' that we will include in the next release.

       

      I hope that these questions make sense and would appreciate any thought on them or this general topic.

       

      Many thanks!!

        • Re: Input needed for CMR: User Identification and Permissions
          Tracy Maurer

          When you say "user ID", do you mean username? I ask because there is actually a user ID that is a number, but it is not something that can easily be used to look up a user.

          • Re: Input needed for CMR: User Identification and Permissions
            Ted Hopton

            Trying to re-create my post from this morning that got lost...

             

            First, I am soooo happy that you identify this kind of actionable information as "One of the important priorities we have for our next version of CMR." That's wonderful to hear! I completely agree that this is the critical next step needed for the CMR to fulfill their stated mission (reports for community managers).

             

            And you have identified important issues around privacy and data security. You have to get this right, period.

             

            My answer to your first question, what is the minimum to identify a user, is username. From that, we can derive everything else we need if we build VLOOKUPS in Excel off of other reports we can get either from Jive Support or from the SAP BO site. But, boy, what a pain that would be, and as you said, really pretty lame. Not consistent with the standard of ease-of-use you have established with the UI of the CMR so far. It would be a weak answer. Yet, let's be clear, it would be a quantum leap forward from the nothing we have now!

             

            The top-notch way to do this, in line with the thought and effort you put into the CMR UI already, is to make these permission settings customizable in the admin console. For example, I run an internal community where all work emails are visible, so I want that data in the CMR results. Someone running a customer community with members in the EU has to have ways to restrict access to email addresses that users have not opted to make visible. So let us configure the settings so they meet the needs of our community.

             

            I can't tell you HOW to set up the configuration options, but this reminds me of the multi-tenancy problem, which was masterfully addressed by Jive with a group of Jive Champions who worked with Olivia Teich and Kathryn Everest, among others, to thoroughly explore the needs and use cases, ending up with a prioritized list of requirements. I would suggest that this is a similarly complex issue which different Jive customers have different, and strong, feelings about. If you engage us in real-time discussion I suspect we will tease out fine points with big implications that might otherwise be missed. In fact, the multi-tenancy changes coming will need to be accounted for in when it comes to these privacy and security aspects of the CMR, so there is another can of worms.

             

            So here's my FINAL ANSWER, Karl

            1. Give us these actionable reports ASAP with just usernames so we can get busy on the important work of developing our communities with this valuable data. We'll suffer through the lameness for a while, happy to have such great data even though we have to work to make it useable.
            2. Don't delay these actionable reports while you build the comprehensive permission setting scheme that it needs to truly be great, but DO get us customers involved in defining the requirements for this. Then roll it out as soon as you can so we can leave the lame username-only reports behind and instead get the reports as we truly need them to be efficient and effective community managers.
            3. Creating a way to share the community-wide reports is 1a on my list, and more important than #2 here. Since we are asking for a way to let us grant access to these reports, it's on us to make appropriate decisions about who those people are, meaning the work on your end should not be anywhere near as extensive as #2, above.
            • Re: Input needed for CMR: User Identification and Permissions
              Shane Rogers

              In response to your initial questions:

               

              1. Minimum info to identify a user is UserID. For us it's the userid from our customer portal (we use SSO from our portal to our community). I would have to do some data jockeying to get this to something more actionable, but it's the minimum field to enable some action.

               

              2. Our default is NOT to show emails to the broader community, but it comes from our customer portal where it's available to our employees. For our situation, option 3 to provide all of the fields assuming this access/CMR is made available to those with the privilege to access the data from other sources. If we took it a step further and included a field for download/export indicating the current visibility setting for the field - then I could act on the data knowing what the customer visibility preferences were.

               

              Another note for our community is First/Last name is visible by default and is set to the display name for our Community.

               

              I'm anxiously awaiting the iterations of the CMR. In order to be ready to apply updates ASAP, I'm staying current on patches too. Thanks!

                • Re: Input needed for CMR: User Identification and Permissions
                  Jackie Bartolotta

                  Chiming in here, as this appears to be the closest thread to what I am experiencing.

                   

                  A few weeks ago, I was able to pull the leaderboards per office so that we could reward the most active user per office.  I could go into the CMR > User Adoption, then filter by location, then download the CSV to get a full list.  The CSV included User Names, so was very easy and effective to distribute.

                   

                  A couple of weeks ago we installed the updated CMR plug-in.  I just attempted the same download, but now the CSV file lists out User ID rather than Username.  Not nearly as useful.

                   

                  Is this a result of the plug-in?  Anyway I can get to username rather than userid?

                   

                  Jackie

                    • Re: Input needed for CMR: User Identification and Permissions
                      Karl Rumelhart

                      Yup.  We messed up on that.  With all the CSV changes in this version we inadvertently regressed on that one.   Very sorry about that.  We will definitely fix this soon.

                       

                      Anyway I can get to username rather than userid?

                      Well, one option you have is to use Jive's handy-dandy APIs!    Assuming you are on 5.x, you can access v2 of the "core API."   (You can look at OpenClient REST API, click on User Service and then Get user for the relevant documentation.)  One simple way to use this API is to use the CURL command.  (This is available on Mac.  You can get it on windows.)

                       

                      Open a terminal window and type the following

                      curl -u {username}:{password} http://{url to your instance}/api/core/v2/{id}

                       

                      Note: you may need https instead of http; items in {} should be filled in with appropriate values

                       

                      For example, in the jive community my user id is 117964.  If you type the command

                      curl -u {username}:{password} https://community.jivesoftware.com/api/core/v2/users/117964

                      the first part of what comes back is

                      {

                        "name" : "Karl Rumelhart",

                        "level" : {

                          "name" : "Jive Employee",

                          "description" : "",

                          "points" : 459,

                          "resources" : {

                            "image" : {

                              "ref" : "https://community.jivesoftware.com/api/core/v2/images/status/c/statuslevel-600.gif",

                              "allowed" : [ "GET" ]

                            }

                          }

                        },

                        "username" : "karl.rumelhart",

                        "enabled" : true,

                        "email" : "karl.rumelhart@jivesoftware.com",

                        "firstName" : "Karl",

                        "lastName" : "Rumelhart",

                       

                      This is assuming you have permission to see my profile info (which you do).  If you don't have permission you get less.

                        • Re: Input needed for CMR: User Identification and Permissions
                          Jackie Bartolotta

                          Yep - that works, but it takes a lot of time to go through that userid by userid when you have about 500 users!  That was a super handy list, and something I was looking forward to sharing with our community manager group so they could access this themselves.  Please fix :-)

                           

                          Thanks, Karl!

                            • Re: Input needed for CMR: User Identification and Permissions
                              Shane Rogers

                              I haven't tested this in a while, but I used to use the regular Admin console to save a list of users in CSV format that included the userid and UserName (at least I think it included both). If you could get the file from the Admin console which may be a larger user population than what you are looking for via the CMR, you could use excel and VLOOKUP to go from userid to username.

                               

                              Sorry for posting prior to confirming that this process will actually work, but I won't get to trying this out for a day or two and in case you have a time crunch I wanted to toss it out to you.