Subcategories

Here are the initial rules around subcategories:

1. Like a category, a subcategory also defines a category of service that might be offered by a company.
2. The subcategory is a more granular, and specific, example of the parent category (e.g. "Trimming" is a more specific example of "Grooming").
3. Subcategories are only one level deep (a subcategory cannot have its own subcategories).

We need to define how categories are managed and used, within specific business processes and by each type of user "role" we have in the system. (role == admin || member || user || visitor (and, perhaps in the future, supporting member)).

Probably the best way to start is to create some user narratives here, which we can discuss and finalize - from which we can derive PT stories for implementation. We should not start with PT stories yet, as there is much discussion to occur at the SHF organization level about how subcategories will be used.

It might also be useful to think about a phased implementation. For instance, phase 1 could focus on an admin-centric set of processes. Phase 2 could bring in more capabilities for a member to perform limited management (such as create subcategories), etc. Phase 3 could extend capabilities to a user (such as the ability to specific both categories and subcategories in an application that has not yet been approved.

Phase 1 description (example narrative)

The admin can manage subcategories (created, edit, delete). No other role can do so.

A member can see subcategories associated with their business categories. A member can propose that one or more subcategories be added to their application. Associated with this request, the member can upload supporting documents. Each proposed to-be-added subcategory is now associated with the member's application. Each such subcategory also is assigned a status indicating that it is under review (note: probably also need to change the status of the application as well). This then initiates a review cycle.

The admin reviews the requested application changes, and this review looks much like the initial review cycle (admin can approve, reject, request additional info, etc.). After the admin review each proposed subcategory, the subcategory status is changed accordingly (accepted, reject). After all proposed subcategories have been reviewed, the application status (if change in prior step) is changed back to accepted.

NOTE: this stuff is difficult to write at the correct level - in the above, I may be getting too much into implementation detail. On the other hand, things like entity status as described are admin-visible items, and also drive the logic paths, so one can argue that this kind of detail needs to be specified in the narrative.