Index: openacs-4/packages/acs-subsite/www/doc/group-admin-pages-acceptance-test.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-subsite/www/doc/group-admin-pages-acceptance-test.adp,v diff -u -r1.2.2.4 -r1.2.2.5 --- openacs-4/packages/acs-subsite/www/doc/group-admin-pages-acceptance-test.adp 9 Jun 2016 08:53:54 -0000 1.2.2.4 +++ openacs-4/packages/acs-subsite/www/doc/group-admin-pages-acceptance-test.adp 1 Jul 2016 09:11:53 -0000 1.2.2.5 @@ -92,30 +92,30 @@
    -
  1. Go to /admin/group-types and select "Developer defined -test types"
  2. Add a permissible rel type of Membership +
  3. Go to /admin/group-types and select "Developer +defined test types"
  4. Add a permissible rel type of Membership Relation
  5. Add a group named "Test group"

GROUP TYPE PAGES BASIC FUNCTIONALITY

(Start at /admin)
    -
  1. Click on group types
  2. Click on Groups
  3. Click on "Group name" under "Attributes of this type of -group"
  4. Ensure that you see the properties of the attribute and +
  5. Click on group types
  6. Click on Groups
  7. Click on "Group name" under "Attributes of +this type of group"
  8. Ensure that you see the properties of the attribute and that you are offered no administrative links
  9. Make sure you cannot add attributes or do anything under administration
  10. Make sure you see Composition and Membership Relation as -the default relationship types
  11. Add a new group called "Foobar" - Make sure Foobar -appears after adding the group
  12. Click on Foobar
  13. Click on nuke this group then click no. Ensure group is +the default relationship types
  14. Add a new group called "Foobar" - Make sure +Foobar appears after adding the group
  15. Click on Foobar
  16. Click on nuke this group then click no. Ensure group is not deleted
  17. Click on nuke this group then click yes. Group should no longer show up
  18. Recreate the group Foobar
  19. Click on foobar, then change the name to -"ArsDigita"
  20. Change ArsDigita's join policy to closed
    21. +"ArsDigita"
  21. Change ArsDigita's join policy to closed

DYNAMICALLY EXTENDING GROUPS

(Start at /admin/group-types/)
    -
  1. Click on "Define a new group type" and create a new group -type called "Project" with type "project". Ensure that all the -fields you see are required (try submitting without entering in -anything).
  2. Define another group type, child of group, named +
  3. Click on "Define a new group type" and create a +new group type called "Project" with type +"project". Ensure that all the fields you see are +required (try submitting without entering in anything).
  4. Define another group type, child of group, named "Test"
  5. Define another group type, 'subproject', child of project. Ensure that the index page correctly displays the hierarchy.
  6. Define a new group type with group type = group. See @@ -126,35 +126,38 @@ default relationship types
  7. You have a link to change the default join policy
  8. You have a link to delete the group type
    9. -
  9. Click on "Add a permissible relationship type." Ensure -that you are not given a select bar but are offered a link to -"create a new relationship type"
  10. Create a group of type test.
  11. Delete the test group type (first verify that the cancel -button works)
  12. Go to the "project" group type
  13. Add a required attribute called "Project type" of -datatype enumeration. Values are "Client" "Toolkit"
  14. Add an optional attribute "Monthly fee" of type integer -and default of "10000"
  15. Add a third attribute called test.
  16. Make sure you can see all the attributes. Delete the test +
  17. Click on "Add a permissible relationship type." +Ensure that you are not given a select bar but are offered a link +to "create a new relationship type"
  18. Create a group of type test.
  19. Delete the test group type (first verify that the cancel +button works)
  20. Go to the "project" group type
  21. Add a required attribute called "Project type" +of datatype enumeration. Values are "Client" +"Toolkit"
  22. Add an optional attribute "Monthly fee" of type +integer and default of "10000"
  23. Add a third attribute called test.
  24. Make sure you can see all the attributes. Delete the test attribute
  25. -Go to "/admin/object-types/one?object_type=project" and -ensure that start_date and monthly fees are listed as attributes. -Also make sure:
      +Go to +"/admin/object-types/one?object_type=project" and ensure +that start_date and monthly fees are listed as attributes. Also +make sure:
      • test attribute is not visible
      • monthly_fee has a default specified (NULL) in the pl/sql parameter list
      • start_date has no default specified
      -
    • Go to "/admin/object-types/one?object_type=subproject" -and ensure the new attributes of project are in the pl/sql +
    • Go to +"/admin/object-types/one?object_type=subproject" and +ensure the new attributes of project are in the pl/sql package
    • Now go back to the group type admin page for the -"Projects" group type. Remove the composition relation. Make sure -you get a link back to add a relationship type. Add back the -composition relation.
    • Add a group of type project named +"Projects" group type. Remove the composition relation. +Make sure you get a link back to add a relationship type. Add back +the composition relation.
    • Add a group of type project named GuideStar.org

