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!
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.
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.
