aboutsummaryrefslogtreecommitdiffstats
path: root/include/zot.php
Commit message (Collapse)AuthorAgeFilesLines
* ensure that we don't have permission settings issues due to version skew ↵friendica2014-07-171-1/+1
| | | | across sites.
* collection sync issuefriendica2014-07-171-0/+25
|
* collection syncfriendica2014-07-161-0/+114
|
* limit fields to what we requirefriendica2014-07-141-1/+1
|
* index collection sync info by hash rather than idfriendica2014-07-141-1/+1
|
* clean up more code duplicationfriendica2014-07-141-6/+20
|
* the sending side of clone syncing of collection/privacy_group information. ↵friendica2014-07-141-1/+15
| | | | The receiving side is not yet implemented.
* much better fix to problem yesterday of updates with the wrong ud_addr ↵friendica2014-06-301-23/+16
| | | | | | getting updated. Now we'll pass in the update table row to import_xchan so we know exactly which ud_addr applies. We still need ud_flags passed in separately.
* control chars crept in.friendica2014-06-301-1/+1
|
* ensure we have a unique guid for each address if one is generated.friendica2014-06-301-1/+1
|
* update the update records for all addresses attached to this channel, not ↵friendica2014-06-301-7/+19
| | | | just the primary.
* Implements a new permission level PERMS_PENDINGAlexandre Hannud Abdo2014-06-191-11/+15
| | | | | | | | | | | | | | | | With this a user can allow some action to any user which connects to them, even before they've connected back. Ref. https://mobiliza.org.br/display/478d9e71eaf55748dc646d3990651d6d34cfb7db5c38360538ec730ca3ccf908@zothub.com Also some code cleanup and an alternative logic for handling notifications of permission changes in zot.php. This assumes that private posts are still restricted to people in your addressbook. Regardless of your global permissions, a pending channel won't get private posts, even if the post only has a deny clause not matching the pending channel.
* note work still remainingfriendica2014-06-171-0/+1
|
* sync profiles to nomadic clonesfriendica2014-06-171-0/+39
|
* send new connection notification even if auto-perms are setfriendica2014-06-121-1/+1
|
* duplicate birthday events showing upfriendica2014-06-041-0/+7
|
* bring back birthdaysfriendica2014-06-021-2/+11
|
* Merge branch 'master' into neweventfriendica2014-05-291-1/+21
|\ | | | | | | | | Conflicts: include/zot.php
| * cleanup dead directory entries. This was a real b#tch, so keep your eye out ↵friendica2014-05-281-0/+18
| | | | | | | | for issues - which you shouldn't see until next weekend when this is scheduled to run. We're only setting flags, so if anything goes wrong we should be able to recover without too much pain.
| * add activity_received hookfriendica2014-05-131-0/+3
| |
| * fix events until the new event subscription mechanism goes in, as shared ↵friendica2014-05-071-1/+1
| | | | | | | | events have been broken
* | better event managementfriendica2014-05-071-30/+0
|/
* ok *now* shred works with alternate config filesfriendica2014-05-071-0/+4
|
* Often somebody will join the matrix with a dodgy cert and we'll sort that ↵friendica2014-04-131-11/+25
| | | | out but their profile photo will remain rainbow man (or the site default). However the photo_date has been updated so we won't try again. This checkin looks for such a failure and leaves the photo_date alone if the photo import failed.
* add the message-id to delivery reports. This _could_ allow an enterprising ↵friendica2014-04-101-14/+14
| | | | developer to collect the delivery reports for a given post and store them in a DB table so that the sender could track and verify where a message had been sent on a web page and verify the success or failure of those attempts without requiring admin access. (To be fair this would also need an extra flag which hasn't yet been implemented to indicate that a channel created a second delivery chain of the message).
* Include the entire original item when notifying other channels of deletions ↵friendica2014-04-101-1/+1
| | | | as it contains important routing and scope information. Previously we were only sending a couple of critical fields like the message-id, flags, and creation date. The thinking was that it is deleted, let's not resend the deleted contents anywhere. But in order to route this through the same path the original post took we really need the entire original post with all of its baggage attached.
* this should be better - "xchan deleted" state on remote sites only follows ↵friendica2014-04-071-9/+6
| | | | the xchan_flags and not the channel_pageflags; XCHAN_FLAGS_DELETED should only be set if the channel is to be removed from the entire network. As mentioned in a previous commit, channel_pageflags could be set to PAGE_REMOVED but still leave living clones on other sites.
* undo one of yesterday's changes - if a channel was deleted we want to mark ↵friendica2014-04-071-6/+6
| | | | the hubloc deleted - but not the xchan. The channel might be alive at another hubloc. We should only mark the xchan deleted when removing a channel from the entire network - e.g. there are no hubs left to service it.
* prevent follows of and notifications to deceased channelsfriendica2014-04-071-0/+9
|
* source routing stufffriendica2014-03-291-0/+3
|
* try and sort out the item delete messfriendica2014-03-271-3/+3
|
* new connection notificationfriendica2014-03-271-0/+9
|
* more work on firehosefriendica2014-03-261-5/+7
|
* this should improve queue performance dramatically.friendica2014-03-241-1/+2
|
* create_sys_channel during setup bypasses our check when creating the first ↵friendica2014-03-231-0/+2
| | | | account that there is a site keypair. Esnure that a site keypair is created before any sys channels are created.
* found what I believe is the root cause of issue #230, but don't yet have a ↵friendica2014-03-201-13/+21
| | | | workable solution. This one is hard.
* increase log info to track down source of ownership failuresfriendica2014-03-201-1/+1
|
* cleanupfriendica2014-03-181-12/+19
|
* bring friends backfriendica2014-03-061-10/+10
|
* change flags for one-way connections from hidden to unconnected so we can ↵friendica2014-03-041-5/+10
| | | | still use hidden for - well hiding connections
* directory sync issuesfriendica2014-03-031-8/+8
|
* some anomolies found when viewing connections in various cases.friendica2014-03-021-0/+21
|
* minor stuff, some doco, auth cleanup, and make "unknown" more translateable ↵friendica2014-02-221-4/+0
| | | | by context.
* fix login weirdness for accounts that need to be approvedfriendica2014-02-201-5/+0
|
* believe i found the issue which was causing hundreds/thousands of identical ↵friendica2014-02-201-9/+12
| | | | hublocs to be created
* several things were not working correctly w/r/t community tagging. The ↵friendica2014-02-161-5/+7
| | | | preference vanished from settings at some point, and we also weren't updating the original post timestamp so that the changed taxonomy would propagate correctly as an edit.
* implement a forced directory update mode where we unconditionally create a ↵friendica2014-02-111-6/+9
| | | | directory sync packet. This is needed to ensure that monthly directory pings are propagated to other directory servers so they can each prove for themselves whether or not an account is alive or dead. We do not trust other directories to provide us information beyond "look at this entry and decide for yourself" as doing otherwise would invite rogue directory manipulations. As this scheduled update occurs on all channels across all servers, we should also pick up refresh messages from all existing channel clones and these should also propagate out to all directory servers using the same mechanism (though perhaps not at the same time).
* reversed args in update_modtime, incorrect ud_guid and ud_hashfriendica2014-02-101-1/+1
|
* Check for the correct DB name before pushing.friendica2014-02-101-1/+1
|
* add channel_notify_flags to list of things which should *not* be synced ↵friendica2014-02-101-1/+1
| | | | across nomads. You probably only want one site to send you notification emails for the same events as opposed to all of them.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-11 01:22:56 +0000