| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
ConversationObject, hopefully this won't destabilise the network as it's a somewhat major permission tweak related to comments; also add any local clones to allowed_public_recips() as they should always be allowed recipients. Not sure what to do about host permissions in the event of clones. They have more than one host, and it isn't spelled out in the sent message.
All of this stuff will make your head hurt.
|
| |
|
|
|
|
| |
adult profile keywords. Eventually the directories will be forced to mark adult profiles and sync this knowledge between them. At the moment there's no way to do an unsafe search, but we really just need a checkbox and pass the value through directory to dirsearch on the back end, and some will want this as a pconfig.
|
| |
|
|
|
|
| |
to update table to store the target address since it's possible the mirroring directory won't yet have an xchan or hubloc they can link the ud_hash to and therefore mayn't know how to contact them.
|
|
|
|
| |
(directory sync) updates have been processed in some way.
|
| |
|
|
|
|
| |
https://abcentric.net/display/f17b319c6d4b616a0d0a639e177969c6ae084248f1ee2bec9d8147c9291bf495@abcentric.net
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
directory sync. Please do not mess with any of this.
Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this.
OK? Understood?
|
| |
|
| |
|
|
|
|
| |
conversation templates so that themes can use the module context to suppress or show comments as desired
|
|
|
|
| |
completely NOT work, so at least there's some improvement
|
| |
|
| |
|
|
|
|
| |
the site record was updated - without checking first to see if anything changed. This is causing lots of sync entries when nothing changed to warrant it.
|
|
|
|
| |
viewsrc to item_photo_menu, and log what changed in import_xchan update objects so we can find out why there are so many updates when nothing _obvious_ has changed that should trigger it.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
hubloc if anything at all changed anywhere.
|
|
|
|
| |
posts have recipients.
|
| |
|
| |
|
|
|
|
| |
before, but was still not quite right. We seem to be getting all the right results for top-level posts now, but comments aren't getting through on channels for which we've allowed them to send us their stream, but not comment on our posts. The reason is we were seeing if they could comment - and we only need to do that if we own the post. If they own the post, we only need to check if they can send us their stream.
|
|
|
|
| |
down has been solved.
|
|\
| |
| | |
to flag failed auth attempts in db table hubloc as hubloc_receive_error
|
| | |
|
| | |
|
|/
|
|
| |
very old bug that's been reported time and time again and nobody every bothered to debug or even report it somewhere where we could monitor it. It's buried somewhere in my stream, but basically is "things don't work right if you've got 'everybody in my address book' permissions" on "can send me their channel stream and posts". I think this is Michelle's problem and anybody else who has en empty matrix after making lots of connections.
|
| |
|
| |
|
| |
|
|
|
|
| |
item_store logfile | grep -v created
|
|
|
|
| |
wrong inside item_store(), !! this changes the return of item_store !!
|
|
|
|
|
|
| |
logger_data level) on failure
This should probably be at a lower log level, but unsuccessful connections could happen a lot on a busy production site so we'll try to keep the log noise down unless somebody really needs to track this info.
|
| |
|
|
|
|
| |
I'm making this up as I go and not exactly certain where to go next but it makes more sense now and I think the basic idea will actually work. I'll just have to keep making it up until it does work.
|
|
|
|
| |
connections get a fresh update.
|
|
|
|
| |
clone instances
|
|\
| |
| | |
only show categories this channel has used
|
| | |
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
//service class configure in .htconfig.php:
$a->config['system']['default_service_class']='standard'; // this is
the default service class that is attached to every new account
$a->config['service_class']['standard'] =
array('photo_upload_limit'=>20000000, // total photo storage limit per
channel (here 20MB)
'total_identities' =>5, // number of channels an account can create
'total_items' =>2000, // number of top level posts a channel can
create. Applies only to top level posts of the user, other posts and
comments are unaffected
'total_pages' =>10, // number of pages a channel can create
'total_channels' =>500, // number of channels the user can add, other
users can still add this channel, even if the limit is reached
'attach_upload_limit' =>20000000); // total attachment storage limit
per channel (here 20MB)
|