Group Abilities - Roles Test
1. Describe the expected behavior and purpose of the new code.
To give groups more flexibility and control by allowing the groups to specify "roles" which can be given distinct group related "abilities". Members can be in any number of different roles and different groups may have different roles besides just the "owner", "offier" and "member" that the current groups system has.
2. List any dependencies the new code may have -- what other systems may be affected?
These changes effect group behavior, the group information floater and the finder. They also effect group behavior, group IMs, group notices. Basically anything dealing with groups will be effected by this change. It does have few dependencies but is dependent on the database that it communicates to to have proper columns and set ups.
3. Detailed plan(s) for testing new functionality, including success and failure cases, if possible.
Non-Member Test(3a)
3.a.1) Open the Finder, choose the Groups tab and search for a group in which you are not a member of. Select one of those groups so that it's information is displayed in the finder.
3.a.2) Verify that as a non member, the "Members and Roles" tab is disabled and you cannot select it.
Create Role Test (3b)
3.b.1) Open up the group information floater for a group in which you have the "Create New Roles" ability (and none of the following abilities..role deletion, ability to change role properties, viewing roles, assigning members to a role, removing members from a role, change role abilities) and go to the "Members and Roles" tab and then to the "Roles" subtab. Verify that the "Create New Role" button is enabled.
3.b.2) Click the "Create New Role" button. Verify that in doing so, a new role entitled "New Role" is created and it's information is filled in into the botton section of the panel (name, title, description, assigned members, allowed abilities).
3.b.3) Verify that there is no title, no description, no assigned members and none of the abilities are checked.
3.b.4) Verify that creating a new role is considered a "change" so that going to another tab (or sub tab), closing the group information floater, or the SL client causes the "Apply/ignore/cancel" dialog to appear.
3.b.5) Verify that cancelling, ignoring and applying the changes (via the dialog) all work correctly (correctly means the new role is persisted on apply or not on ignore, etc.).
Delete Role Test (3c)
3.c.1) Open up the group information floater for a group in which you have the "Delete Roles" ability (and none of the following abilities..role creation, ability to change role properties, viewing roles, assigning members to a role, removing members from a role, change role abilities) and go to the "Members and Roles" tab and then to the "Roles" subtab. Verify that you can view the list of roles. Verify that the "Delete Role" button is enabled if you select a role that is the "owner role".
3.c.2) Select a dummy role (perhaps you want to have created a new one previously) or any role that you want to delete. Click the "Delete Role" button to delete the role.
3.c.3) Verify that the role now no longer appears in the list of roles.
3.c.4) Verify that deleting the role is seen as a "change" and that switching to a different tab, different sub tab, closing the group information floater, or closing the springs the "apply/cancel/ignore" dialog.
3.c.5) Verify that "cancelling" the change works properly (from the dialog or from the cancel button).
3.c.6) Verify that "ignoring" the change works properly (from the popup dialog).
3.c.7) Verify that "applying" the change from delting a role works properly and is persisteted to other users in the same session (so that users who are logged in when you make the deletion and apply it, see the deletion and don't have to relog to see it...they may need to open/close some floaters however).
3.c.8) Verify that you can delete multiple roles at any given 'session' (means the time between applying changes) and that all of the deletions persist upon apply and all are cancelled upon cancellation/ignoring of changes.
Role Properties Test (3d)
3.d.1) Open up the group information floater for a group in which you have the "Change Role Properties" ability (and none of the following abilities..role creation, role deletion, viewing roles, assigning members to a role, removing members from a role, change role abilities) and go to the "Members and Roles" tab and then to the "Roles" subtab. Verify that you can view the list of roles.
3.d.2) Verify that when you click on a role, that the text editors where the role's description, title, long description are displayed are enabled and that you hae the ability to type in changes to those fields.
3.d.3) Verify that altering any text (even if it is altering some text, then altering it again to return it to the way it was) is considered a "change".
3.d.4) Do the standard apply/cancel/ignore tests for changes the buttons, for switching between subtabs, for switching between tabs, for closing the group information floater, and for closing the client. These tests are srot of 'standard' now.
3.d.5) Verify that you can make changes to multiple roles and that applying the changes applies the changes across all of the roles.
3.d.6) Verify that if you make changes to a role, select another role, then reselect the changed role, that the changes persist (in both the UI and after you apply the changes).
Role Assign Member Test (3e)
[Users needed] 2. One with ONLY the ability to assign members to a role and one group owner.
3.e.1) Open up the group information floater for a group in which you ONLY have the ability to asssign members to a role (user A). Go to the "Members and Roles" tab and the "Members" subtab. Verify that you can view the current list of members.
3.e.2) Click on a member a verify that a list of all roles in the group appears with checkboxes next to them. Verify that every role the selected member is in has the checkbox next to the role name checked. Also verify that the "checked" roles are disabled (implying that the user cannot remove the selected member from the role). Verify that every role the selected member is NOT in has the checkbox next to the role name unchecked and that the checkbox is enabled. Verify that the "owner" role's checkbox is disabled since user A should not be able to add members to the owner role.
3.e.3) Verify that user A, can click the checkboxes for the selected member which are enabled (thus adding them to the role). Verify that on clicking the role, that they checkbox is still enabled (thus allowing them to "undo" the change made).
3.e.4) Verify that the "role abilities" associated with the role in which user A just added the selected member to are listed in the "abilities list". Verify that the "abilities list" is an aggregate sum of all the abilities in which the selected member has over all of his roles.
3.e.5) Uncheck the role user A just added the selected member to. Verify that the "abilities list" now only contains abilities in which the selected member's checked role's have.
3.e.6) Add the selected member to some role, verify that doing this is a "change" and that the familiar apply/cancel/ignore dialog appears in the different scenarios. (The "different scenarios" in which this happens should be well known by now).
3.e.7) Verify that cancelling or ignoring the change returns the selected member's state to what it was originally.
3.e.8) Verify that applying the change, persists that the selected member was added to that role and the role's checkbox is now greyed out since User A does not have the ability to remove members from a role.
3.e.9) Verify that checking and unchecking a role for a member (therefore adding them to a role, then deciding not to) is not considered a "change" and does not bring up the apply/cancel/ignore dialog. Also verify that one a change is applied that it is no longer considered a change.
3.e.10) Verify that making changes to one member then selecting a different member and selecting the "first" member again, shows the changes previously made to the "first" member.
3.e.11) Verify that multi-selecting many members and making a change has that change show up when selecting the individual members also as well as any subset of the first group selected.
3.e.12) Verify that "User A" cannot add ANYONE to the "owner role".
3.e.13) Verify that "USer O" (an owner) can add anyone (except himself obviously) to the owner role.
Role Remove Member Test (3f)
Repeat the above "Assign member Test" but replace the word "assign" with "remove" and the change to the appropriate abilities.
Role Change Abilities Test (3g)
Users needed: [1 with the ability to add abilities to a given role]
3.g.1) Open up the group information floater for a group in which you ONLY have the ability to asssign abilities to a role. Go to the "Members and Roles" tab and the "Roles" subtab.
3.g.2) Verify that you can indeed see all the roles in the group. How do you know if they are all of them? Magic! Or have an owner view them.
3.g.3) Verify that when you click on a role, a list of all the abilities possible is populated.
3.g.4) Verify that, for all the abilities in which the selected role has, all of the checkboxes next to those abilities are checked and enabled so you can uncheck and recheck them.
3.g.5) Verify that, for all the abilities in which the selected role does not have, all of the checkboxes next to those abilities are unchecked and enabled.
3.g.6) Verify that adding or removing an abilities or multiple abilities from a role is considered a change and brings up the ever popular apply/cancel/ignore dialog in the no well known scenarios.
3.g.7) Verify that applying/ignoring/cancelling a change behaves as expected.
3.g.8) Verify that adding an ability and then removing it (from the same role) is not considered a "change".
3.g.9) Verify that making a change to a role, selecting a different role, then selecting the previous role again shows the previous change you made to that role.
4. Detailed plans for testing dependent code, including success and failure casses if possible.
Like most of the other groups related code, this is all intertwined. Hard to really describe code in which the code this test is written for depends on.
5. Requirements for gathering data on existing features being modified if applicable. Are user able to find the data they want about groups in the finder?
N/A
5a. Follow this with requirements for gathering data on new feature in new format, etc.
N/A
5b. Explain how to compare data to ensure new feature is not worse (i.e. lower framerate, higher bandwidth, more db queries, etc.)
N/A