Kabissa issues:
spec 1 and spec 2
- be more specific with multiple values and hard limit in. For now we are assuming multiple == 2
http://wiki.civicrm.org/confluence/display/CRM/Kabissa+Revised+Spec+1+-+Member+Signup
- Tobias reply: we have updated the spec with this - and agree 2 is a good number for multiple addresses etc.
- Edit Member Profile will basically take you to Edit Application
- All the frontend work is Kabissa responsibility. We'll give you the url to start or update a membership application
- Tobias reply: fine. I take this to mean that we are in charge of the "Step 1" part of the process, showing the "benefits and obligations of membership" which then provides a link to the signup form which you are in charge of.
- Pages are validated when they are submitted. i.e. page 1 is validated when page 1 is submitted
- Tobias reply: in our discussions we agreed that, since we do not want people to be registered in the system before we have their org details, we will validate/save the content after the process is complete. This is for the signup process - for the update process it does make sense to save each page individually as it is updated.
- All new applications when complete go into a "New Applications" group. (this is a static group)
- We will not be doing free tagging. If u want us to, we will but we also expect this to take 30-50 hours (at least) since we'll be educating ourselves about it
- tobias reply: ok - we will inform ourselves about this and see how we can handle it.
- define unique profile url format. This will be handled by the drupal kabissa module
- Edit Member Profile == Edit Application (can reuse the same code and plus its broken down nicely etc)
- View Member Profile, fair amount of information, will need a mockup
- Tobias reply: ok - will strive to get this to you
- Need to resolve if we should address any of priority 3. For now, we will only handle priority 1 and 2. We'll also do the 3-step applicaion form since that is part of the framework
- Tobias reply: ok in principle but need to know more granularly what the decisionmaking is. See the matrix we will upload shortly to the wiki.
- We will need templates of the approval / pending / reject / other emails which will be kept in a tpl file (i.e. changing it is quite easy).
- Tobias reply: will upload to the wiki.
- Member screens
- Create / Edit Application
- View Organization Info
- Member Locker (list of organization member can view / edit etc)
- Ability to add / remove a person with view/edit access to the organization profile
- Ability to agree to a relationship with an org
- Admin Screens
- Admin Locker (links to orgs in various groups)
- Processing application workflow screen
- Notice level workflow screen
- Review activity log for organizations
spec 3
- region == northern africa, country = Uganda, section = ???. We'll need mockups for the above screens
- What criteria should be searchable. mockup needed
- Integration of drupal search + member search. We'll need to do research etc on how to make this happen. Another 30-50 hour project
- Tobias reply: this is a big concern for us.
- math problem == captcha (since that is already part of civicrm)
- Tobias reply: we've discussed this and it will be implemented.
spec 10
- Integration with drupal roles and drupal permissioning is outside the scope of the project. We can write simple api's to expose civicrm information if needed
- Formatting is a bit messed up
spec 9
- Most of the functionality required is handled via CiviMail and/or "Send Email to Contact" functionality. I suggest kabissa use that since its not additional development needed
 If the workflow changes kabissa needs are more inline with what we want with CiviMail further down the line (like use message templates for mass mail), we will add those features as part of core civicrm. Note that templates are part of the "Send email to contacts(s)" functionality
- How do we identify which admin level member receives an email? do all admins get the email? can they opt-out? Most likely we will create the "admin only" list as a static group within the package
|
|
