On big databases these queries from the Nodeinfo plugin choked up:
SELECT profile_id FROM notice
WHERE notice.created >= (CURRENT_DATE - INTERVAL '180' DAY)
AND notice.is_local = 1;
SELECT id FROM "user"
WHERE "user".created >= (CURRENT_DATE - INTERVAL '180' DAY);
The code used to operate under the assumption that MariaDB doesn't support
quoting identifiers. Not only is that not exactly true, but MariaDB has
reserved keywords that cannot be used as table or column names unquoted.
Fixed an error where a profile id was reused after another profile was
deleted, and the new profile still had the deleted role.
Fixed ActivityGenerationTests::testNoticeInfoRepeated() which was passing
User instead of Profile, throwing errors.
tests/ActivityGenerationTests.php now passes.
CommandInterpreterTest now passes.
Moved JidValidateTest to XmppValidateTest, since Jabber functionality has
moved to the XmppPlugin. Tests work but don't pass, but they are at least
skipped if XmppPlugin is not active.
LocationTest passes, but the tests are not very good. Lots of nulls.
MediaFileTest passes.
NicknameTest passes. Nickname::normalize() now throws an error if the
nickname is too long with underscores.
UserFeedParseTest passes.
URLDetectionTest passes if $config['linkify']['(bare_ipv4|bare_ipv6|
bare_domains)'] are false. Untested otherwise.
Fixed Nickname::isBlacklisted() so it does not throw an error if
$config['nickname]['blacklist'] not set.
We don't guess the current profile anymore if the value of the profile === -1
Also sets $this->scoped for all ScopingNoticeStream inheritors, which just
like in an Action can be null if we're not scoped in any way (logged in).
Also made some changes in the password "munging" function call
common_munge_password to accept a profile instead of user ID (which
was only there because stoneage StatusNet used the ID to generate a
not-very-random salt, but nowadays we primarily use AuthCrypt plugin).
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).
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.
Conversation trees works pretty bad with the current layout, javascript
etc. So it's best if we separate it and work on it as a side-project. The
oldschool settings are currently being deprecated (or broken out like this).
I'll wait with removing User preferences for oldschool conversation tree,
since that might be reusable data. But I guess it will go in the near future.
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.
