Show Members in Superordinate Nodes

1 Requirements

In the current implementation of the Study Programme it is possible to assign a member at any node in the programme. The member then only is shown on the members-tab on the node where she is assigned and on the members-tabs of the subsequent nodes, but not on the members tabs on the nodes above. The idea that lead to this decision was, that there would be study programmes where the different parts are supplied by different departments in an organisation (e.g. institutes at an university). It then should be possible for those departments to assign members to their parts of the programme without implying that these are visible in the superordinate nodes.

This, however, is not enough to represent some real world use case of the SP. The root node of the programme there is only understood as a container, where the subordinate nodes represent the very same programmes supplied by different providers. A member then only has to complete the programme at one provider. The member also is assigned by the provider at the node of the provider. For the central organisation, managing and controlling the members of the programme at all providers, it should still be possible to view all members of the programme at the root node.

To implement this requirement while maintaining the idea, that a department should be able to add members to its nodes without making them visible in superordinate nodes, a setting "Show Members in Superordinate Nodes" should be introduced. If that option is set at a programme, all members visible at the members tab of the programme will also be visible on the members tab of the node directly above. The members won't be shown at the nodes above the direct superordinate node, unless that node also sets the "Show Members in Superordinate Nodes"-option (and so on for the nodes above that).

At the superordinate node, it won't be possible to accredit the user, as he does not need to complete the superordinate node (she was assigned at the node below that). It also won't be possible to remove the user, as he is not assigned at the node in question but a node below. It also won't be possible to show the individual plan of the user, as this would also imply editing that plan, which would break the assumption that the controller of the node where a member was assigned is reponsible for the conditions for completing a programme.

2 Additional Information

• Idea / concept: Marko Glaubitz, Richard Klees <richard.klees@concepts-and-training.de>
• Interest in funding: (please indicate if you are interested/able to fund this feature)
• Maintainer: Richard Klees <richard.klees@concepts-and-training.de>
• Implementation of the feature is done by (will be set by Jour Fixe / maintainer)
• Testcases by: (please add your name if you want to create the testcases for this feature)

3 Discussion

4 Implementation

{please give a description of the final implementation and add screenshots if possible}

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.