Forum OpenACS Q&A: Group bboards

1: Group bboards

Posted by Roberto Mello on 05/03/00 06:11 AM

Hi all,

    Can a bboard be made available only to a group ? I can't seem to find
out how.

    In the user groups admin pages, you can add modules for a certain
group but bboard is not there.

    Thanks,

    Roberto Mello

2: Response to Group bboards (response to 1)

Posted by Janine Ohmer on 05/03/00 03:57 PM

I just implemented this for a client (in ACS Classic :). There used to be support for Private bboards, which required a password for access, but that has been mostly ripped out even though you can still choose Private for the moderation style.

I won't offer to make code changes available yet, because the client claims he can get into a private bboard with an unauthorized user. I can't duplicate his results, but clearly something is still not right. In concept, what I did was this:

I added a new user group type called Private Topic. Then when a new bboard topic is being created, if it's moderation policy is set to private, a Private Topic group is created for it instead of an Administration group. This way only members of that group are able to see the topic.

Oh, this also requires fixing a bug where the group is created for the topic, but the group_id is never saved! In a way this bug is a blessing, though, because they put code in place to restrict viewers of the topic to the group, and you don't really want that if the group is an Administrative one as is created by default...

I'll try to remember to come back here and let you know when I've got it right. Roberto, feel free to e-mail to remind me if I seem to have forgotten :).

3: Response to Group bboards (response to 1)

Posted by Michael Feldstein on 05/03/00 04:03 PM

It's becoming increasingly clear to me that defining Groups is a central task in ACS that is currently very poorly documented. (When do you define them? Why? Which modules require them?) I volunteer to take on this documentation task as soon as I finish writing the spec for the proposed usability testing module (which should be done with a week or so).

4: Response to Group bboards (response to 1)

Posted by Roberto Mello on 05/03/00 05:21 PM

Not all modules have been "groupalized" I think, but quite a few have (news, calendar, faq, content sections, display, etc.) To define a group, just go to /admin/ug and define them.

You can associate several modules to different groups or different group types according to the group type definition. The documentation is there but it is not specific enough IMHO. Maybe some examples would help.

Basically you have to define a group type, which can have several groups inside it and each group can have subgroups. For our site (fslc.usu.edu) we created a group type called "FSLC Projects" so that the different members of the projects our club is involved in, can have their own news, calendar, etc.

The groups pages are accessible at /groups, which should show all the public groups. I wish each group could have a user-defined "Group Homepage".

Janine, thanks for the pointers. They are very helpful. It's nice to see flurfy folks around here. I think flurfly will contribute a lot to OpenACS by providing commercial hosting using it.

5: Response to Group bboards (response to 1)

Posted by Titi Ala'ilima on 05/03/00 06:03 PM

At Ybos we've put together a group-scoped bboard module so that any user group can have its own bboards. Any one willing to take on the task of porting it to OpenACS?

6: Response to Group bboards (response to 1)

Posted by Roberto Mello on 05/03/00 07:14 PM

Hi Titi,

I downloaded Ybos' group scoped bboard module and made a diff against our bboard module. I just looked at two or three files now for I have to study for my final tomorrow, but the changes are just in the Oracle/PG SQL dialects, besides the procs that you added.

I'll port it tomorrow and we could provide that as optional in OpenACS or maybe even integrate it. Supposedly aD is rewriting bboard to be group scoped isn't it ? But I need it now so I'll just do it.

One thing I noticed is that you removed many standard proc calls like [ad_pvt_home] for your own "Lisa Home" in the defs files. Why is that ? Isn't it easier to just leave these calls and use the .ini file to configure it ?

Thanks for making the module available.

7: Response to Group bboards (response to 1)

Posted by Titi Ala'ilima on 05/03/00 08:02 PM

Dunno where ACS is in terms of scoping the bboards. I kinda hope they burn the whole thing down and start over. We took out [ad_pvt_home]
for a client's site, and I figure we oughta fix that in our tarballs,
but we haven't gotten around to that yet. Can't just take care of that in the .ini files. We wanted to change context bars to direct to the home page instead of the workspace, which we would have had to change somewhere or another. Maybe tinkering with ad_pvt_home and ad_pvt_home_link would have been a slightly simpler solution.

8: Response to Group bboards (response to 1)

Posted by Ben Adida on 05/03/00 10:32 PM

Yes, it's *very* important that we not make the same kind of
mistakes that the ACS has sprinkled throughout, with direct
references to module locations and home pages.

