Hi

Detlev/Nils,

Regarding issue #4 from Erik's email concerning social group blog permissions, we do have a few questions.

The current expected behaviour with regard to which users can edit posts in a blog in a social group is as follows:

1) An owner of a social group, or user with the "administer" role, has permission to edit any posts made in the blog of that social group - including posts made by other members of the social group.

2) Regular members of a social group may edit any posts they create in the social group blog but a regular member cannot edit posts created by other users in the social group blog.

In local testing, the application is adhering to the above expected behaviours in normal use cases.

I have created a new private group to check this behavior.

- userA created a new private group and a blogpost

- userB became member and can NOT edit that blogpost

- userB became admin and could change blogpost

- userB became member again and could NOT change the blogpost

This result confirms the point 1 & 2.

However, in the case that was opened by Lufthansa (http://www.jivesoftware.com/jivespace/thread/57132), the stated seen behaviour was that a member was able to edit the blog post made by another member in a social group.

The first question we'd like to confirm is, when the term "members" was used in the support case, can you confirm that it was used in reference to users that are not owners or administrators of the social group in question?  I assume the answer is yes, but we just need to be certain in investigating the cause of the undesired behaviour.

Yes, member is member, administrator is administrator.

Creator/Owner have not been in the focus.

Next, in local testing, we have only been able to replicate the undesired behaviour when one of the following scenarios has first taken place.  Can you confirm whether either of these scenarios took place prior to seeing the issue the support case was opened for?

 

1) In the admin console under Blogs -> System Blogs, a system admin can actually navigate to a social group blog if the admin knows the blogID value for the blog from the database and they enter that blogID value in the text box at the top right of the list of system blogs and hit enter.  If the admin then chooses to add a user as an author to that blog via this screen, upon clicking the "Update Blog" button, all users that are able to write posts in the social group blog at that time will be granted administrative permissions for the social group blog which would then allow them to edit posts of other users in the social group blog.

I could not add the userB. The "Blog Address" was not filled and Clearspace complaint about that.

After adding the groups name as the address, the userB (member only user) could edit the blog.

After removing userB from the System-Blogs configuration editing was NOT possible anymore.

2) If userA creates a new social group and then chooses to grant the "administrator" role to another member of the group, userB, then userB will then have the ability to change userA's role to just "member."  However, if this is done, userA, who at one time was an "administrator" for the social group, still retains their administrative permissions for the social group's blog and thus is still able to edit posts made by other users.

I did this test, too (userA and userB are just oposite)

- userB created a new secret group

- userA got member and could NOT edit that blogpost

- userA got admin and could edit that blogpost

- userB got member and could STILL edit that blogpost

I can confirm point 2.

It is important to note that both of these scenarios describe product bugs that we will be fixing in the next patch release of the software, but in both scenarios, intervention is required by a system admin or an administrator of the social group before the undesirable situation where a user who is simply a member of a social group is able to edit posts made by another user when they shouldn't be able to.

Any information you can provide concerning these scenarios and Lufthansa's use cases would be very helpul.

With this new background information I will try to get some more info about the behavior we have with the test group of the reported issue.

- Nils

mysql> SELECT * FROM jiveEntitlement WHERE objectType = 37 AND objectID = '2526';+---------------+------------+----------+--------+---------+-------------+-----------------+---------------+------------------+
| entitlementID | objectType | objectID | userID | groupID | contentType | entitlementMask | creationDate  | modificationDate |
+---------------+------------+----------+--------+---------+-------------+-----------------+---------------+------------------+
|        344601 |         37 |     2526 |   2695 |      -1 |          -1 |              11 | 1255091479361 |    1255091479361 | 
|        344602 |         37 |     2526 |   2005 |      -1 |          -1 |              11 | 1255091479361 |    1255091479361 | 
|        344603 |         37 |     2526 |   2045 |      -1 |          -1 |              11 | 1255091479361 |    1255091479361 | 
|        344604 |         37 |     2526 |   5792 |      -1 |          -1 |              11 | 1255091479361 |    1255091479361 | 
+---------------+------------+----------+--------+---------+-------------+-----------------+---------------+------------------+
4 rows in set (0.00 sec)

