aboutsummaryrefslogtreecommitdiffstats
path: root/include/zot.php
Commit message (Collapse)AuthorAgeFilesLines
...
| | * force site_url to be lowercase when stored. Otherwise rating hubs on ↵friendica2015-02-151-1/+1
| | | | | | | | | | | | postgres could get real messy.
| * | normalize age dataHabeas Codice2015-02-161-2/+7
| |/ | | | | | | | | | | | | | | mysql has type tinyint(3) which probably turns into a 24-bit value, but postgres uses 3-digit decimal as its constraint (probably what the mysql schema was intended to do). either that or mysql silently truncates while postgres respects the constraint. Either way, bad data gets in unchecked, now it's checked.
| * missing paramfriendica2015-02-131-1/+1
| |
| * well that was certainly fun. And the reason why likes and other acitivity ↵friendica2015-02-111-3/+4
| | | | | | | | deletions weren't propagating. Hopefully this is the last reason and there aren't more lurking further down the chain.
| * more efficient processing of response activities, plus a proof of concept ↵friendica2015-02-111-17/+44
| | | | | | | | fix for the problem of receiving a delete notification before we actually get the item which we're supposed to delete.
* | Merge branch 'master' into tresfriendica2015-02-051-11/+35
|\| | | | | | | | | | | Conflicts: view/css/mod_events.css view/theme/redbasic/css/style.css
| * Merge branch 'master' of https://github.com/friendica/redHabeas Codice2015-02-051-10/+34
| |\
| | * Merge branch 'master' into pocoratefriendica2015-02-031-0/+5
| | |\
| | | * garbage in garbage outfriendica2015-02-031-0/+5
| | | |
| | * | send rating information to directoriesfriendica2015-02-021-10/+29
| | |/
| * / escape datesHabeas Codice2015-02-051-1/+1
| |/
* | Merge branch 'master' into tresfriendica2015-01-311-9/+34
|\| | | | | | | | | Conflicts: include/zot.php
| * sync_locations() toggle DB flag functions were broken - result of postgres ↵friendica2015-01-301-4/+22
| | | | | | | | changes. Split these into seperate set and reset blocks.
| * let zot_refresh continue without a primary hub if one cannot be found. also ↵friendica2015-01-301-5/+14
| | | | | | | | weekly doc updates
* | Merge branch 'master' into tresfriendica2015-01-291-3/+6
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: include/group.php include/text.php mod/acl.php mod/channel.php mod/connections.php mod/display.php mod/group.php mod/item.php mod/locs.php mod/network.php mod/photos.php mod/ping.php mod/starred.php mod/viewsrc.php
| * local_user => local_channelfriendica2015-01-281-1/+1
| |
| * add yet another firehose checkfriendica2015-01-281-1/+1
| |
| * more minor tweaks to the route mismatch algorithm after watching it all day.friendica2015-01-281-2/+5
| |
* | more message restrict conversionsfriendica2015-01-291-5/+5
| |
* | Merge branch 'master' into tresfriendica2015-01-271-5/+68
|\| | | | | | | | | Conflicts: include/socgraph.php
| * ignore route mismatches on firehose posts to the sys channel. Use whatever ↵friendica2015-01-271-1/+1
| | | | | | | | parent route we have. By definition we aren't going to have permission issues with these things.
| * we need to actually ask for the id from the DB if we want to use it.friendica2015-01-271-1/+1
| |
| * improved route mismatch detection. We will be less strict about the absolute ↵friendica2015-01-271-2/+22
| | | | | | | | route matching and only look at the last hop before it got to us - which is ultimately all we should care about (since that sender controls the thread permissions). Route mismatches seem to occur somewhat frequently from yamkote (for unknown reasons), and the logging has been improved a bit so it should provide some slightly more useful debugging info in case it still happens going forward. Oh, also we'll set the parent on comments when we store the initial post (item_store()) and only go back and set the parent for top-level posts. This should reduce the number of comments with missing parents on shared hosts, but may increase the number of missing threads. Probably worthwhile to do a query occasionally for parent = 0 and see how we're doing and how many have shared host related delivery issues.
| * handle an incoming directory rating messagefriendica2015-01-261-2/+45
| |
* | sql typofriendica2015-01-271-1/+1
| |
* | Merge branch 'master' into tres and add some work on the item_deleted flag ↵friendica2015-01-261-1/+1
|\| | | | | | | | | | | | | | | | | | | refactor Conflicts: include/attach.php include/onedirsync.php include/zot.php mod/locs.php
| * remove superfluous group byHabeas Codice2015-01-241-1/+1
| | | | | | | | | | this gets called from a zot post_post dealing with a specific messageid and hubloc_hash combination. grouping by site doesn't make sense here and it gets grouped when pulled back out elsewhere anyway
| * zot_finger second arg is optional but function declaration didn't specify ↵friendica2015-01-211-1/+1
| | | | | | | | this - causes issue with check_upstream_directory
* | heavy lifting converting item flag bitsfriendica2015-01-221-5/+2
| |
* | slow progress removing bitfields on item tablefriendica2015-01-211-1/+1
| |
* | working through the xchan table to remove bitfields, mostly complete except ↵friendica2015-01-201-44/+26
| | | | | | | | for updating the updater
* | that should take care of the bitfields in hublocfriendica2015-01-201-35/+27
| |
* | first cut at unpacking bitfields in hubloc, fixed hubloc_error and ↵friendica2015-01-201-19/+13
|/ | | | hubloc_deleted
* connection clone issuesfriendica2015-01-101-0/+3
|
* don't update locally deleted itemsfriendica2015-01-061-3/+8
|
* don't import to sys channel from self-censored authorsfriendica2014-12-121-1/+11
|
* can't reset public to false because it may have been passed in as true and ↵friendica2014-12-011-5/+5
| | | | this would be wrong and cause even more subtle bugs. Reset to whatever value was passed in.
* Somewhat subtle process_delivery() bug - $public was not being reset if a sysThomas Willingham2014-12-011-0/+1
| | | | channel is reached but then the loop iterated over another channel.
* change logging of some troublesome or noisy bits so we can figure out what ↵friendica2014-11-191-2/+2
| | | | is really going on
* couple of fixes:friendica2014-11-191-0/+5
| | | | | - significantly increase the content availability on the discover channel - fix the button group on the blog/list mode which made the border on a single comment button a bit wonky
* there's still a permission issue delivering a public post directly to the ↵friendica2014-11-191-0/+2
| | | | sys channel (on the local system), but this puts the local sys channel in the public delivery chain and fixes an issue with unseen counts showing on the discover page (where you can't do anything about it).
* add sys channel to public recips if scope publicfriendica2014-11-181-0/+12
|
* put timeout code in place but don't turn it on.friendica2014-11-131-6/+7
|
* Merge remote-tracking branch 'upstream/master'Habeas Codice2014-11-131-46/+97
|\ | | | | | | | | | | | | | | | | | | | | | | Conflicts: boot.php include/dba/dba_driver.php include/diaspora.php include/follow.php include/session.php include/zot.php mod/photos.php mod/ping.php
| * indicate public forums in directory results (there will be some [possibly ↵friendica2014-11-101-4/+5
| | | | | | | | considerable] lag time before existing forums are correctly tagged).
| * add public forum identification to libzot. No attempt is made to identify ↵friendica2014-11-101-2/+6
| | | | | | | | other types of forums or weird custom channel permissions. If the channel is auto-accept and taggable, it's a public forum.
| * don't overwrite $x (contains import_xchan result) with role permissionszottel2014-11-061-3/+3
| |
| * ok heads up - potentially destabilising change. I've tried to sort out all ↵friendica2014-11-041-9/+9
| | | | | | | | | | | | | | | | | | | | 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).
| * php warningsfriendica2014-11-021-23/+23
| |
| * I'm going to try again with the conversation request packets. I've looked ↵friendica2014-11-021-11/+55
| | | | | | | | 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.