| Age | Commit message (Collapse) | Author |
|---|
|
AtomGroupNoticeFeed, consolidating some code. (RSS feeds pulling title, logo etc from the Atom data structure so we don't dupe it.)
OStatus now calling the feed classes directly instead of faking a call into the API, should be less flakey.
|
|
administrator and moderator options.
Buttons need to be themed.
|
|
|
|
|
|
|
|
- switch 'en_US' to 'en', fixes the "admin panel switches to Arabic" bug
- tweak setting descriptions to clarify that most of the time we'll be using browser language
- add a backend switch to disable language detection (should this be exposed to ui?)
|
|
profiles. We can't initiate remote sub for an OMB from our end, so dropping there.
|
|
group and a local group exist with the same name. (If you're a member of two groups with the same name though, there's not a defined winner.)
|
|
* 'testing' of gitorious.org:statusnet/mainline:
Using position relative only for the remote subscription in section
Added group subscription button to groups mini list
Added event hooks at the start and end of groups mini list
|
|
All 'connect' menu panels used to be optional, so Action tried to
figure out what the first item on the 'connect' menu should be.
This is no longer necessary because we have the non-optional OAuth
client connections panel now, which is not optional and can't be
turned off.
|
|
|
|
|
|
Also stripping id from foreign HTML messages (could interfere with UI) and disabled failing attachment popup for a.attachment links that don't have a proper id, so you can click through instead of getting an error.
Issues:
* any other links aren't marked and saved
* inconsistent behavior between local and remote attachments (local displays in lightbox, remote doesn't)
* if the enclosure'd object isn't referenced in the content, you won't be offered a link to it in our UI
|
|
|
|
"getEnclosure"
|
|
|
|
|
|
|
|
When it sneaks in it can cause some very slow queries due to mismatches with the indexing.
Twitter removed 'since' support some time ago, and we've already removed it from the public timeline, so it shouldn't be missed.
|
|
mentioned in the replied message.
|
|
This reverts commit c25fc8a4b51466f13c41efc0565bf15f78f6cb4d.
|
|
|
|
|
|
We only need one author for user feeds: the user themselves. So, show
the user as the activity:subject, and don't repeat the same
activity:actor for every notice unnecessarily.
|
|
|
|
|
|
* 'testing' of gitorious.org:statusnet/mainline: (25 commits)
Fix a bunch of notice & warning-level messages that were breaking my inter-instance communications
more output in updateostatus.php
lost important fields when switching queries
show service debug info
pass listener URI into consumer for OMB
remove strict check on OMB exception strings
return correct HTTP status code for OMB errors
send smaller error pages for OMB API endpoints
Remove check for secret in token deletion on Subscription::cancel()
Better logging on bad token in subscription
Return empty array when no subscriptions to remote
drop tokens for OMB on unsubscribe
fix path for updateostatus.php
Script to convert OMB subscriptions to OStatus subscriptions
show service debug info
pass listener URI into consumer for OMB
remove strict check on OMB exception strings
return correct HTTP status code for OMB errors
send smaller error pages for OMB API endpoints
Remove check for secret in token deletion on Subscription::cancel()
...
|
|
This reverts commit 19ec0e3a62d4c60d7e5581b4e38ec705650b1d18.
|
|
|
|
|
|
|
|
|
|
|
|
In a federated system, "@nickname" is insufficient to uniquely
identify a user. However, it's a very convenient idiom. We need to
guess from context who 'nickname' refers to.
Previously, we were using the sender's profile (or what we knew about
them) as the only context. So, we assumed that they'd be mentioning to
someone they followed, or someone who followed them, or someone on
their own server.
Now, we include the notice information for context. We check to see if
the notice is a reply to another notice, and if the author of the
original notice has the nickname 'nickname', then the mention is
probably for them. Alternately, if the original notice mentions someone
with nickname 'nickname', then this notice is probably referring to
_them_.
Doing this kind of context sleuthing means we have to render the
content very late in the notice-saving process.
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
EVENTS.txt
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
