2.2.1: if-block leads to reject

[Alan DeKok]

Brian Candler wrote:
> I queried this a while ago, and it seems to be intentional (albeit
> sparsely documented) behaviour.

  I agree.  I have people working on documentation.  But it still
requires my input, and I'm all over the place with a number of projects.

> I wonder if this could all be made to work in a more intuitive way - for
> example, once a module has set "reject = 1" this status sticks until
> another 'real' module is called, as opposed to just update { ... }
> sections.

  It's hard to change in a stable version, because we should NOT be
breaking peoples configurations.

  That being said, the new module handling code is a lot clearer than
the previous code.  So it may be worth making this change for 3.0.

  I've looked at the "weird" behavior with empty sections.  The good
news is changing that is easy, and won't break working configurations.
So from now on, when you have:

	module1
	if (1) {
	}
	module2

  The "if" section gets skipped, and doesn't change the return code.

> Anyway, this is just something I've had to grit my teeth and bear with.
> It seems really weird, but eventually makes sort of sense. I ended up
> having to write a test suite (invoking radclient with all the different
> cases) to make sure they all worked the way I wanted.

  Yeah.  That code goes back to the earliest versions of the server, and
largely hasn't changed.  The good news is that it works.  The bad news
is that it's fairly opaque.

  But I think it's been a big benefit to the server.  The ability to
configurably process a list of modules is *very* useful.

  Alan DeKok.