Affects Version/s: 2.0
Fix Version/s: 2.0
The flexible need is primarily used as a container for contacts who are interested in volunteering for a particular project, but who are not committed to a specific need. Without the flexible need, the Assign UI kind of falls apart.
- Update the form processing at civicrm/a/#/volunteer/manage/N such that, when the project is created, a flexible need is created and associated with it.
- Update the search to always include the flexible needs of active volunteer projects.
- In the Define UI, default the "Allow users to sign up without specifying a shift" checkbox to off. I think flexible sign-ups will become less useful with the emergence of the new vol opp search form.
- At least in the vol opps search UI, change "Flexible" labels to "Any role" and "Any time" – this language feels more appropriate in this context.
Rationale for #2: If no start time is set for a flexible need, it will never show in the search results. We either need to set the start time – like "open until filled" opportunities, which have the start time but not the end time or the duration set – or update the search to include anything with the "is flexible" flag ticked. If the goal is to deprecate the is_flexible field (and we've agreed in this issue and elsewhere that the model is overloaded and needs rethinking), then addressing it the way we address "open until filled" needs is more forward-thinking. Then again, legacy flexible need won't don't have the start date set, so they will be excluded from searches unless we write an upgrade script. That upgrade upgrade script would set the start date for legacy flexible needs to some arbitrary date, which feels wrong. Neither choice feels great, because we're accommodating the flexible need rather than eliminating it, but updating the search logic seems less wrong.
Rationale for #3: By default, flexible needs are public. Once we've addressed #2 above, they will show up in the search. In my opinion, exposing the flexible needs in the search results should require explicit user action. Pre-release use of CiviVolunteer 2.0 indicates that it is a common use case to use standalone volunteer projects for single-need projects – e.g., I have a need for a graphic designer that should remain open until it is filled (i.e., it doesn't expire). In this case, the flexible need adds clutter to the search results.
Another reason flexible needs should not be public by default: they won't fall off the available opportunities list without explicit user action: either the administrator marks the flexible need as not public, or she disables the project. Over time the flexible needs could really clutter things up.