For groups that require a private scope, we force every notice to be limited to group scope.
Changed the group-discovery code so we only get groups once -- regardless if they were provided or not.
Notice::saveNew() now does these checks directly when making a repeat:
* make sure the original is valid and existing
* stop you from repeating your own message
* stop you from repeating something you've previously repeated
* prevent repeats of any non-public messages
* explicit inScope() check to make sure you can read the original too (just in case there's a funky extension at play that changes scoping rules)
These error conditions throw exceptions, which the caller either uses as an error message or passes on up the stack, without having to duplicate the checks in each i/o channel.
Numbered parameters when more than one used in a message.
L10n updates for consistency.
i18n for non-translatable exception.
Updated translator documentation.
Removed superfluous whitespace.
We disallow repeating a notice (or whatever) if the scope of the
notice is too private. So, only notices that are public scope
(available to everyone in the world) or site scope (available to
everyone on the site) can be repeated.
Enforce this rule at a low level in Notice.php, and in the API,
commands, and Web UI. Repeat button doesn't appear on tightly-scoped
notices in the Web UI.
We've been muddling through with 6- or 8-argument functions for managing streams. I'd
like to start thinking of streams as their own thing, and give them some more value.
So, the new NoticeStream class takes over the Notice::stream() function and Notice::getStreamByIds().
There's probably some fine-tuning to do on the object interface.
like leprous boils in our code. So, I've replaced all of them with //
comments instead. It's a massive, meaningless, and potentially buggy
change -- great one for the middle of a release cycle, eh?
As a hack this removes the mysql_timestamp bit from the field settings on reply.modified so that our value actually gets saved. This *should* work ok as long as system timezone is set correctly, which we now set to UTC to match when connecting.