The context bar has an option for not displaying the workspace,
and you could easily layer an abstraction on top of that to
prepend a link to the homepage. Just because it's Tcl doesn't
mean it can't be carefully designed for reuse :)

9: scoped module locations (response to 1)

Posted by Titi Ala'ilima on 05/03/00 10:48 PM

One other addition I threw into the scoped bboards was an abstraction
of module and module_admin paths so that scoped paths are preserved.
Check out the new ad_scope.tcl for ad_scope_module_url and ad_scope_module_admin_url.

10: Response to Group bboards (response to 1)

Posted by Michael Feldstein on 05/04/00 01:56 AM

Here's the latest description of the ACS Classic 4.0 plan for bboards:

http://www.arsdigita.com/bboard/q-and-a-fetch-msg.tcl?msg_id=0003ye&topic_id=ACS%20Development&topic=

11: Response to Group bboards (response to 1)

Posted by Naveen Agnihotri on 05/04/00 07:17 AM

Here's an example of how not to implement group scoping of the bboard module.

closedACS 3.2 (the glorious "MIT sucks!" release) comes with this glorious kludge: At the bottom of ad-custom.tcl.postload hides a filter that defines the function bboard_restrict_access_to_group for all URLs of the kind /bboard/*. Within this function, there is some logic of the kind of:


set has_access_p 0

if { $user_id > 0 } {
   .   
   .
   .
   do some stuff to check group_id, and
      if everything is ok, set has_access_p 1
   .
   .
}

if has_access_p is still 1, return filter_ok.

else, give a nasty "you are not allowed in the group that is
allowed to see this bboard" message.

This guarantees two things: First, it guarantees that anyone just clicking through the site without logging in (i.e., with user_id = 0) will not be granted access to any bboards. They will not be taken to a login screen. They will just be rejected.

But perhaps more importantly, this guarantees that the sysadmin trying to figure out why the heck non-registered users cannot see any bboards and looking in the normal places -- the bboard-related tcl library files -- will end up scratching their head: there is nothing there talking about how bboards are being scoped. The documentation doesn't talk about it, and the admin page for user groups doesn't list bboard as among the modules you can associate with any user group.

Nothing like a few minutes of grepping to provide me with a cheap sense of accomplishment!

12: Response to Group bboards (response to 1)

Posted by Peter Vessenes on 05/04/00 05:53 PM

I fixed that by returning filter_ok instead. A cheap hack to fix a cheap hack. And, yes, I was annoyed when I saw that.

13: Associating bboards with groups (response to 1)

Posted by Titi Ala'ilima on 05/04/00 05:58 PM

Group-scoping the bboards was a maddening process. I was originally hoping to implement some moderation while I was at it, but I got lost in the maze of legacy columns combined with columns added to enable future implementation. Anyway, I finally figured out that the way to get bboards to associate with groups was by adding a row into the table acs_modules (see modules.sql for examples of how this is done, or bboard-patch.sql in our module to see what we inserted for it.

14: Please be careful about dissing aD or ACS Classic (response to 1)

Posted by Michael Feldstein on 05/04/00 06:09 PM

Naveen, while I appreciate your comments about what needs to be improved in ACS Classic, I'd appreciate it if you'd tone your rhetoric down a notch. The OpenACS community needs to work as hard as we can to keep relations with aD and the larger ACS community as strong as possible. Please remember that the folks at arsDigita do read these boards and occasionally even post here.

We are all ambassadors for OpenACS. Let's try to keep our tone as civil and constructive as possible.

15: Response to Group bboards (response to 1)

Posted by Naveen Agnihotri on 05/04/00 06:42 PM

My profound apologies. I had no intention of dissing aD or ACS Classic. I was simply trying to point out something that, while being a (partially) working solution, is bad programming practice.

ACS is, of course, a very valuable, well organized tool. Kudos to the people who make it, and bless their heart for giving it away!

16: The official name of ACS Classic 3.2 (response to 1)

Posted by Naveen Agnihotri on 05/04/00 07:19 PM

I just got asked this in an email, so a clarification is in order: my calling ACS 3.2 the glorious "MIT sucks!" release is not my dissing on aD. That is the official name of that release!

This release was managed by the aD LA office composed almost entirely of Caltech people. (Aure tells me that official release names are bestowed upon a release by the release manager. It is placed in the first line of the index.tcl file of the pageroot directory of a default ACS distrib.)

So while I was pointing to some violation of SICP principles, I wasn't dissing MIT in some lame Slashdottish way!

Which brings me to this: Will OpenACS distrbitions have official release names?

17: Response to Group bboards (response to 1)

Posted by Michael Feldstein on 05/04/00 09:25 PM

OK, now it's my turn to apologize. I had no idea about the official release name. If the East and West Coast aD factions want to poke fun at each other, far be it from me to get in the middle.

Sorry, Naveen.

18: Bboards in General (response to 1)

Posted by Scott Mc Williams on 05/07/00 02:29 AM

Hi all, I just scanned the latest document that Michael aimed us at http://www.arsdigita.com/bboard/q-and-a-fetch-msg.tcl?msg_id=0003ye&topic_id=ACS%20Development&topic= and wanted to add an opinion from my side of the tracks.

As a web studio, we get called on to ad bulletin boards to a number of sites we do. We usually end up going with something prepackaged because the rest of the site is not a full ACS type community. The features that come in those packages are pretty standard, but they blow away an unmodified ACS Bboard. I can't imagine it would take too much work to see what other bulletin board system have and integrate those features into a standard ACS release. The data are there, they just need to be called! Take a peek at http://www.ultimatebb.com or http://www.ezboard.com to see some of these features.

Last but not least, check out the discussion Forums at http://www.edulix.com/bboard to see our latest hack of the ACS bboard. These are live forums, though...so please use caution! Thanks!

Scott

19: Groups & Bboards: How to - Late July 2000 (response to 1)

Posted by MaineBob OConnor on 07/28/00 03:32 AM

I'm reviving this thread which ended almost 3 months ago to see if there is new info.

I want to implement 3 forums for three groups:

Group 1: Guest Forum Read & Write "Public"
Group 2: Member Forum Read "Public" Write "Group"
Group 3: Special Forum Read & Write "Group"

In other words, users in Group 1 can read and post in the guest forum but can only read the member forum. Users in Group 2 can read and post in both forums. Only Group 3 has access to special forum.

I want a simple way to implement this and even though it's implied in /doc/bboard.html it doesn't appear possible without some code modifications. What do OpenACS people recommend? Any changes expected to make this easier in 3.2.4? (Which I expect soon!)

Has any OpenACS person used the "Group-scope BBoard Module" at http://www.ybos.net/modules/bboard.tcl? It appears to be designed for ACS Classic 3.2.

If not, I'd love to get a step by step on what needs to be fixed.

TIA -Bob

20: Response to Group bboards (response to 1)

Posted by Nathan Reeves on 09/19/00 07:20 AM

Yep, refreshing this thread again. Anyone get anywhere in porting the YBos Grouped BBoards??

21: Response to Group bboards (response to 1)

Posted by Michael Feldstein on 09/19/00 03:21 PM

I don't know if there's much point in working with Ybos code for this because ACS 4.0, which is due out early next month, will have group-scoped bboards. In fact, I believe that alpha2 is available today to play with.

Having said that, let me add two disclaimers. First, I have no first-hand familiarity with either the Ybos module or the ACS 4.0 bboard, so this is all going on what I've read. Second, if you're committed to using OpenACS 3.x for the foreseeable future, then the Ybos module may make more sense. I doubt the 4.0 bboard will port to 3.x.

22: Response to Group bboards (response to 1)

Posted by Michael Feldstein on 09/23/00 07:04 PM

aD has released an improved bboard for ACS 3.4 which includes, among other things, group scoping. Read more about it: http://www.arsdigita.com/bboard/q-and-a-fetch-msg?msg_id=000HAn&topic_id=175&topic=ACS%20Development

23: Response to Group bboards (response to 1)

Posted by Titi Ala'ilima on 09/25/00 05:37 PM

the main difference between the 3.4 bboards and the Ybos bboards is continuity of module scoping. the aD bboards have forums which are scoped, but that only serves to restrict whether or not a given user can see them, i.e. all public forums and all forums which belong to a group you are in are visible to you. With the Ybos bboards, given forums are only accessible within the right context, i.e. public forums are accessible from /bboard and group forums through /groups/group-name/bboard. Moreover, we carried the group look-and-feel (display module) through the whole module.

In the process of putting our version together, we discovered the scoping mechanisms have some great parts to them, but overall need a major overhaul. So it didn't seem worth it to re-do all of our work for 3.4, since 4.0 will be completely different (I hope)