friendica
d5d6158973
ok heads up - potentially destabilising change. I've tried to sort out all the default connection permissions for those who don't have a predefined (or therefore have a "custom") permissions role. Unfortunately this includes most people that were using this software more than a month ago. The real changes are that the SELF address book entry no longer holds "auto-permissions" but instead holds your "default permissions" (if you have a pre-defined role, the defaults will be pulled from the role table).
...
The auto permissions have moved to a pconfig (uid.system.autoperms). A DB update will move these settings into their new homes.
What used to be the "Auto-permissions settings" page is now the "default permissions settings" page and a checkbox therein decides whether or not to apply the permissions automatically. A link to this page will only be shown when you have the "custom" role selected.
With luck nobody will notice anything wrong. But at least for the next few days, please review permissions that have been assigned to new connections (either automatically or manually) and make sure they make sense (e.g. they aren't "nothing"). You still need to take action when seeing a message "permissions have changed but not yet submitted" as we always let you review and perhaps adjust the settings _before_ a connection is established (unless you have autoperms turned on).
2014-11-04 17:11:02 -08:00
friendica
0e4f318b71
php warnings
2014-11-02 19:22:18 -08:00
friendica
285d6f61e4
I'm going to try again with the conversation request packets. I've looked this over and tested a lot of edge cases, and thought about from every angle I can think of to prevent looping. I don't *think* this can loop. I also doubt that this is the problem at friendicared.de, but I don't know for sure what that problem might be.
2014-11-02 15:28:20 -08:00
friendica
4274a2d06c
add some more safety checks before turning the conversation request messages back on
2014-11-02 00:06:52 -07:00
friendica
50c16c394f
check that we have valid data
2014-11-01 01:52:27 -07:00
friendica
a659ac8952
disable request message response until we work through this
2014-11-01 00:36:21 -07:00
friendica
1cb45c30e9
document request packets a bit more
2014-10-31 06:24:14 -07:00
friendica
5637d07138
flag notify packets that are sent in response to a message_id request and prevent them from recursing
2014-10-31 04:59:30 -07:00
friendica
28a35261db
What this checkin does is catch the case where a comment arrived and there's a missing top-level post to match it with. So we'll send a request back to the sender that you've never seen this thread and please send a fresh copy of the entire conversation to date. We could soon have posts in the matrix from different platforms from days gone by, which have been migrated into the modern world. We'll be polite and not deliver these to everybody. However, if someone comments on one of these antique threads we wouldn't be able to see it in our own matrix because we won't have a copy of the parent post. So this rectifies that situation. Be aware that item deletion may need to change to keep "hard deleted" items indefinitely so that they don't keep coming back. We'll have to null out the important data of the former item to accomplish the deletion aspect.
2014-10-30 19:15:03 -07:00
friendica
fd492386bf
Tried this once before but had to revert. Basically prevent a comment from being relayed more than once - as it's a huge drain on resources. But last time I tried this, wall-to-wall comments stopped getting relayed. This checkin should do the right thing in both conditions.
2014-10-19 17:31:10 -07:00
friendica
903f7e73fb
if a hubloc primary change results in an xchan primary change, create a directory update packet.
2014-10-13 21:44:46 -07:00
friendica
0057612a9f
figuring out how to bootstrap the change_primary procedure when all you have is inconsistent data which you think you trust.
2014-10-13 21:38:36 -07:00
friendica
19e1b95837
don't use cached data
2014-10-13 21:01:51 -07:00
friendica
bd4dd85fbb
there's the problem
2014-10-13 20:53:34 -07:00
friendica
1b0390af06
new function hubloc_change_primary()
2014-10-13 15:27:56 -07:00
friendica
718bea5d45
cleanup of sync_locations and better logging. There was one significant code change but it is unrelated to current issues, basically if no primary was set we were setting everything as primary.
2014-10-12 15:18:49 -07:00
friendica
f26cd5a636
ah yes, the redundant relay run was for the benefit of wall-to-wall posts issue #633
2014-10-10 15:17:32 -07:00
friendica
b5f91d7b40
missing source route after edit
2014-10-10 14:45:18 -07:00
friendica
cde244ef74
improvement in source route checking when handling complex *upstream* delivery chains, which were not adequately accounted for in the earlier checkin.
2014-10-10 00:13:46 -07:00
friendica
4634049549
allow (our own) ajax urls to pass through bbcode intact.
2014-10-09 20:59:33 -07:00
friendica
effc8960c3
OK this is important. So read it carefully.
...
This checkin implements route matching of comments so that they are only accepted from the same route as the top-level post they are attached to. This way there should be no mis-match of permissions between any posts in the thread. It may not be completely compatible with comments posted in the past (though I've tried to be, there may be some minor issues). In addition it seems that relaying was invoked more often than necessary - especially when a duplicate post arrived which was not processed because the edited time hadn't changed - it still invoked relaying. This fix should improve site performance considerably for comments cross-posted to forums; which got bounced around a bit and delivered redundantly for no reason.
Roll this back *only* if it causes a meltdown or comment loss is "serious" (as in OMG people are dying, make it stop!). If we can get past 24 hours without serious issue we need to get everybody onto this code. There may be some minor comment loss (mostly affecting new comments to older posts or likes of older comments) until the majority of sites have moved to the new code.
It may be difficult or impossible to deliver comments to posts that pre-date the addition of source routes (April 1, 2014) to anybody but the top-level post author at his/her primary hub. We may wish to close comments on these posts, but let's see how we go before doing that.
2014-10-09 18:12:53 -07:00
friendica
467c6c72f0
ability to pre-populate connections for new channels. e.g. "MySpace Tom"
2014-10-01 14:48:08 -07:00
friendica
b735961560
found the sucker
2014-09-22 16:23:59 -07:00
friendica
c4608d4c82
just mark dead hubloc deleted - don't remove them. This could cause problems. Also clean up fetch_url/post_url header option
2014-09-16 19:07:19 -07:00
friendica
bbc9e4427e
honour service class restrictions for total_identities, total_channels ("friends") and total_feeds both when importing channels and subsequently when syncing clones. Limits are based on the local system - additional entries are silently dropped.
2014-09-15 17:17:00 -07:00
friendica
0dc33900b6
provide a way to sync locations and get rid of bogus hublocs, now implemented
2014-09-14 22:19:19 -07:00
friendica
bcc9057d8c
pull the plug on the old location sync section of import_xchan - this has now been split off into its own function. Cross fingers because this is core functionality which was tried and true, well tested; and now it's a bit different.
...
Please revert this if the matrix breaks in the next few hours.
2014-09-14 18:09:16 -07:00
friendica
c27b60d981
more heavy lifting on the hubloc management and revocation infrastructure; don't rush me. This is going to become a fundamental part of zot. It deserves careful consideration.
2014-09-14 01:48:54 -07:00
friendica
0350b76d85
some backend work for the remaining missing bits of mod_hubman - this is still a fair ways from being complete and is not ready for prime time. Basically we'll let a channel send out a public message saying "these are my currently approved locations" and anything that isn't in the list will be marked deleted. We'll send out this message when locations change somehow - either through direct personal involvement (hub revoke, change primary, channel import) or during a system rename or "find bad/obsolete hublocs" activity. This way we won't have clones sending back location info we just got rid of and re-importing the bad entries.
2014-09-13 16:00:09 -07:00
friendica
e68185fc05
don't allow an xchan to be imported with an empty name. To avoid translation issues we'll just make it '-'.
2014-09-11 18:11:07 -07:00
friendica
c6d07feff5
This is long overdue - use a symblic constant NULL_DATE instead of the easily mis-typed sequence '0000-00-00 00:00:00'
2014-09-08 20:35:15 -07:00
friendica
1102499c71
realm detection logic reversed
2014-09-04 16:09:52 -07:00
friendica
2d0ad0625a
sql error in profile_activity
2014-08-31 16:24:05 -07:00
friendica
8a62b824f9
lots of little Diaspora issues
2014-08-28 21:49:13 -07:00
friendica
6a42d6fe3b
works one way sort of - now to go the other way - which will require fixing a whole slew of FIXMEs
2014-08-26 18:58:48 -07:00
friendica
eb8f194419
sort out some anomalies
2014-08-25 21:42:46 -07:00
friendica
9196c9eef0
We really can't do this without a hubloc. I was hoping we could, but notifier is setup to take hublocs, not xchans.
2014-08-22 21:37:08 -07:00
friendica
69d3e5468d
provide the site blacklist everywhere it is needed
2014-08-21 21:07:32 -07:00
friendica
4a76925787
some more work on realms
2014-08-17 19:06:56 -07:00
friendica
82eb265a20
add collections widget to connections page - and some more work on realms
2014-08-17 17:48:41 -07:00
friendica
20bdcb037f
provide backend storage and declaration of directory realm
2014-08-16 16:10:35 -07:00
zottel
d57fe0765c
don't block "public" messages with authenticated scope
2014-08-15 21:36:24 +02:00
friendica
802a5c2946
zot logging to figure out why we occasionally don't have an address on xchan_import - I suspect we don't have anything useful at all.
2014-08-12 20:46:33 -07:00
friendica
ad1472abf0
got the logic reversed on that one
2014-08-07 18:58:33 -07:00
friendica
f412f6a654
over-ride the private flag if we received a post that isn't completely public, but they didn't set the private flag.
2014-08-07 17:49:57 -07:00
friendica
2cff122d6f
public scope delivery issues
2014-08-06 21:16:24 -07:00
friendica
8da548344b
clone sync of "unfriend" actions
2014-08-05 17:47:17 -07:00
friendica
5a5190f2ff
add an encoding type to formatted zot communication structures so that we can later add alternate encodings.
2014-07-24 15:55:01 -07:00
friendica
9e988afa1f
ensure that we don't have permission settings issues due to version skew across sites.
2014-07-17 20:59:58 -07:00
friendica
437b0cb16e
collection sync issue
2014-07-17 15:53:07 -07:00