Last updated by greggles on Tue, 2010-09-21 18:29
This is a site building recipe to build a private issue tracking system. It is still pretty experimental.
The goal is something kind of like BaseCamp or Unfuddle, but the recipe lacks many of the features provided by those services. You could probably add on more modules to match those services if you really really wanted to do so. Further, the goal is to create a site where people involved in different projects can login to the site but only see information related to their project (you might call these people clients). I've followed a pretty conservative path - I assume that some users will be confused by configuration and may make mistakes so I'd like the only way to make a mistake be that the content is hidden/private instead of shown. The big exception to this relates to files. I chose to use a public filesystem, but certainly if you really really care about the privacy of files you should use the private file system option.
Assumptions are that you want to create "projects" which are all separate "clients" and inside of each of those are
1. Documentation or discussion content
2. Issues for the project
3. (could be extended with) Events/milestones
- Start with Drupal core
- Install OG in two steps - install the "Organic Groups" module and then install the "Organic groups access control" module.
- Don't do any real configuration of OG just yet.
- Install Project module Project_issue and Comment Upload
- Edit the admin/content/types/project-project and make it a "Group node"
- Visit admin/content/types/project-issue and turn off "promoted to front page" enable "Standard group post (typically only author may edit). No email notification."
- Visit all the pages in admin/project and configure as appropriate
- Visit admin/og/og_access and set "Visibility of posts: " to be "Visible only within the targeted groups." and then "Private Groups: " to be "New group home pages and default audience are always private."
- Visit /admin/og/og and set things as appropriate - set the "Groups directory control" to "New groups don't appear in the groups directory. Administrators control the directory exclusively." and "Registration form control:" to "New groups don't appear on the registration form. Administrators control the form exclusively." and "Audience checkboxes" to on (maybe not...l) and "Audience required" as "required"
- Install OG Project
- Create a "client" role for clients - i.e. people who need access to information inside of project-groups.
- Grant the client role the ability to create and "edit own" on all the appropriate content types. Grant them "access comments" and "post comments" and "post comments without approval" and "access own projects" and "access projects" and "access own projects issues" and "access project issues" and "assign and be assigned project issues". Grant them the ability to set the appropriate issue statuses (probably all of these, but not necessarily). Allow them to "upload files" and "view uploaded files" so that they can post screenshots and maybe get/review patches.
- Edit the file extensions on admin/settings/uploads. You probably first need to grant more space in the file size per upload/per user. Also, allow lots of image types (screenshots) and common code file formats like "gz tgz patch diff test info po pot"
Ongoing Maintenance/Configuration
- If a project has a main person that is involved with it, it can be helpful to assign the project node to them (though this also has implications for OG, so be sure you trust that person). That provides the benefit of the "My Projects" link showing them their issues.
Known Weaknesses
- I've configured the ability to assign issues to other people. The "assigned" field doesn't seem to care which group a person is in.
- creating a new issue at example.com/node/add/project_issue/PROJECTNAME/bug should automatically select the group
- the link in the "Group details" block which automatically selects the Group should also automatically specify the project...
These will be fixed in future versions of OG Project
[Moshe: You can use hook_og_link_alter() or some similar function in D6 to change the links in the Group details block as needed. Similarly, you can preselect the group based on the project with a little hook_form_alter() glue code].
Comments
Yay, thanks!
This is great, thanks. I've been meaning to setup something just like this for ages, so it's slick to see that it's working with little or no custom code.
That said, any code to make this easier should probably live in OG Project. @greggles, I'd be happy to give you commit access if you'd like, or review/commit your patches. Either way...
I'm interested in thoughts
I'm interested in thoughts concerning the use of the CaseTracker module instead of project-issue? I've tried both and CaseTracker seemed more natural for a CRM. CaseTracker is based on project.
CRM?
Don't know what you mean by CRM in this context, but anyways ...
I used casetracker to do what Greg says: private areas for each client where client A does not see what client B is doing.
The components are cck, views, casetracker and og. Organic groups provides the isolation, cck provides the project and task content types, and casetracker makes the task content type have status, owner, ...etc.
Works well if all you want is tracking issues.
Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.
Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.
somewhat OT, but...future roadmap, giving back
--
Growing Venture Solutions | Drupal Dashboard | Learn more about Drupal - buy a Drupal Book
knaddison blog | Morris Animal Foundation
Awesome documentation!
We're using the same set-up at Agaric Design Collective, and it's going quite well.
Some custom code to correct the links and allow assignment of an issue to users within a group has proven key.
I'm honor-bound to contribute it as a patch to og_project, so let me finally do that...
benjamin, Agaric Design Collective
benjamin, agaric
I wanted to implement the
I wanted to implement the following:
1. Every group of users can see only their projects
2. They can create their own issues
3. They are not enable to see any other content on the site out of their project
4. They have their own frontpage that's the project page
I followed the steps above one-by-one but I'm forced to enable access content to be able to see the project/issues and this makes the project members to see other contents.
Also, could you advice how to redirect the user (after login) to the project page directly?
Thanks,
Rami
Posts without any groups are always Public
I had read this: "Posts without any groups are always Public."
So I have to make all old posts that don't have groups to belong to some group(s). Any idea for mass updation?
On D6, use Views Bulk
On D6, use Views Bulk Operations module
I'm using D5, I'll try it,
I'm using D5, I'll try it, it has D5 release. Thanks
Action missed
There's no action to assign the nodes to specific group/project!!! Is there a way to create this action?
Use OG Actions module for
Use OG Actions module for D5. It is part of core OG in D6.
D6 version
FWIW, I had been using this on D5, and migrated to D6 last year, but the migration path proved not to be really shock-proof. This may come from my using (and contributing some patches) project on this site since 4.6.x, which may mean an accumulation of approximative migrations.
Hope to find some time to make it cleaner with D7 Groups and current project* versions.