will verify unknown aliases against old ones if the new identifies as a
previously recognized URI.
Steps:
1. Check the newly received URI. Who does it say it is?
2. Compare these alleged identities to our local database.
3. If we found any locally stored identities, ask it about its aliases.
4. Do any of the aliases from our known identity match the recently introduced one?
Currently we do _not_ update the ostatus_profile table with the new URI.
Use profile URL (not URI), like elsewhere.
Profile::getUri() doesn't actually do anything useful, here--
it does nothing unless a plugin (like OStatus) is already
able to resolve the Profile into a backend object (e.g.: an Ostatus_profile).
If we might not already have an Ostatus_profile for a given Profile,
then we need to use $profile->getUrl() and fetch the data from that URL.
If we know the URI sent from the remote party, and we don't know the
notice it is replying to, we might still be able to put it in the same
conversation thread!
So that we can actually find commandline.inc.
This should have been updated when the files in the EmailSummary tree
where moved down a level into subdirectories.
At the same time we change this to call ActivityUtils::checkAuthorship
instead to let the retrieval/verification go through event handling.
rozzin (Joshua Judson Rosen) found this error. Thanks.
We need to look up a feed profile for HandleFeedEntryWithProfile events,
regardless of whether they're an OStatus user, group, or something else;
this is the least hairy way of doing that--the alternative being
to keep spreading the same logic all over the calling code.
Theoretically, this change might allow OStatusGroups to be recorded
as the authors of activities if they pass through any authorless
activities; but that's why we have checkAuthorship().
Similarly to what ActivityUtils::checkAuthorship does; try to ensure
that activities from ambiguous OStatus feeds (groups and peopletags)
that require explicit authorship don't get in without explicit authors.
InboxNoticeStream::getNotices() no longer returns an ArrayWrapper;
just fetch notices normally via $notice->fetch(), so that
we can actually get the top notice-ID and update email_summary_status
accordingly--and not mail about the same notices repeatedly.
The last commit found a bug that a previous move of the FavCommand
into a plugin called $this in FavoritePlugin instead of the instance
of a CommandInterpreter class. Now that call is statically defined in
CommandInterpreter and appropriately called in FavoritePlugin.
In the future, use events for formatting microapp notices, more specifically
through the plugin's function "showNoticeContent" or similar, which is called
from MicroAppPlugin, which is extended from ActivityHandlerPlugin.
---------------------------------------------------------
WARNING: Some plugins attempt to get a property 'group' from (basicly) a Menu
class which does NOT have such property. This badly needs fixing.
---------------------------------------------------------
Signed-off-by: Roland Haeder <roland@mxchange.org>
There is required to be an answer-action element for the threaded view
so we can fetch that action value to an AJAX call which fetches the form.
That is: Currently the "Your answer..." placeholder will fetch a blank URL.
Got this mainly from my patches to FreeSocial. The idea is to migrate
also the Note activity to a plugin and have everything be handled as
events, only filling out the basic "context" stuff in the Notice class.
Getting rid of NoticeListItemAdapter, putting more into ActivityHandlerPlugin
and relying on plugins to handle rendering code of the content. This gives us
a lot more structure and consistency in notice structure and allows activity
plugins to stop rendering certain kinds of notices more easily.
There should also be a property for an ActivityHandlerPlugin class to avoid
rendering notices in the ordinary stream, so we don't have to overload stuff.
Lost dependency of OStatus plugin for lib/microappplugin.php, whoo!
also noting which plugins should be upgraded to new saveActivity support.
Favorite plugin won't work with the new system just yet, it doesn't have
the necessary functions to extract activity objects, but that's coming
in the next (few) commits.
saveActivity will accept an Activity which gets parsed and saved through
plugins. So when an ActivityHandlerPlugin (such as Favorite will be soon)
gets a feed to save, this will be the function called instead of saveNew.
The code is now more event-driven when it comes to rendering notices
and their related HTML elements, since we can't have direct calls from
core to a plugin.
lib/activitymover.php has a function to move a Favorite activity which
will not happen now. The move must be pluginified and performed as an
event which plugins can catch on to.
Now we have to fix any code in the core which directly uses the Fave class
or any other favorite stuff, since it is pluginised and thus might not be
available on some installations.
It's less of a problem that one queue-item does not get handled, attention wise,
than that the queue keeps filling up. The typical error raised here is 'already exists'
so it's not even the case that the item won't get handled (it already has been).
The real problem is that the queue_item table accepts duplicates (content-wise) which it
should not.
No validation has been attempted yet. Lots of changes left. This
is visibly not (very) different from the previous CSS layout. But
some simplifications have been made.
Might cause issues with local changes to themes and CSS. Also maybe
javascript which depends on certain legacy microformats elements.
The move to microformats2 is motivated by the announcement that all
microformats should be migrated to version 2, as of 2014-06-20 at:
http://microformats.org/2014/06/20/microformats-org-turns-9-upgrade-to-microformats2
This also fixes a problem with "initial salmon slap", which was a
problem for newly registered accounts which would have their first
salmon slap fail to distribute since there was a problem with Magicsig
keys. Apparently we have to re-read them with importKeys so the
Crypt_RSA objects publicKey and privateKey match later instances of them.
I think it may have been that generate() doesn't specify a signatureMode,
but I leave experimentation of that to the future.
