Forum OpenACS Q&A: Spam... A good example of a general problem

1: Spam... A good example of a general problem

Posted by defunct defunct on 03/28/02 04:21 PM

Folks,

Whilst testing Spam I came across a situation which I think is not that uncommon and I thought I'd mention it here to get some direction.

Basically when I create a new spam as the admin user everything works ok.

However when I then log in as a user with only read permissions (the default) then that user, from /spam/index can see *all* spam queues past and present.

Its deliberate.... but is it correct?

I personally don't think that by default, *any* package should make other peoples information available unless its a specific requirement.

Why should a user by default be able to see all my admin queues?

Ok, so. I've failed the package in acceptance testing (strict ain't I) so is this an SDM candidate?

Also, should we consider this a general test/requirement i.e. packages should have a proper, explained permissioning policy governed by an overall system policy.

Thanks

Simon

2: Response to Spam... A good example of a general problem (response to 1)

Posted by Jon Griffin on 03/28/02 04:27 PM

It is wrong, there is no ifs ands or buts.

ACSclassic never had any testing so I wouldn't be surprised if there are a lot of screwed up permissions. Many of the modules were ported by people who didn't understand 4.x and therefor we have the mess that exists today.

I am not sure we should hold up the release searching for all these problems though as the ones that are found should be easily fixed.

3: Response to Spam... A good example of a general problem (response to 1)

Posted by Jon Griffin on 03/28/02 04:29 PM

After reading my last post, I want to clarify -- people porting from 3.x to 4.x at AD, not the openacs port.

4: Response to Spam... A good example of a general problem (response to 1)

Posted by defunct defunct on 03/28/02 04:59 PM

Thanks Jon, I agree entirely.

I guess this also highlights an important problem for testers/developers.

Its extremely difficult to know which packages are good, which ones suck, which ones are taking the right approach which are using slightly dodgy approaches.

Again this overall ACS problem is a lack of consistency.. Too many solutions to one problem, but none of them 'properly' done and tested.

I personally think there's something harsher required. I actually think (and I guess its Don's call) that a large percentage of this toolkit should be dumped/binned immediately, if for no better reason than for clarity.

By way of example I think the forms system is a good example of this. There's a functional templating method building up in the tcl/adp approach and this should be extended. Then there's a forms based interface for generating forms that have no inherent relation to the templating system and not only that produce pretty crappy looking items of limited value given that most commercial web applications get highly customised. (I mean you may as well use Remedy if you want a crap interface done badly but quickly)

But... they both hang around the system, they both have errors, they both require answering questions, imporved docs and so forth... and worst of all they boht need testing!

Sometimes you have to be cruel to be kind, and perhaps some judicious pruning at this juncture might be good for us all..

Any thoughts?

Its gotta be better to do a few things well than keep supporting multiple, lower quality packages?

If nothing else, is it worth reviewing the 'develope guidelines' and standards and rating each package against it. At least then its clearer which ones are good exemplars and which are not.

Cheers
Simon

5: Response to Spam... A good example of a general problem (response to 1)

Posted by Jonathan Ellis on 03/28/02 05:21 PM

I would agree with Simon. It's hard enough to learn a new toolkit without "bad examples" mixed in with the good and not being able to tell which is which.

6: Response to Spam... A good example of a general problem (response to 1)

Posted by Jade Rubick on 03/28/02 07:01 PM

Perhaps what we could do is pare down the default installation to those modules that are maintained and in fairly good shape. Then we can have another place to refer people to for the code for the more undeveloped packages?

7: Response to Spam... A good example of a general problem (response to 1)

Posted by Don Baccus on 03/28/02 10:50 PM

I personally think there's something harsher required. I actually think (and I guess its Don's call) that a large percentage of this toolkit should be dumped/binned immediately, if for no better reason than for clarity.

I've struggled with this myself. The problem is that even the packages that are poorly written work well enough not to be totally useless. So my own thinking has been that these packages are OK as stop-gap measures but need to be heavily modified or rewritten as a top priority.

 By way of example I think the forms system is a good example of this. There's a functional templating method building up in the tcl/adp approach and this should be extended. Then there's a forms based interface for generating forms that have no inherent relation to the templating system and not only that produce pretty crappy looking items of limited value given that most commercial web applications get highly customised.
I'd disagree about the forms package, actually. I hate the default "two shades of blue" template and have considered asking folks if they'd mind just having the default being good old "black ink on white paper". But ... you can template forms yourself, too.
And the forms system gives much improved error messages if used properly, i.e. embedded in the form. Much better than the "please hit the back button and, oh, try not to screw up this time, OK?" error page you get from ad_page_contract.
We've had a discussion on the forms builder in the design forum and the consensus then seemed to be that we needed to greatly improve integration with the rest of the toolkit (same is true of the templating system in general). I'd like to be able to build self-submitting form handling pages with an ad_page_contract-style syntax (there's no reason we can't parse form element names, types, default values, etc and generate the elements directly rather than force folks to issue a long string of "form element" calls).
And of course I'd like the full ad_page_contract-style feature set, with checks for bogus HTML (or the ability to refuse HTML), signing and verification, etc ...
But I personally don't think we should dump it. I think we should fix it ...

8: Response to Spam... A good example of a general problem (response to 1)

Posted by Allan McKinnon on 03/29/02 05:34 PM

Okay - time to bell the cat.

If a user wants a 'good' example of an existing package to provide a service what existing package(s) should they be using as their model?

If a user wants a 'good' example of an existing package that saves content and provides many user io forms etc, what existing package(s) should they be using as their model?

This thread should end on the identification of 'best packages' so amateurs like myself don't inadvertently model our efforts on the worst examples the toolkit has to offer.

I would concur that we're better to release a handful of well tested and functional packages than to have every new users fall into the same weasel traps time and again.