Background

There is some confusion around some of the configurations for CiviVolunteer Projects. (See the linked issues, for example.)

On the create/edit projects screen, the Relationships section is used to determine which contacts have which kinds of administrative access to the project in question. It is also used to define the Beneficiary of the Project (i.e., on whose behalf are volunteers working?). The relationships are extensible, so users could also set corporate partners, etc.

The Volunteer Registration section of this page is used to allow project creators to specify which data they would like to collect from registering volunteers via selection of Profiles.

For seasoned users of CiviCRM, these concepts are familiar and the level of control is desirable. However, many organizations are allowing third parties to use these interfaces, and these users – many of whom have no previous exposure to CiviCRM and little to no training on how to use the system – can't make heads or tails of the settings.

Another use case: the organization is not allowing third-party usage of the system, but it is small and not technically sophisticated. Their CiviCRM provider wishes to streamline operations by limiting the number of choices they have to make each time they create a volunteer project.

To eliminate some of the confusion, we propose to give system admins more control over the volunteer coordinator experience.

Technical Approach

• We already have a way for administrators to set defaults for these settings (civicrm/admin/volunteer/settings). Let's have new releases of CiviVolunteer ship with sensible defaults. Okay, that was only partly true. VOL-202, which I have more or less completed, addresses the untrue part.
• Introduce two new permissions: Edit Volunteer Project Relationships and Edit Volunteer Registration Profiles.
• If a user has Edit Volunteer Project Relationships and a default is set, don't show that section of the form on create/edit. Otherwise, display it. I think the crossed-out check is unnecessary; the extension provides a set of defaults for all these settings, so it is hard to think of a scenario in which a default wouldn't be set.
• If a user has Edit Volunteer Registration Profiles and a default is set, don't show that section of the form on create/edit. Otherwise, display it. See comments above.
• Users upgrading from an earlier version of CiviVolunteer should see a pop-up explaining the new permissions.
• Up until now, the client (i.e., Angular) has concerned itself with providing defaults to the server, which has led to some difficulty (e.g., the current user doesn't have access to the default contact, or to an API needed to retrieve information about the default contact). Instead, we should do this on the server side, where we have the ability to easily skip permissions checks when appropriate.
• The API will enforce these new permissions; if a request comes in with project relationships, but the user doesn't have permission to modify them, they will be discarded.