Forum OpenACS Q&A: Re: Re: OpenACS.org upgrade (was: Openacs.org having problems. Refrain from using it until Sept 25th)

I do agree this information is useful, but to my knowledge it was removed from the toolkit on purpose. If not, it should be easy to reinstall the code from the old page and make all the additional information optional using an acs-subsite parameter.
Malte, all the links from the community member page to the user's contributed content, "were removed from the toolkit on purpose", years ago - which was a bug, and the bug has apparently still been in the toolkit all this time. openacs.org experienced this same bug when upgrading from OpenACS 3.x to 4.x, and it was fixed on openacs.org, but apparently, it was never fixed in the toolkit. Now someone needs to fix it again.

It is rather embarassing to see OpenACS perpetuate this particular bug over and over again. The page of links to the user's contributed content is perhaps the single simplest yet very valuable feature that ACS and OpenACS have always gotten right. (While every single other bulletin board or mailing list archive I've ever seen has always gotten wrong, by either never bothering to think about it at all, or by never having a central user data model to tie it to.)

Heck, Philip G. (and probably others as well) have written about the value of this one simple feature, both extolling its own usefullnes and using it to illuminate the benefits and community centric design of OpenACS as a whole - and yet openacs.org has broken it repeatedly, and now some of its own maintainers apparently don't understand its value! Not good.

Andrew, plain and simple, I'm all in for taking the links back as I think they are very useful. But due to our new rules, this has to be TIPed as it is a functionality change on a core package. So, it is not me not understanding it's value (and it's legal consequences in many countries, due to the fact that every registered member can see aggregated user behaviour on one page along with the name and e-mail of said user), but the fact that:

a) We decided to keep openacs.org on released code.
b) That particular piece of code has been taken out some time ago from the toolkit.

What I am going to do is write up a TIP and it would be great if you could help refining it and later on implementing it.

Malte, plain and simple, that sounds like a bunch of bureaucratic nonsense to me. It takes a TIP to add back the feature to openacs.org that you just removed during the upgrade, but it didn't take a TIP to remove it in the first place? That's just plain silly.

Running openacs.org off the stock toolkit is indeed attractive for various reasons, so I recommend simply adding the feature back, but with a setting to turn it on/off. Turn the feature on for openacs.org, leave it defaulted to off in the stock toolkit. Then at your leisure, write a TIP to change the default setting from off to on.