A-NO-NE Music wrote:
At this point, I would like to try having former students posting if they are into helping the new students. This might be a bad idea, but I think I would like to try.
I would create a separate role for your existing students -- this way, from an admin place, you could filter new from existing students based on role.
If you don't need to separate them, then I'd advise keeping one group.
I think so too. I made one group with sections by OG taxonomy. This should work for separating students group, right? One problem is Registration Key. I don't think I can assign a key per taxonomy.
Using OG Reg Keys, there is no way to separate by taxonomy. If you need that level of separation, then possibly separate groups are the way to go.
I guess I have to create a mandatory profile field on the reg page. Another question is if I won't get any problem mass-emailing per section? I haven't explorer notification module yet. I just wanted to make sure if notification will work fine this way down the road.
If you can get away with using core OG email functionality, I would try to just use that. First off, it will help you avoid module bloat; and second, it will be less complex to set up. Core OG supports mailing all members of a group.
Ooops. Hm. Can it be done manually without hacking the db? At least I need to separate/hide Class_1, which I already created tons of contents last semester, from the Class_2 group I am about to create. This is most scary. What can I do to solve this issue?
I would recommend checking out the Views Bulk Operations module -- it let's you process large groups of nodes in one fell swoop: http://drupal.org/project/views_bulk_operations -- I literally just used it (in conjunction with Workflow and Workflow Access) to set up a mechanism where editors can mass-approve (or demote) content. While getting into setting up workflow might be more time/effort than you want to expend at this point, Views Bulk Operations is probably the cleanest way to manage batches of nodes via the administrative UI -- unless, of course, you wanted to unpublish last terms nodes using the core content management UI at admin/content/node
Also, at the risk of stating the obvious, set up a test site to try these various methods on
Yup. I do have dev env on my MacBook Pro. I do local dev for my other sites (shown in my sig), but not for this site for my classes. The problem is that this particular ISP won't let me upload db. This is what you get when you get cheap. Moving along OG, I got so confused that I was afraid it won't be possible for me to reproduce the local settings on my live site so I started to do it on the live site. Yes, I should change my ISP. I know :-(
Glad to hear you have a test site; sorry top hear about the limitations of your ISP. RE OG: Chapter 12 in the book goes through the core OG config options in a fair amount of detail. If you're wrestling with setting up OG, it could be a good place to start.
Cheers,
Bill