New to v1.4, this case fails: Verify adding the member to the group when the member has "Partial Application" status and group has upper status than the member i.e. "Pending Approval " status.
Also: Verify adding the member to the group when the member has "Partial Application" status and group has equal status as of the member.
Testing reference - test case #'s ADDgrp-TC-015 and ADDgrp-TC-016
"1. Login with the user who has been assigned the right to add group membership. Search for an independent client.
2. Click on a client name.
3. On the Client Information page, click on ""Edit Meeting Schedule/Add Group"".
4.Click on ""click here to add group membership""
5.Specify the group name and click ""Search"".
6. Click on the group name.
7. Click ""Submit"".
8. Check the Group Membership and Meeting Details.
1.3 behavior: The client gets added, inherits the meeting schedule of the group and is displayed in the client details page.
1.4 behavior: "Customer cannot be added to an inactive group"
Not a showstopper, but is a regression so we should fix it
This was introduced in trunk r14263 in response to MIFOS-2210.
While it is not possible to transfer a client in "pending approval" or "partial application" state to a group in "pending approval" state, it is possible to create a new client under a group in the "pending approval" state. Should the restriction on "client transfer to group" be made consistent with "client creation under group", or is the desire that they be different?
If that was too confusing, here's two scenarios that can be quickly reproduced on the trunk test server:
== A. group must be active ==
follow repro steps in description. "pending approval" can't be transferred into a "pending approval" group.
== B. group can be "pending approval" ==
1. create new group, leave in "pending approval" state
2. create new client under that group, leave in "pending approval" state
seems to differ from (A) because client is allowed to be in the group even thouh the group is in "pending approval" state.
By the way, for the next person that looks into this, the check to make sure the target group for client transfer is active is in AddGroupMembershipAction#updateParent().
Fixed in trunk r16913 based on rules specified at http://www.mifos.org/knowledge/functional-specifications/account-creation/client-accounts#assigning-clients-to-a .
From IRC today (I'm "meonkeys"):
<meonkeys> kaychau: would you take a look at my question on (sent to the functional mailing list)?
<kaychau> meonkeys: okay ... quick answer is i think the answer is no, they should not be different - so client w/ pending approval should be allowed in pending approval group- though the bug is slightly different too I think it is talking about "partial application" - look here for the logic - http://www.mifos.org/knowledge/functional-specifications/account-creation/client-accounts#assigning-clients-to-a
Integration tests fixed in r16915.