BPlan Construction - Update #3

— June 1st, 2009 —

business plan competition + comptuers

Four days of work customizing Organic Groups and Views is tough enough. Doing it with a sinus infection is even tougher. I managed to get a lot of work done, but I never thought that administering and configuring Organic Groups (OG) would be so annoying!

Most of the changes were tightening up OG modules. What I have learned is that installing OG and other related modules is not very difficult, but configuring them, especially to work in any other purpose than their original intention, is very very difficult.

My first problem is that I want to change the names of things. I am a big fan of Drupal, but I don't think that most users of a site want to interact with such a ridgid system. I also don't want to use the same names and labels that OG module developers use. There are some things I just want to be able do:

1. I want to call the them "teams", not "groups"
2. I want to change the menu structure to my own desires
3. I want to use a different path, one that does NOT include "og"

This is just a beginning, but I had numerous issues with configuring Organic Groups. The first is that it doesn't use Drupal's menu system much. Instead, it uses Views. I really do not appreciate this because Views does not construct paths well. More importantly, Views does not work as well with URL aliases. In order to get cloes to implementing #1 and #3, I had to hack around for hours using hook_menu_alter() and hook_form_alter().

What I did:

• Created roles "Manager", "Team Leader", "Team Member", and "Team Owner"
• Added OG user roles module

Used OG user roles to automatically assign "Manager" to every group admin, "Team Owner" to every person who starts a team, and "Team Member to every team member. I intend to use "Team Leader" to control which users can be assigned a position/title.

By the way, I think OG user roles is a very messy module. The help text and fieldset descriptions are clumped together in an administration form that is devastating to handle. Furthermore, the module appears to be four different modules, packaged together under the banner of a role management module.

I expected it to create a sub-role system for Organic groups. I expected an API where OG modules could create permissions which were handled only on group pages and perhaps even with the addition to declare a page or a path (using wildcards '*' and '?') as a "group page". Instead, the module has a few set options that are a bit confusing and requires some complicated thought processes to set up correctly. Nevertheless, I did what I needed to do and set it up.

I installed OG Audience by Type, which allowed the audience to be segmented by their node type. Meaning, I could have the word "Team" being used on node creation forms instead of the word "Groups", which I liked.

I installed OG Titles to handle team leadership positions. My original intent is for it to be used for executive managers for the company created, but I am starting to think otherwise. Going through all these issues with OG, I don't think I want to mix OG with the actual business plan content types at all. Instead, I should probably use a simple user reference field grouped with taxonomies or something. Perhaps there is a lot I can do with taxonomies that I hardly ever do.

I tried a lot of other Organic Groups modules and ran into similar issues with them all being geared towards the one single agenda of running a "Google Groups" type website. I guess, you can also use it to set up Facebook type groups. However, if you want to call them anything different or change the paths they use or use real menu structures instead of Views, OG is actually a nightmare.

It would be nice if there were a lightweight groups module or if there were better written add-ons for OG. I'm not complaining too much, though. This is inconvenient, but still better than writing my own groups system.

After days of work, it finally started looking the way I wanted it to. I used the String Overrides module to change some strings from "group" to "team", but I have not noticed any changes yet. Again, because the OG module developers are a bit sloppy and don't use t() functions.

Overall, this experience is making me want to start developing a custom theme for my site to accompany my custom module in order to quickly erase some of the many issues I am having with some poorly written modules. Or, to at least give me some more flexibility.

What can be done so far:

• Users can create accounts, making them “Members”
• Members can add personal and professional information about themselves
• Members can apply to be “Entrepreneurs” or “Donors”
• Administrators can control the application process
• Entrepreneurs can create Business Projects and start Teams
• Entrepreneurs can associate Teams with their Business Projects
• Entrepreneurs can list their projects
• Members can join Teams
• Members can list their teams
• Members can list the content posted to their teams, called an Inbox
• Members have simple team functionality, such as viewing other members

What comes next:

• BACKUP DATA
• Create Business Plan content type

This may be very fun now that I am going to add the business plan node type. There are some modules which I have looked into that will help me do this. I have debated two options:

1. Create a single node type with many field groups (leaning in this directio)
2. Create multiple node types and link together
3. A mix of #1 and #2

The only reason I can see for #2 is if I wanted to duplicate certain areas. However, I don't think this will be the case, and if I need anything grouped together, I can just use node references, right? Anyways, we will see how it all turns out later.

Options: Leave A Comment

Next Entry: Competition Research
Previous Entry: Oh, Nigeria