RELATIONSHIP TYPE PAGES BASIC FUNCTIONALITY

  1. Create a new relationship type, Employment relation, that is a subtype of Membership relation, between group and person. Group has role of employer, person role of employee.
  2. Select the employment relation and add an attribute age -(integer, not required)
  3. Delete the employment relationship type.
  4. Re-add the employment relationship type (we're testing to -make sure the age attribute is correctly removed and flushed from -the cache)
  5. Click on membership relation, then click on create +(integer, not required)
  6. Delete the employment relationship type.
  7. Re-add the employment relationship type (we're +testing to make sure the age attribute is correctly removed and +flushed from the cache)
  8. Click on membership relation, then click on create subtype
  9. Click on membership relation -> Create subtype type: project_lead_relation name: Project Lead between projects (the composite) and persons (the project leader new role)
  10. Create a new, dummy rel type, subtype of Project Lead @@ -168,35 +171,37 @@
  11. Go back to the admin page (/admin)
  12. Click on the Groups -> GuideStar.org. Add ArsDigita as a component
  13. Remove the composition rel type from this group
  14. Readd the composition rel type. Make sure arsdigita -doesn't show up
  15. remove the composition rel type
  16. Add a permissible rel type: +doesn't show up
  17. remove the composition rel type
  18. Add a permissible rel type: project_lead_relation
  19. Click yes to create a rel segment named "GuideStar Project Leads"
  20. Go back to /admin/groups
  21. Click on "relationship to site"
  22. Remove yourself from the group.
  23. Add yourself again as a member (using the membership relation). You will have to select an existing party from the -system.
  24. Make sure you see the segment "Main Site Members" for -parties with a membership relation to the main site.
  25. Go to the ArsDigita group.
  26. Add guidestar.org as a component
  27. Remove the membership relation type from this -group
  28. Add the employment relation type
  29. Create a segment named "ArsDigita employees"
  30. Add a constraint named "ArsDigita employees must be Main -Site Members" for employees and the segment "Main Site -Members"
  31. Go back to the guidestar.org group
  32. Add yourself as a project lead.
  33. Click on the project lead segment "GuideStar Project +system.
  34. Make sure you see the segment "Main Site +Members" for parties with a membership relation to the main +site.
  35. Go to the ArsDigita group.
  36. Add guidestar.org as a component
  37. Remove the membership relation type from this +group
  38. Add the employment relation type
  39. Create a segment named "ArsDigita +employees"
  40. Add a constraint named "ArsDigita employees must be +Main Site Members" for employees and the segment "Main +Site Members"
  41. Go back to the guidestar.org group
  42. Add yourself as a project lead.
  43. Click on the project lead segment "GuideStar Project Leads"
  44. Click delete this segment. Say no.
  45. Click delete this segment. Say Yes.
  46. Recreate the "GuideStar Project Leads" -segment
  47. Add a constraint named "Project leads must be employees" -that says all "project leaders must be employees of -ArsDigita"
  48. Make sure you see yourself as a violation. Remove the +segment
  49. Add a constraint named "Project leads must be +employees" that says all "project leaders must be +employees of ArsDigita"
  50. Make sure you see yourself as a violation. Remove the violating relation and finish adding the constraint
  51. Try to add a project leader to guidestar. You should see -that there "There is no other Person that can be added as Project -Leader to GuideStar.Org"
  52. Add yourself as an arsdigita employee
  53. Make yourself the project lead on -guidestar.org
  54. Go back to /admin/groups and select "relationship typ -site." Remove your membership relation. You should get prompted to -remove relation to arsdigita, then to guidestar. Remove all of -these relations.
  55. Make yourself a project lead of guidestar +that there "There is no other Person that can be added as +Project Leader to GuideStar.Org"
  56. Add yourself as an arsdigita employee
  57. Make yourself the project lead on +guidestar.org
  58. Go back to /admin/groups and select "relationship +typ site." Remove your membership relation. You should get +prompted to remove relation to arsdigita, then to guidestar. Remove +all of these relations.
  59. Make yourself a project lead of guidestar again.

Testing with more Users

-Now we're going to test that the user interface remains +Now we're going to test that the user interface remains consistent if there are a few more users.
    -
  1. Go to /acs-admin/users and add 4 users
  2. Go to /admin/groups and click on "relationship to site." -You should see all of the people you just entered listed as members -of the subsite.
  3. Try to remove your Membership relation. You should see +
  4. Go to /acs-admin/users and add 4 users
  5. Go to /admin/groups and click on "relationship to +site." You should see all of the people you just entered +listed as members of the subsite.
  6. Try to remove your Membership relation. You should see only one constraint violation.
  7. Remove one of the other people from the registered users group. You should be allowed to do it immediately.
  8. Add back the person you removed.
  9. Remove yourself from the registered users group. Make yourself a project lead on guidestar again.
  10. Make another user a project lead on @@ -207,7 +212,8 @@
  11. Go to /admin/group-types
  12. Select the project group type
  13. Delete this group type. Should get prompted to delete sub projects group type.
  14. Delete the sub projects group type.
  15. Should get prompt to delete the project lead rel type
  16. Delete the project lead rel type. Continue until you -delete the project group type.
  17. Delete the ArsDigita group.
  18. Go to /admin/rel-types/
  19. Click on "View all roles"
  20. Click on "Project Leader" - delete this role
  21. Click on "Employer" then on Employment +delete the project group type.
  22. Delete the ArsDigita group.
  23. Go to /admin/rel-types/
  24. Click on "View all roles"
  25. Click on "Project Leader" - delete this +role
  26. Click on "Employer" then on Employment Relation
  27. Delete the employment relation type.
  28. Delete the employee, employer, and project_leader roles
  29. Delete any groups you created for the developer defined type
  30. Index: openacs-4/packages/acs-subsite/www/doc/group-admin-pages-design.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-subsite/www/doc/group-admin-pages-design.adp,v diff -u -r1.2.2.3 -r1.2.2.4 --- openacs-4/packages/acs-subsite/www/doc/group-admin-pages-design.adp 9 Jun 2016 08:53:54 -0000 1.2.2.3 +++ openacs-4/packages/acs-subsite/www/doc/group-admin-pages-design.adp 1 Jul 2016 09:11:53 -0000 1.2.2.4 @@ -15,13 +15,13 @@

    II. Introduction

    -The group administration packages provides a "control panel" to -allow the administrator of a subsite to control the groups in use -on that subsite. Administrators manage the types of groups in use -on a subsite. For each of these group types, the administrator can -create new groups, specify applicable relationship types, create -relations between these groups, and modify attributes of the types -and groups. +The group administration packages provides a "control +panel" to allow the administrator of a subsite to control the +groups in use on that subsite. Administrators manage the types of +groups in use on a subsite. For each of these group types, the +administrator can create new groups, specify applicable +relationship types, create relations between these groups, and +modify attributes of the types and groups.

    III. Historical Considerations

    Versions 4.0.x of the ACS lacked a useful group administration @@ -111,8 +111,9 @@ constraint acs_obj_types_dynamic_p_ck check (dynamic_p in ('t', 'f')) -

    Note that the dynamic_p is still experimental -and may be removed in a future version of ACS

    +

    Note that the dynamic_p is still +experimental and may be removed in a future version of +ACS

    VII. Data Model Discussion

    ... @@ -138,9 +139,9 @@

    We also may add a few additional package parameters including:

      -
    • "Create Group Types" (Boolean). Determines whether new group -types can be created dynamically.
    • "Create Relationship Types" (Boolean). Determines whether new -relationship types can be created dynamically.
      • +
    • "Create Group Types" (Boolean). Determines whether +new group types can be created dynamically.
    • "Create Relationship Types" (Boolean). Determines +whether new relationship types can be created dynamically.

    XI. Authors

    Index: openacs-4/packages/acs-subsite/www/doc/group-admin-pages-requirements.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-subsite/www/doc/group-admin-pages-requirements.adp,v diff -u -r1.2.2.4 -r1.2.2.5 --- openacs-4/packages/acs-subsite/www/doc/group-admin-pages-requirements.adp 9 Jun 2016 08:53:54 -0000 1.2.2.4 +++ openacs-4/packages/acs-subsite/www/doc/group-admin-pages-requirements.adp 1 Jul 2016 09:11:53 -0000 1.2.2.5 @@ -17,11 +17,11 @@

    II. Vision Statement

    From /doc/subsites-requirements.html:
    The other piece of the subsite system is a -subsite package that provides subsite admins a "control panel" for -administering their subsite. This is the same package used to -provide all the community core functionality available at the -"main" site which is in fact simply another -subsite.
    +subsite package that provides subsite admins a "control +panel" for administering their subsite. This is the same +package used to provide all the community core functionality +available at the "main" site which is in fact simply +another subsite.     This control panel needs to treat individual groups as belonging to a single instance of a subsite. However, groups themselves are not enough. We must allow a subsite to specify its @@ -42,11 +42,11 @@

    IV. Use case and User Scenarios

    The Intranet Application

    The Intranet application may model employees in many ways. -Without loss of generality, we assume each employee is a "person" -with an "employment relation" to a company. Figure 1 shows an -outline of what the ACS Site Map may look like with several -companies. Note that each company represents one instance of the -intranet application.

    +Without loss of generality, we assume each employee is a +"person" with an "employment relation" to a +company. Figure 1 shows an outline of what the ACS Site Map may +look like with several companies. Note that each company represents +one instance of the intranet application.


    Figure 1: Structure of Multiple Intranets
    @@ -76,19 +76,23 @@ groups

    The administrator must be able to specify the permissible relationship types to use for each group. The defaults are inherited from the list of permissible relationship types for the -group's type.

    +group's type.

    VI.B Requirements: API

    -
    20.10 Define a new group type

    Users should be able to create a new type of +

    20.10 Define a new group +type

    Users should be able to create a new type of group.

    30.10 Specify attributes

    Users should be able to dynamically add attributes to group types. These attributes should be stored efficiently.

    35.10 Remove attributes

    Users should be able to dynamically remove attributes from a group type. Removing the attribute removes all values specified -for that attribute.

    40.10 Relationship Constraints

    The API must support the following types of constraints on -relationships:

    40.10.10 Permissible relationships

    Each group type should maintain a list of all relationship +for that attribute.

    40.10 Relationship +Constraints

    The API must support the following types of constraints on +relationships:

    40.10.10 Permissible +relationships

    Each group type should maintain a list of all relationship types that can be used to add elements to groups of this group -type.

    40.10.20 Constraints on relationships

    Relationships listed as allowable for a given group type +type.

    40.10.20 Constraints on +relationships

    Relationships listed as allowable for a given group type should link to more information about the relationship type, including any constraints that must be satisfied before relations of the specified type are created.

    40.10.30 Constrain membership to a given @@ -103,7 +107,8 @@ 100.10 Create a group type with attributes

    When creating a new group type, the UI should support ACS datatypes with appropriate UI.

    -130.10 Group type summary page
    +130.10 Group type summary +page
    130.10.10 Display allowable relationship types

    The group type summary page should display all the @@ -112,19 +117,21 @@ existing ones.

    130.10.20 Display groups

    Display all groups of this type, based on permissions. UI should scale well with a large number of groups.

    -110.10 Create an instance of a particular group -type

    When creating a new group of the specified type, the UI +110.10 Create an instance of a +particular group type

    When creating a new group of the specified type, the UI must request values for each of the attributes of that type, including attributes of all supertypes (up the type tree until the object of type 'group').

    -130.10.20 Display type attributes

    Display all attributes for this group type, including +130.10.20 Display type +attributes

    Display all attributes for this group type, including supertypes.

    130.10.20 Delete group type

    Allow administrators to delete the group type. This action removes all groups of this type.

    -150.10 Group instance summary page
    +150.10 Group instance summary +page
    150.10.10 Display relations

    Each group should display all the parties related to it @@ -135,8 +142,8 @@ each.

    150.10.20 Delete group

    Allow administrators to delete the group including all relations to the group.

    -150.20 Integration with relational Segments and -Constraints

    The group summary page should offer links to define +150.20 Integration with relational +Segments and Constraints

    The group summary page should offer links to define relational segments for the group, based on a particular relationship type. The UI must also integrate with the relational constraints data model to support defining constraints on