Roundcube 1.0.3 released

I don't like the fact that Custombuild is managing everyones Roundcube config by simply overwriting the existing config.inc.php with every Roundcube update:

- This .INBOX change broke a couple of clients their webmail, these clients were not able to delete emails anymore since the configured trash folder didn't exist anymore.
- Spellings check is suddenly set to "false" in the roundcube config.
 
DutchTSE, with the newest release of CB 2.0 it sets webapps_inbox_prefix=yes, if it detects options.conf file on the system. If there is no options.conf file, webapps_inbox_prefix=no is set on the generation time. enable_spellcheck was always false, so it hasn't changed. If you'd like to customize your config.inc.php, please check http://help.directadmin.com/item.php?id=365.
 
I've noticed a new 'Archive' folder, and a new button for it. I've moved things there accidentally :( because it's located (on the 'Classic' skin I use) where the delete button used to be located.

I already had a folder called zArchive (so it'll alphabetize to the bottom) where I have lots of subfolders for stuff I keep.

Anyone know where this new folder came from? It's not in the Roundcube changelog.

Jeff
 
Maybe is the "Archive" plugin that may be included now (smtalk can confirm).

The default created folder are stored in config.inc.php file in /var/www/html/roundcube/config/

Regards
 
RoundCube 1.0.3 has the following in config.inc.php.sample file by default:
Code: 
// List of active plugins (in plugins/ directory)
$config['plugins'] = array(
    'archive',
    'zipdownload',
);

And CB 2.0 just uses these defaults :) It doesn't enable/disable these 2 plugins.
 
I guess we'll stick with them, then, now that I know about it. It was just surprising when it popped up; I didn't know from where.

Thanks.

Jeff
 
jlandes said:
[..cut..]Also, the .Junk folder is created by RoundCube when a user logs in for the first time.
Click to expand...

This is strange. On one of my servers the folder Junk is always created when creating new accounts, but in my other servers, it is called Spam. I can't understand why one server is different on that name.

I am testing SeLLeRoNe's script tonight, hope it works correct. :)
 
SeLLeRoNe said:
Be sure to make a backup first ;)
Click to expand...

Thank you for the reminder. :) I am using R1Soft and have backup of everything using R1Soft on external server. However I wanted to run a Admin backup from DirectAdmin of all users in addition, however if I do not select "Domains Directory", then I don't get a backup of the default email accounts (those with user name and not complete email address as user name). The problem with this, is that I don't want to fill up the server with those big backup of users home directory, when I only want the email data. So I guess I will have to only use R1Soft if things go wrong, at least regarding restore of default system email accounts wich not will be inluded in admin backup in DirectAdmin because I don't select "Domains Directory". Wel, this was a little off-topic. :)
 
I have tested your script on two servers wich do not have any customers, and it worked perfectly. It also copied the contents on the default system email accounts. So it seems very good.

Cross my fingers, I will soon run your script on the servers with my customers, hope it work as good as it did on the first two servers. :)
 
Well i'd used the same script on my production servers without problem :) But a backup is always a good point where to start from ;)

Regards
 
This is a little late to the party, but we had a few requests to be able to merge existing data, in the even that there was "Sent" data in both the INBOX.Sent, and Sent..
I've coded this in the DA binaries (currently in the pre-release binaries)
http://www.directadmin.com/features.php?id=1674

which will go through INBOX.Sent, INBOX.Drafts, INBOX.Trash, and merge them into Sent, Drafts, Trash, followed by removal of the old paths and update of "subscriptions" file.

The direction of the merge is based on the CustomBuild 2.0 setting:
webapps_inbox_prefix=no

so if you have:
webapps_inbox_prefix=yes
it will be the reverse:
Sent -> INBOX.Sent, and Sent is removed.

So if you have CustomBuild 1.1/1.2 OR webapps_inbox_prefix=yes, you might not want to use the above feature, else anyone using any other client, like outlook will end up having Outlook create duplicates.... making a similar mess.

It should also rename anything like .INBOX.Sent.subfolder to be .Sent.subfolder, but wouldn't touch the subscriptions file for that case.
Folders are only unsubscribed from, if the removal went well.

John
 
Question for anyone who has done this:

When you convert to not use the INBOX prefix, where does the Sent folder end up showing up in Roundcube? In IMAP desktop clients?

Is it still handled as a special folder and placed near the top? Or does it end up alphabetically in a long list, hard to find?

This is important to me and others who expect to be able to easily find SENT (and in fact other special folders) near the top.

Your reply is appreciated.

Thanks.

Jeff
 
It will be taken as special folder as for the ones with prefix, and yes, are showed in top of clients/webmail list as it was aswell.

Regards
 
Thank you, Andrea.

I was about to go ahead and do this today, but then I was wondering about my clients, none of whom have ever complained, and all of whom have presumably gotten used to seeing the special folders as subfolders of the Inbox for all these years...

So I'm asking this question to the group:

Is this really something we should change?

Your opinions and reasons are appreciated.

Jeff
 
The main need for the conversion would be a few cases:

1) When we first did the folder change in RoundCube, it affected anyone who updated CB.
However, we then changed it to only use the new format (eg: "Drafts") for fresh option.conf rewrites, but keep the old format (eg: "INBOX.Drafts") for any existing options.conf files.
This will minimize the effects of the change on existing systems.
However, there was that window of time where any updates would get the change, so the script would be used for that case.

2) Restores from box with the old folder layout, to box with the new layout.
This will likely show itself in time, but if you've got a new DA box, it will have the new folder structure.
However, the backups from an old box would have the old structure.
Run it for any case where you want to merge one way or another.
As mentioned, DA does determine which direction (old->new or new->old) based on the options.conf webapps_inbox_prefix setting, but only if it's CB2.0.
For CB1.1 and 1.2, the option doesn't exist (DA won't look for it, even if you add it), so it would always default to the old format..

So if you want the new format.. you must also use CB2.0, else RC/SM updates would reset the old format in the inc.php files, unless you set it up in the custombuild/custom/* area.. (but don't touch the converter script)

John
 
Thanks, John. I'm still not sure what my clients will prefer.

Years ago it took me a long time to get used to INBOX.other but now I'm used to it, and I'm not sure which my cliens will prefer.

So comments from admins are still appreciated :)

Jeff
 
Back to the whole point of us making the change.. I believe it was only the SquirrelMail default, back in the day, which is why we ended up with the INBOX.* format.
Almost all modern email client use the new format, so we want to get in sync with that.
 
You must log in or register to reply here.
Back
Top