| Commit message (Collapse) | Author | Age | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Looks like the mercury topics were deprecated and instead we get these:
* deltaThreadName
* deltaParticipantsAddedToGroupThread
* deltaParticipantLeftGroupThread
Also slightly modified the handlers on the bitlbee side to add users
directly without requiring a thread fetch, and to show a kick message
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has a number of benefits:
- Most of the time the contact sync reply will be empty
- We can do contact sync more frequently (It's 5 mins now, was 30)
- Figuring out what contacts were added or removed is much simpler and
less likely to get things wrong.
- Non-friends are no longer accidentally removed because there's no need
to compare contact lists
- On accounts with lots of friends this gets rid of one source of CPU
usage spikes
- Less load for facebook's servers (lol)
|
| | |
|
| |
|
|
|
|
| |
This replaces a subset of "Failed to parse thread information" (the ones
that aren't really a problem parsing) with "You have been removed from
this chat" appearing in the relevant chat window.
|
| | |
|
| |
|
|
| |
See bitlbee/bitlbee@d28fe1c.
|
| |
|
|
|
|
|
|
|
| |
I'm still not sure about the origin of these errors (I suspect it's a
race condition between servers), but it's going to be fixed properly in
the future when the sync protocol is updated and doing HTTP requests to
get the attachment URL is no longer required (newer orca versions only
do HTTP requests to get the url of file attachments, everything else is
included in the MQTT stream)
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
The set `mark_read` now accepts `available` in addition to `true` and
`false`. When `mark_read` is set to `available` it will only mark
messages read when the user is not marked as away/invisible.
The set `mark_read_reply` was added, when this is set to `true` any
unread messages will be marked as read when the user replies them
(assuming they where received by bitlbee).
|
| |
|
|
|
| |
This is mainly for sanity and consistency as the bee_user should be
zeroed.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This adds more functionality to the `group_chat_open` set, which would
only allow added group chats to be opened automatically. With this new
set value of 'all', any group chat will be automatically opened with an
incoming message.
Value overview:
- false: never open group chats automatically
- true: open added group chats automatically
- all: always open group chats automatically
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Control channels never have a room setting, so joining to &facebook and
trying to fbjoin a channel would result in a null pointer dereference in
the next line (FB_ID_TO_STR)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This feature is not yet in any stable bitlbee release, but it's designed
to be backwards compatible:
- Run time: Detects if the "self_messages" global setting exists.
- Build time: sets OPT_SELFMESSAGE to 0 if it doesn't exist.
In other words, if this is built against a bitlbee version that supports
this feature, it will still run in anything 3.4+, and only display these
messages in the newer ones.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This adds a setting, group_chat_open, which if set to true, will allow
the plugin to open added channels upon an incoming message.
This also addresses:
- Improper message printing for root commands
- The fbchats command not joining existing channels
|
| |
|
|
|
|
|
| |
Currently, as soon as a user is invited to a group chat, they are added
to the group chat. In order to ensure the user is actually added, the
plugin should wait for an already handled group chat event for the user
being added.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Simpler and more verbose version of my other patch which silently
created a new queue - this will show up as a reconnection and should
make it obvious if an infinite loop happens. jgeboski's idea, not mine.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
As of now, group chat channels do not persist after they are left. This
is due in part to the channel not being of chat_type room. Furthermore,
the account and room identifiers are not set on the channel.
This issue becomes apparent when the plugin disconnects from the remote
services for whatever reason, and the channel is not setup again.
This issue was introduced in 06956d1.
|
| |
|
|
|
| |
The compatibility flags of BEE_USER provided by OPT flags should not be
used as they are deprecated.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Currently, the plugin relies on the 'chat add' root command in order to
create a new group chat. Aside from being an ugly hack, this prevents
the plugin from being able to automatically join the bitlbee user into
the newly created channel. In order to allow for automatic joining, the
plugin should directly create the group chat, rather than relying on
the "chat add" root command.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, all roots commands require an account identifier in order to
operate. However, more times than not, there will only be one Facebook
account per bitlbee user. The plugin should allow for the short handing
of root commands, where the account identifier is negated when there is
only one active Facebook account.
This patch allows for users with only one active Facebook account to
negate the account identifier. The negation of the account identifier
is optional. If there is more than one active Facebook account, the
root commands behave as they currently do, and require an account
identifier.
|
| |
|
|
|
|
|
|
| |
Currently, it is just assumed that the account is online, however, this
is not always the case. If one of the root commands attempts to act on
an offline account, it will typically lead to a segmentation fault. To
guard against this, an additional check must be added to ensure the
account is actually online.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
