Sometimes we just want to accept the user's wrong, but when it comes
to remote APIs etc. we probably want to let the client know it has
done something already (in this case multiple identical subscription
requests - which might indicate to it that it should refresh the sub
lists or something).
For example the public timeline would show notices from a user with
private_stream configured. (previously it would only hide _new_ notices
by this user as they would be the only ones with notice scoping set).
If a new file is uploaded, it will be matched with a previously uploaded
file so we don't have to store duplicates. SHA256 is random enough and
also unlikely enough to cause collisions.
If this merge throws exception on scripts/upgrade.php and you recently
tried a nightly (i.e. during 2015-02-19) then just go back a commit or two
and try again.
Or delete the duplicate entries. Find the entries like this:
SELECT COUNT(*), urlhash FROM file_redirection
GROUP BY urlhash
HAVING COUNT(*) > 1;
then for each urlhash (or come up with a smart SQL query) do:
DELETE FROM file_redirection WHERE urlhash='hashfrompreviousquery' LIMIT 1;
You'll have to remove duplicates more than once if you have >2 identical
urlhash entries. LIMIT -1 might do that for you. I'm not sure.
For some reason the "retweeted to me" part of the Twitter API was removed
when Evan made some inbox changes back in the StatusNet days. We might
recover this functionality, but not yet. The proper function calls are
however fixed in this commit.
Default is now to take still thumbnails of animated GIFs and then
show them as originals in an AttachmentListItem. The still frames
are mostly used with front-ends like qvitter.
The getUrl call would think that a File_thumbnail object was the child
of a local File if its filename was set. That has been true up to recent
development code where a File_thumbnail can have a 'filename' value,
but the original File does not. Only look at the File object to indicate
whether it's a local or remote file!
In some development code I noticed that when handling File objects without
filename values, there would be problems calling getPath and such.
The width and height value testing will be validated later anyway, and by
removing such a narrow test we can use events to generate thumbnails of
media formats supported by recently added plugins on demand.
