| Commit message (Collapse) | Author | Age | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
