| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| | |
|
| |
| |
| |
| | |
This reverts commit b57010e3da6c0521121a622c27013c8af7678132.
|
| | |
|
|/ |
|
|
|
|
| |
The issue remains what to do about comments which are already in the DB and have ITEM_ORIGIN incorrectly set. We can't exactly reset them because the "original" context has been lost. (Sorry but couldn't resist an insider pun that none of you will be able to follow anyway). Read the comments.
|
|
|
|
| |
There are some fields in the actual stored item that may change when we start the second delivery chain so a few plugins may not deal with these items correctly. Since we only source public items these effects will be slight.
|
| |
|
| |
|
|
|
|
| |
nix extra var
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| | |
postgres could get real messy.
|
|/
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
deletions weren't propagating. Hopefully this is the last reason and there aren't more lurking further down the chain.
|
|
|
|
| |
fix for the problem of receiving a delete notification before we actually get the item which we're supposed to delete.
|
|\ |
|
| |\ |
|
| | | |
|
| |/ |
|
|/ |
|
|
|
|
| |
changes. Split these into seperate set and reset blocks.
|
|
|
|
| |
weekly doc updates
|
| |
|
| |
|
| |
|
|
|
|
| |
parent route we have. By definition we aren't going to have permission issues with these things.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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
|
|
|
|
| |
this - causes issue with check_upstream_directory
|
| |
|
| |
|
| |
|
|
|
|
| |
this would be wrong and cause even more subtle bugs. Reset to whatever value was passed in.
|
|
|
|
| |
channel is reached but then the loop iterated over another channel.
|
|
|
|
| |
is really going on
|
|
|
|
|
| |
- 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
|
|
|
|
| |
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).
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| | |
considerable] lag time before existing forums are correctly tagged).
|
| |
| |
| |
| | |
other types of forums or weird custom channel permissions. If the channel is auto-accept and taggable, it's a public forum.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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).
|
| | |
|