For a Notice object with multiple results, ->getProfile() would ALWAYS
return the first profile in the list. For example our "popular notices"
stream ended up believing all notices were made by the same profile.
Added the following FIXME:
How should a Twitter user get their Inbox filled with foreign tweets?
Every imported Twitter user has a profile in the Profile table, so we
could setup a Subscription entry for each of those, meaning they get
collected in the InboxNoticeStream... But this would mean a lot of
unnecessary entries and listings that generally just point to the
locked down Twitter service.
Let's figure out a good relation so we can connect any profile to any
imported foreign notice, so it shows up in the "all" feed.
This will work without much extra effort because there will always be
more notices (higher value) than conversations (so no collisions).
But please run upgrade.php to avoid having an autoincrement id on
conversation table.
Installations using code after 2014-03-01 will have identical
conversation IDs to the initial (conversation root) notice IDs. This
will not affect older installations, which will have very different
values.
Also removed the entirely unused saveGroups function.
Now avoiding multiGet and using listFind in Profile->getGroups()
so we don't have to deal with ArrayWrapper.
NoResultException was the wrong choice in this case, because it was
not a DB_DataObject instance that performed the search, but a static
call to the Notice class.
This reverts commit 8cc4660bd9.
This seems like something Evan only did to make pump.io import notices easier,
or maybe he just wanted to get rid of the identi.ca URLs?
This is the beginning of getting notice URI info via WebFinger
*XrdActionLinks is renamed *WebFingerProfileLinks, check EVENTS.txt
in WebFinger plugin for new events.
I implemented changes from quitter.se's new API that their front-end qvitter
uses, https://github.com/hannesmannerheim/qvitter/blob/master/api-changes-1.1.1/CHANGES
However I left out the URL shortening commens, since I believe whatever behaviour
they experienced that caused them to implement this was a bug (or many) and should
be fixed in their proper areas and that shortening should not be entirely left
out in API calls.
