| Commit message (Collapse) | Author | Age | Lines |
... | |
| | |
|
| |
| |
| |
| | |
This reverts commit e8ee94584cd39333aa98c2a77fca31a53735d7fb.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
| |
The previous one seemed to imply a "file not found" error, which is
misleading.
|
|
|
|
|
|
|
| |
Just freeing the list on logout and when removing items from them.
Also remove the "checking mutes" debug which is disproportionately noisy
compared to the rest of the protocol.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
Twitter doesn't error if you mute the same user multiple times.
Also, correct signedness of the stringified user ids. bitlbee keeps them as
unsigned even if the json library uses signed for integers...
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
In certain situations, e.g. when working with pregenerated
configurations, it is useful to be able lock down accounts so they
cannot be deleted and authentication information (user, password,
server) cannot be changed.
We mark such sensitive settings with ACC_SET_LOCKABLE and will refuse to
change them if the account is locked by setting the ACC_FLAG_LOCKED
flag.
This flag is stored in the xml files as account attribute locked="true".
|
|
|
|
|
|
|
|
|
| |
Basically the same thing as github PR #55, which fixes trac bug 415,
but this one conditionalized that behavior and uses the API introduced a
few commits ago.
I didn't think too much about the setting name and i'm open to changing
it to anything else
|
| |
|
| |
|
|
|
|
|
|
| |
So if someone has several connections with several clients to a chat,
they won't appear as leaving from the chat until they leave from the
last client.
|
|
|
|
|
|
|
| |
nick_hint only works when creating new users, it's a no-op after the
user is online. This new function takes care of nick changes after that.
It also helps clean up couple of hacks in irc_im.c \o/
|
| |
|
|
|
|
| |
9456255 made the variable 's' unused but failed to remove it.
|
| |
|
|
|
|
|
|
|
| |
The jabber_buddy used for messages sent from other resources connected
to the same groupchat has a different ext_jid and it's a different
object than jc->me, so doing a string comparison against acc->user is
needed.
|
|
|
|
| |
It was showing 'secondary' only before.
|
|
|
|
|
|
|
| |
This reverts commit d11ccbf6ea94264bde8b0f525c4bbedf50de0174.
After thinking about this long enough I've decided this is a bad idea,
and better wait for the hipchat server to support carbons.
|
| |
|
|
|
|
| |
This was needed back in 2010, but now it's not.
|
|
|
|
|
|
|
|
|
|
| |
Those are purple_conversation_write with PURPLE_MESSAGE_SEND flag set,
received through the write_conv UI op.
write_chat and write_im still receive and filter PURPLE_MESSAGE_SEND.
In the case of write_chat it *could* show some of those, but it seems
there's no decent way to tell echoes apart from remote self-messages.
So just keep those hidden for now.
|
| |
|
|
|
|
|
|
|
|
| |
When people build with ./configure --purple=1 --oscar=1, the native
oscar is compiled statically, which should take priority, but sometimes
purple's oscar is used instead and bad things happen, most of it being
due to calling bitlbee's native aim_callhandler instead of the function
with the same name of libpurple's liboscar.so.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reuses part of the carbons code, but it's not like it at all.
To be able to receive these messages at all, a different cap node
whitelisted by them is required. I could have used one of the official
clients, but let's try to get things done the right way.
This will start working once they make that change in their servers,
right now this is still in their ticket backlog. I'm merging this now
because it's harmless and nice to have as part of the upcoming release.
|
|
|
|
|
| |
This prevents them from being stored or copied to other clients when
carbons are enabled.
|
|
|
|
|
|
| |
imcb_find_buddy is mentioned only in nogaim.h, and is never defined anywhere.
This is misleading for plugin authors, who were probably looking for
(the actually implemented) imcb_buddy_by_handle instead.
|
|
|
|
|
|
|
|
|
| |
This reverts commit ed431c389887080dc4fa45e30d051ce733f4ce57.
I'm going to let this leak. Turns out only purple allocates an empty
list for every time this is called. Other protocols have statics, and
they always return the same thing, can't free those. Whatever. The
purple leak was insignificant, just more scratching of itches.
|
|
|
|
|
|
|
|
|
|
|
| |
It was passing the wrong data to the callback - it was supposed to pass
the data of the PurpleMenuItem but it passed the PurpleMenuItem itself.
Probably also applies to other protocols too. It worked fine with
jabber, which i'm guessing is what this code was tested with originally.
It still whines about the null return value saying "(Possible) failure"
but, eh, whatever.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes trac ticket 1175, https://bugs.bitlbee.org/bitlbee/ticket/1175
"Setting away with libpurple fails silently except for a few values"
Turns out the fallback was the first item of the list, which for
libpurple's jabber is "Feeling" (what?) and seems to be a no-op in
practice.
With this commit the fallbacks are in this order:
1. Try to find whatever the user wrote in the away setting.
2. If that fails, find "away" in the away states.
3. If that fails, use the first away state.
This might not fix it in some rare cases where the prpl doesn't have
an away state equivalent to away. But hopefully the old fallback works
for those, jabber was the weird one here.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Facebook's oauth has been broken for months, and in the last few days
they broke plain logins too, so I just added an error message that says
this when you do "account on":
Facebook's XMPP service is gone. Try this instead:
https://wiki.bitlbee.org/HowtoFacebookMQTT
Also nuked all the oauth related code, except some parts of lib/oauth2.c
which seemed generic enough to maybe help in the future with other
not-really-compliant not-really-implementations of the not-really-oauth2
not-really-spec
|
|
|
|
|
|
|
|
| |
Purple's IRC, for example, doesn't have the PURPLE_CONNECTION_HTML flag,
but still sends html for format codes.
Note that using IRC through libpurple through bitlbee is still a
terrible idea. Use ZNC instead.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Which has no connection context. Luckily local_bee exists, and libpurple
only supports only one irc user per process.
This sucks.
And yesterday I was naively thinking (again) that local_bee might not be
needed, that maybe we can do things properly. Of course it only took a
look at that one reverted commit (56985aa) to remember that life is
unfair, and that, under Moloch, everyone is irresistably incentivized to
ignore the things that unite us in favor of forever picking at the
things that divide us in exactly the way that is most likely to make
them more divisive. That being said, I think all these hacks are going
to look nicer once I sandbox the whole thing in a separate process with
one IM account per process, as opposed to one irc use per process. Then
we'll be able to rely on global state exclusively, which is saner.
|
|
|
|
|
| |
Just a trivial wrapper over irc_rootmsg(), but will help me to slightly
reduce the ugliness of an unavoidably ugly hack for libpurple.
|
|
|
|
| |
More fixing warnings.
|
|
|
|
| |
Also turn them into asserts because that's what it really does.
|
|
|
|
| |
I mean sure you could use messenger reviver but..
|
| |
|
|
|
|
|
|
|
|
| |
Just a 1msec timeout, so that it will run in the next main loop
iteration.
The official clients send the first few commands in the same request,
which reduces roundtrips during login. This commit doesn't do that.
|
|
|
|
|
| |
Most of them related to channel joins, one of them related to my recent
certificate pool path fix.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When joining named channels, purple_chat_join() returned NULL instead of
a struct groupchat, which was actually created in the conversation
created callback (prplcb_conv_new()).
If the name of this channel turned out to be different to the joined
one, this meant having one empty window in the irc client, and another
one for the other channel.
The fix is to return a mostly-empty struct groupchat immediately, and
pick it up later when the PurpleConversation is created using
bee_chat_by_title(). If that fails, fall back to creating a new one.
This bug also meant there was no proper way to report a join failure.
Future commits will address that, this one just makes that easier.
Thanks to Etan Reisner (deryni) for enlightening me while i was trying
to figure out how to fix this.
|