This will simplify actions for future development and maintenance
since we can automate much more (such as auto-running show[Ajax|Page])
and handle errors of various kinds. Essentially the same kind of
improvements as Managed_DataObject gives us.
notice.id will give us even really old posts, which were
recently imported. For example if a remote instance had
problems and just managed to post here. Another solution
would be to have a 'notice.imported' field.
It seems it was only used to get a _single_ file attachment from
the posted notice, with no possibility to get multiple attachments.
If one fetches metadata about attachments for the notice, we have
enough data there to fulfill anyone's fetching dreams.
This makes it easier to disable, but remember that you must then
either enable and maintain queue daemons or disable queueing (and
handle whatever remaining queue items are stored in the database)!
Make the logic match the intent described in the comments.
The intent is clearly "accept notices whenever (A or B or C)", but
the logic implemented was more like "not ((not A) or (not B) or (not C))",
which is a basical boolean algebra fail (each of those ORs need to
become ANDs for double-negation to work).
The practical implication was that, for example, writing a reply
to someone else's notice and including an @-reference to _another_
user on another site to bring them into the discussion would
fail to deliver the notice to the new user because their server
would basically say `oh no, you can't message this user
from someone else's thread' because an earlier check for
the `A' or `C' parts of `(A or B or C)' prevents `B' from
being checked.
cf.: <http://status.hackerposse.com/notice/55846>, which was
refused by the nhcrossing.com server because it didn't know
about <http://sn.jonkman.ca/notice/93724>, even though it would
have passed the later `notice contains a reference to a local user'
check if not for an exception being prematurely thrown.
The whole idea of reporting `which specific check FAILED'
in an `if ANY SUCCEEDS' analysis is just bogus, so nix all of
the distinct ClientExceptions--a single `ALL FAILED' exception
is the only one that makes sense.