mysql> SELECT entitlementID,objectType,objectID,userID,groupID,contentType,entitlementMask,from_unixtime(creationDate/1000),from_unixtime(modificationDate/1000) FROM jiveEntitlement WHERE objectType = 37 AND objectID = '2526';
+---------------+------------+----------+--------+---------+-------------+-----------------+----------------------------------+--------------------------------------+
| entitlementID | objectType | objectID | userID | groupID | contentType | entitlementMask | from_unixtime(creationDate/1000) | from_unixtime(modificationDate/1000) |
+---------------+------------+----------+--------+---------+-------------+-----------------+----------------------------------+--------------------------------------+
|        344601 |         37 |     2526 |   2695 |      -1 |          -1 |              11 | 2009-10-09 14:31:19              | 2009-10-09 14:31:19                  | 
|        344602 |         37 |     2526 |   2005 |      -1 |          -1 |              11 | 2009-10-09 14:31:19              | 2009-10-09 14:31:19                  | 
|        344603 |         37 |     2526 |   2045 |      -1 |          -1 |              11 | 2009-10-09 14:31:19              | 2009-10-09 14:31:19                  | 
|        344604 |         37 |     2526 |   5792 |      -1 |          -1 |              11 | 2009-10-09 14:31:19              | 2009-10-09 14:31:19                  | 
+---------------+------------+----------+--------+---------+-------------+-----------------+----------------------------------+--------------------------------------+

these are the results for that group I have been testing with in the cause of troubleshooting this issue.

To check how big our problem is, it would be great to get another query that gives us all the members of a group with their role (creator, member, admin).

Putting both results side by side would show if a group's blog might have 'wrong' permissions.

-- Nils

Hi,

I wrote a script to compare the blog and the group permissions for every group.

The result says that we only have 15 groups where the permissions of both match.

And 138 groups where there is a mismatch.

Many mismatches might be false positive, since I compared entitlementMask = 11 to memberType = 0.

If I change the comparisson to entitlementMask in (11,15) to memberType = 0. The result looks better.

Groups that look good: 102
Groups that look bad : 51

For further analysis it would be great to get access to the documentation of the database schema, where we can lookup what entitlementMask = 15 is.

best regards,

Nils

PS: the result are from our test system which has all produtive data from around June in it. I do not do a produtive search, yet.

Thanks for the info.

I attached the results maybe you interpret them differently.

There are a lot of groups that show in the list that just have a different number of "admin" users.

Other show up in there because they have a little number of group owners, but a large number user with blog-overwrite permissions.

That overwrite permissions (entitlementMask = 11,15) can only be set via saving a group in System-Blog (admin console)

Detlev and me and the other admin can not remember to have saved all these blog individually.

Or by the group admin, but taking a look at the list, it is very unlikely that, that many group admins made all their members  admins and back again.

Can you really exclude the possibility that something else upgrade, bugs might have set these permissions?

To get back to a normal state, I am thinking of taking the groups results and update the blog-permissions so that group members get create permissions and only the owners get overwrite rights.

best regards,

Nils

scott.hirdes wrote:

 

Can you send along the queries as you are running them that are producing the results under the "Blog Permissions" and "Groups Permissions" sections in the output you gave?  I just want to be sure I am reading the columns correctly.

The queries are the ones you have posted here. The script including the queries is attached.

The normal state for entitlements for a social group blog would be:

• all the owners/admins of the group have a jiveEntitlement record for the social group blog with an entitlementMask value of 15
• all regular members of the group have a jiveEntitlement record for the social group blog with an entitlementMask value of 3
  

So updating to these settings would bring us back to normal. Great.

The bugfixes that are planned for 2.5.18, do they also correct permissions that are not consistent or do they 'just' prevent new errors? I ask this because, if they heal our problems we wouldn't have to update the permissions.

best regards,

Nils

  I would recommend that you also include a "containerType = 700" in the inner query against jiveBlog there since the social group id could potentially overlap with other container ids for other container types.  Not necessarily all that likely, but possible.

Thanks for the feedback. I changed the SQL in the script. We still get the same number of groups with problems.

 

As for an upgrade task, at this time we are not planning on implementing an upgrade task to update entitlements for social group blogs.  Changing the values in the database as you have suggested would be the supported way of correcting the data.

Will you/Jive provide the queries for the correction task?

best regards,

Nils

Hi Jive,

can you please update the "Case Product Issue" widget.

scott.hirdes wrote:

The fixes mentioned in this case are going to be in 2.5.19, the 2.5.18 release was already closed to development by the time these issues were discovered.

best regards,

Nils