Delete left over account entries in tiny email client?

So i had to delete my accounts (outbound), because each e-mail account was listed twice after we upgraded to the newest version. But now I have this issue:
So basically there is two left over account entries that is listed with < > and I’m not sure how to get rid of them. If I look in the database:

–and –

Those two leftovers are not to be found…

Any idea guys where these could reside so I can delete these?


Sorry, I don’t understand your issue

You have two rows in the database that don’t appear in the UI? Maybe they have deleted=1?

Or is it something else?

There may outbound definitions in inbound_email table, it’s base64 encoded in the stored_options field. You can decode it easily to see what’s in there.

Hi @pgr

Thanks for your reply.

I deleted all the outbound accounts and these two entries are still there.

Now I added all the accounts back and now they are listed multiple times:

I don’t understand why SuiteCRM does this. As you can see the same account is listed up to 3 times. There is 3 private outbound and one group account.

hello@ listed 2 times
ceo@ listed 4 times
ds@ .dk 2 times
ds@ .se 2 times

Pretty messed up right?

Also SuiteCRM keeps using the Danish template instead of the e-mail template that i set up for each account (one for the English, one for Swedish account and one for the Danish account).

This is all very strange.

Its more like reverse:
I have two deleted rows that appear inn the UI.

But now after I added the accounts back they are duplicated several times.

So, did the clues in my last post lead you anywhere?

Net yet. Thank you @pgr for asking. I appreciate that.
I have check it tonight when I have more time for myself.

But basically you copy paste the data from the DB into that tool right?

I don’t understand also why my mail templates doesn’t load. I made three templates based on English, Danish and Swedish. But only one of them load.

In the old system before this update it switched automatically when you changed the email. Not so anymore. :upside_down_face: But that may just be my system that has been bugged by this update maybe… I don’t know…

Well let’s take my ceo@mail for example; which is listed 4 times in the tiny email client. In the DB outbound email >>>* I cannot find anything that would give the cause to be listed 4 times:

a:12:{s:9:"from_name";s:32:"My name | Company Ltd Ltd";s:9:"from_addr";s:20:"";s:13:"reply_to_name";s:32:"My name | Company Ltd Ltd";s:13:"reply_to_addr";s:20:"";s:10:"only_since";b:0;s:13:"filter_domain";s:0:"";s:30:"email_num_autoreplies_24_hours";s:2:"10";s:26:"allow_outbound_group_usage";b:0;s:14:"outbound_email";s:36:"d2164cf3-6949-1b20-15f5-63e96f40252f";s:7:"mailbox";s:5:"INBOX";s:11:"trashFolder";s:13:"Deleted Items";s:10:"sentFolder";s:10:"Sent Items";}

It looks quite normal, doesn’t it @pgr?

So hmm… What else could be the cause of it do you think? :thinking:

Kind regards

So what do you think?
is there somewhere else in the DB I need to look @pgr?


I don’t know. There’s a bug somewhere and it’s not easy to get more information without being able to access the system (which I am not asking to do, I don’t have time).

Your best option is perhaps reporting it on github. And your best workaround is to just delete all inbound email accounts and start over.

Thanks pgr.
I did the try and delete the accounts both inbound and the outbound and start over but then I got those weird duplicate empty < > entries there instead as seen in the picture below:
Maybe you are correct and it is some kind of bug. But on the same time it doesn’t make sense as that < > must load form somewhere in the database right?

That dropdown is new code. It’s normal to have insufficiencies. There seems to be something in your installation that it isn’t prepared to handle.

SQL queries with relationships sometimes produce multiple rows when there are multiple entries in the relationship tables. So you could have left-over relationships between the user and some long gone email account. The SQL would need to be adjusted to handle these cases.

Well something has gone totally south, that’s for sure. It used to work like Swiss clock before with no greater issues.

What do you mean in this case with “adjusted”? Like we need to tweak the SQL server itself or just find the failing data in the database?