Came across this bug while helping a user out on IRC:
Create 3 users: one, two, three
Create 3 groups: leaf, branch, tree
Make branch be a member of tree
Make leaf be a member of branch
Add user one to leaf
Add user two to branch
Add user three to tree
Create three articles on 1 page, where each article is viewable by one group (leaf, branch, tree)
Log in as user one, and you see no articles
Log in as user two, and you see no articles
Log in as user three, and you see ONLY the tree article.
Go back to Admin console and verify all user and group settings and they are correct. tree(three)->branch(two)->leaf(one)
Write a small test script, and you see that what is shown by the article is correct. tree has only 1 member (three), branch and leaf are empty.
Group.t test is still passing.
I've narrowed down the problem further, it's between Operation::Group::www_editGroup and Group::new.
www_editGroup calls WebGUI::Group->new($session,"") when a new group is to be created.
When Group->new gets a null groupId, then it doesn't call the _create subroutine to populate the newly created group object with defaults. This sets the expireTime to 0 (which gets rendered by the Interval form as 1 second). When you hit save, then www_editGroupSave creates a group with the correct defaults, but then the form content overrides the defaults.
I think the way to fix this is to move the defaults into the constructor, and make _create just serialize the object data to the database.
Fixed in 7.0.0.
New groups that were created will need to be have their expireOffsets manually changed.
