| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
other types of forums or weird custom channel permissions. If the channel is auto-accept and taggable, it's a public forum.
|
|
|
|
| |
yourself
|
|
|
|
| |
view. Still need a button or setting to enable "unsafe viewing". This has no effect anywhere but in the album views. They can still be viewed by flipping through the individual photos with 'prev' and 'next'. We probably need a comprehensive strategy for how to deal with n-s-f-w photos in albums so consider this a band-aid which requires additional work and integration with other facilities which access these photos. It is entirely optional.
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
| |
that a directory is returning something in find_upstream_directory()
since this was spotted by a new install who thought *they* were
broken.
|
|
|
|
| |
no results.
|
|
|
|
| |
Revert if there are serious issues, but please note the issues in as much detail as possible so we can work through them.
|
| |
|
| |
|
| |
|
|
|
|
| |
via the conversation structure that needs to be dealt with.
|
|
|
|
|
| |
a while tends to have a longer ping, we should probably have a longer
ping
|
|
|
|
| |
and stuff, move yet another oauth1 library to library instead of having it in plugins where we'll end up with a white screen if we re-use it in another plugin; which I plan to do.
|
|
|
|
| |
world (via siteinfo/json). Otherwise we'll use the default channel of any accounts that have the account admin role.
|
| |
|
| |
|
|
|
|
| |
easily mis-typed sequence '0000-00-00 00:00:00'
|
| |
|
|
|
|
| |
bug, moved service class stuff from plugin to account.php where it belongs and load that by default instead of on demand
|
|
|
|
| |
kill us with complex joins. We can phase out the sign table once this all checks out.
|
| |
|
|
|
|
| |
emulation (and many other uses)
|
| |
|
| |
|
| |
|
|
|
|
| |
notifier is setup to take hublocs, not xchans.
|
|
|
|
|
|
| |
function to do the same thing.
If you have a problem with chatroom expiration, check that it was created with cr_expire set to 120 (minutes). Chatrooms created during the first couple of days of the chat feature didn't have this. You can set the DB value manually.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
since the password is required to remove a channel. Somebody looking at an open session on somebody else's computer can simply change the password and then proceed to maliciously remove the channel. This change gives the owner 2 days to discover that something is wrong and recover his/her password and potentially save their channel from getting erased by the vandal. This is most likely to happen if a relationship has gone bad, or something incriminating was found in your private messages when you left your computer briefly unattended.
|
|
|
|
| |
to load
|
|
|
|
| |
bookmark permission), also remove the unused 'unconnected contacts' view for now.
|
| |
|
|
|
|
| |
(was cloned from elsewhere and is not primary)
|
|
|
|
| |
writeable areas of the server except the config file and logs under the "store" directory. We'll do logs at a future time.
|
|
|
|
| |
REGISTER_OPEN is in effect.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
extended likes
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|