I can't find any hint of the Reject exception that is supposed to 
exist.

Using:

       raise Reject, "You can't resolve this 
issue because
   dependedon issue(s) " +  " ".join(unresolved) 
+
   " must be resolved first."

results in an error unknown 
global Reject. Using:

       raise "Reject", "You can't resolve 
this issue because
   dependedon issue(s) " +  " 
".join(unresolved) + 
   " must be resolved first."

works, 
but I am not sure it is right. Is there a standard list of exceptions that 
can/should be thrown from detectors?

The Reject is talked 
about in the design document and seems to make more sense 
than the ValueError or roundupdb.DetectorError in the 
customization document.

Logged In: YES 
user_id=6405

Yeah, I strayed a little from the spec there. I can't just 
arbitrarily include a Reject exception in the modules - unless I 
fiddle with Python's __builtins__, and I really, really don't want 
to do that. So, I can add Reject to roundupdb, if you think it'll 
be used. 
 

Logged In: YES 
user_id=707416

Hmm, not sure why you need to much with __builtins__.
Can't you 
create a class of exceptions and just have the
detectors include then 
using the standard import
mechanism?

Hmm, now that I 
think of it, the detectors are pretty isolated
from the standard 
variables. So if I can't get to the global
variables, I can't get to the global 
exceptions.

I think its useful to have a standard set of exceptions 
to
raise for consistancy between the reactors. I am thinking of
(at 
minimum):

    PermissionError - user tried to do something that 
s/he
          didn't have permission to do.

    ValueError - user provided 
bogus data in some way

    Reject - Other rules are in place (besides 
permissions)
          to prevent the user from doing what they 
requested.

-- rouilj

Logged In: YES 
user_id=6405

Yeah, this seems reasonable. The upper layers of code will 
have to then handle those errors. 
 
Actually, I can see Reject and PermissionError being 
extensions of ValueError. 
 

Logged In: YES 
user_id=915812

I just came across this problem myself.

What I'm trying to do is use an auditor to extract special
information from the message content of incoming mail, then
remove the extracted information from the contents. If contents
are now empty, I'd like to veto the creation of the message, but
continue with the rest of the operation (e.g. create or
modify an
issue, but without a new message).

To be able to do that we'd need two kinds of Reject exceptions:

- one that aborts an operation as a whole (abort creating a new
  issue do to a badly formatted message), i.e. ValueError

- and one that only vetos the current operation, let's call it
  SingleReject.

While a ValueError would be allowed to traverse up through the
call hierarch to the general error handling stuff, the
latter would
have to be caught at various places, like in mailgw.py line 885:

    message_id = self.db.msg.create(author=author,...

where a SingleReject should be treated similar to a message
with empty content.

I don't know enough about roundup's internals yet to understand
what else might be affected. Certainly client.py though.

Am I making any sense? ;-)

Logged In: YES 
user_id=6405

Just to make it clear, I implemented Reject as described by SingleReject 
as below. Mostly.