Forum OpenACS Improvement Proposals (TIPs): TIP #72 (Withdrawn): Enhance community member information

1: TIP #72 (Withdrawn): Enhance community member information

Posted by Malte Sussdorff on 12/06/04 09:41 AM

Proposal

Enhance /shared/community-member to display additional information about a user that is currently only displayed for a site wide admin, depending on the setting of a parameter in acs-subsite. The additional information would be

Bugs (display_member_bugs)
Forums (display_member_forums)
ETP (display_member_etp_content)

I think the rest of the information is not useful for any outsider. This step is proposed for 5.1

In a second step for 5.2 the display should be changed to a template::list with pagination and the following information:

Type of object (Bug,Forum,ETP,...)
Title of object along with a direct URL to access this object (which will only work in 5.2) directly
Time of object creation

Obviously you should be able to order by all three information types and filter by date range and type of object.

Once approved, I'm willing to work on step 1 and look for funding for step 2.

Reasoning

After the upgrade some community members have been arguing that this information is critical for a community toolkit and should be displayable to users. I agree with this, but for the toolkit there needs to be the option to turn it off.

2: Re: #TIP 72 (proposed): Enhance community member information (response to 1)

Posted by Rocael Hernández Rizzardini on 12/06/04 05:46 PM

Hello Malte,

for the experience of Galileo installation, putting the info that is in:
/acs-admin/users/one?user_id=
as it is in /shared/community-member is not a good performance idea. For instance, if someone clicks on a member that has a bunch of contributions (in Galileo installation), basically the query is so heavy that takes a lot of time and consumes 100% of one of the CPU's (we have two xeon 3.0Ghz cpu's for PG only) for about 10-20 seconds. So we don't want the same code to be accessed by random users that want to know Don's posting history withouth even realizing that they are putting down openacs.org for their curiosity ;)

Maybe splitting the stuff will be a better idea (not showing everything in the same page rather than links for each item type).

I also need to mention that Telefonica I+D is working on user content aggregation for any application through service contracts (basically showing user contributions in one place), they already have some code working and the aim is to release it in january 05, so better not to duplicate the effort, that indeed, is needed. The code aims to replace user/admin & /shared/community-member.

3: Re: #TIP 72 (proposed): Enhance community member information (response to 1)

Posted by Dave Bauer on 12/07/04 05:54 PM

I agree with the goals of this TIP. I suggest we hold off until 5.2 since that will support title of all objects from acs_objects table and make this sort of feature easier to implement. The reason it was taken out is that the code did not discriminate between uninteresting objects and interesting objects so you ended up with a display of thousands of objects that should not be displayed to users. Definitely it should be configurable what object types are interesting.

4: Re: #TIP 72 (WITHDRAWN): Enhance community member information (response to 1)

Posted by Malte Sussdorff on 12/07/04 05:59 PM

I withdraw the tip taking future enhancements into account.

5: Re: #TIP 72 (Withdrawn): Enhance community member information (response to 1)

Posted by Andrew Piskorski on 12/08/04 02:26 PM

What was taken out of the OpenACS 4.x toolkit a long time ago, and what was taken out of openacs.org last weekend, are two completely different things.

The huge enormous random list of a bunch of mostly useless objects related to the user was first added in ACS 4.x, and removed ages ago from OpenACS, because it was useless junk.

openacs.org, on the other hand, until just a few days ago included a very useful and simple link from the community-member page to the Forums page displaying that user's Forums posts. This page was similar - although much less comprehensive - to the same functionality found in OpenACS 3.x. Is there really no such functionality in the OpenACS 5.x toolkit? (If so, that's just plain absurd.)

6: Re: #TIP 72 (Withdrawn): Enhance community member information (response to 1)

Posted by Andrew Grumet on 12/08/04 03:41 PM

Click on your own name in "Posted by Andrew Piskorski" above and I think you'll find what you're looking for.

7: Re: #TIP 72 (Withdrawn): Enhance community member information (response to 1)

Posted by Don Baccus on 12/08/04 05:45 PM

You mean that name's a link for a reason?!? Who woulda thunk it! :)

8: Re: Re: #TIP 72 (Withdrawn): Enhance community member information (response to 6)

Posted by Andrew Piskorski on 12/09/04 02:55 PM

No Andrew, that link is shown only within the Forums package - in order to see that link at all I must already be reading a post by that user. When I click my own name in the site-wide header above, the resulting pages and links give no way at all to find my list of Forums posts. Likewise, there is no way to find my Bug Tracker posts, nor any contributions whatsoever on the site. This is a Bad Thing.

9: Re: Re: Re: #TIP 72 (Withdrawn): Enhance community member information (response to 8)

Posted by Joel Aufrecht on 12/09/04 06:13 PM

I think the problem Andrew is describing is exactly what Malte's TIP addresses. The reason the TIP was withdrawn is that changes in OpenACS 5.2 will make it fairly trivial to implement, so we can do it there.

10: Re: #TIP 72 (Withdrawn): Enhance community member information (response to 1)

Posted by Jade Rubick on 12/09/04 06:26 PM

Until 5.2, why don't we include a link to the forums page, if forums is installed? It's a hack, but we can remove it in 5.2.

11: Re: #TIP 72 (Withdrawn): Enhance community member information (response to 1)

Posted by Don Baccus on 12/09/04 06:38 PM

Why don't we just bust our ass and get 5.2 out in six weeks? :)