Dev

dev@lists.roundcube.net

1 participants
4297 discussions

Logic of identity selection
by Michael Heydekamp 09 Jul '13

09 Jul '13

I need to cover some quite special scenarios here in terms of identity selection, and therefore wanted first to understand the current logic how an identity is being selected (in order to implement a correct and working patch later on). I got stuck already at first attempt. Say we have the following two messages with their headers (please don't ask why there are two headers "Envelope-To:", just please take it as a matter of fact): Message #1: ---------------------------------------------- Delivery-date: Sat, 06 Jul 2013 20:29:21 +0200 Return-path: <theo1(a)tester.de> Envelope-To: identity1(a)test.de Envelope-To: identity2(a)test.de MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Date: Sat, 06 Jul 2013 20:29:21 +0200 From: theo1(a)tester.de To: theo2(a)tester.de Subject: Test #1 (Envelope-To: identity1(a)test.de, Envelope-To: identity2(a)test.de) Message-ID: <identity1(a)tester.de> X-Sender: theo1(a)tester.de User-Agent: Roundcube Webmail/1.0-git Test - pls ignore. ---------------------------------------------- Message #2: ---------------------------------------------- Delivery-date: Sat, 06 Jul 2013 20:29:21 +0200 Return-path: <theo1(a)tester.de> Envelope-To: identity2(a)test.de Envelope-To: identity1(a)test.de MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Date: Sat, 06 Jul 2013 20:29:21 +0200 From: theo1(a)tester.de To: theo2(a)tester.de Subject: Test #1 (Envelope-To: identity2(a)test.de, Envelope-To: identity1(a)test.de) Message-ID: <identity2(a)tester.de> X-Sender: theo1(a)tester.de User-Agent: Roundcube Webmail/1.0-git Test - pls ignore. ---------------------------------------------- Please also take it as a matter of fact that "identity1(a)test.de" and "identity2(a)test.de" are being defined as identities in Roundcube. The main difference between these two messages is the order of the "Envelope-To:" headers. But apparently that doesn't make any difference at all, as when replying to these messages, the identity "identity1(a)test.de" is being used as the sender in the "From:" header in both cases. Hmm...?!? This logic escapes me and makes my life more difficult, as this behaviour is telling me that the order (of both the same headers in the same message!) doesn't make any difference. Is the choice being taken because of the alphabetical order of the sender addresses (so that "identity1(a)test.de" is preceding "identity2(a)test.de")? At this point I stopped testing, and my next question is: As I'm able to create any custom header right before delivery, how can I make sure that this - and only this - custom header will be respected with regards to identity selection, disregarding any other headers/addresses and the entire rest of the logic...? This would be a private patch, of course. Any help and hint appreciated, for I'm a noob in terms of PHP (= I have an idea of the logic, but just can't code it). Cheers, -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany

3 9

quote chars not recognized as quote chars in HTML parts?
by Michael Heydekamp 09 Jul '13

09 Jul '13

Received a multipart/alternative message today, produced with Roundcube 0.9.2 stable (first part text/plain, second part text/html), where the quote chars ">" in the HTML part were not recognized as quote chars upon displaying in RC 1.0-git. See display comparison attached. The HTML code of the relevant paragraph (additionally qp-encoded, charset UTF-8): > > --------------------------------------------------- > >> =E2=94=82 /usr/share/vim/vim73/syntax > >> =E2=94=82 fetchmail.vim > >> =E2=94=82 /usr/share/vim/vim73/ftplugin > >> =E2=94=82 fetchmail.vim > >> =E2=94=82 /usr/share/zsh/4.3.15/functions/Completion/Unix > >> =E2=94=82 _fetchmail > > --------------------------------------------------- Is the displayed result of the HTML part how it should be...? Cheers, -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany

2 9

Re: [RCD] [Svn] [roundcube/roundcubemail] 3b944e: Fix bug where signature wasn't changed on identity selection when editing a draft (#1489229)
by Michael Heydekamp 08 Jul '13

08 Jul '13

Thanks alec, works for me! Cheers, -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany Am 08.07.2013 10:53, schrieb GitHub: > Branch: refs/heads/master > Home: https://github.com/roundcube/roundcubemail > Commit: 3b944edb02a838e92f5f849b1266f157ccfb7040 > > https://github.com/roundcube/roundcubemail/commit/3b944edb02a838e92f5f849b1… > Author: Aleksander Machniak <alec(a)alec.pl> > Date: 2013-07-08 (Mon, 08 Jul 2013) > > Changed paths: > M CHANGELOG > M program/js/app.js > M program/steps/mail/compose.inc > > Log Message: > ----------- > Fix bug where signature wasn't changed on identity selection when > editing a draft (#1489229) > > > > > _______________________________________________ > Roundcube SVN commits mailing list > svn(a)lists.roundcube.net > http://lists.roundcube.net/mailman/listinfo/svn

1 0

Re: [RCD] [Svn] [roundcube/roundcubemail] c3762a: Fix folder names truncation in Classic skin (#1489220)
by Michael Heydekamp 05 Jul '13

05 Jul '13

Am 04.07.2013 11:20, schrieb GitHub: > Log Message: > ----------- > Fix folder names truncation in Classic skin (#1489220) Thanks! But well, they're shortened rather than trucated (at least in IE8), that's how it should be, right? > Fix bug where not all event handlers were executed (because body onload > was executed after rcmail init function, sometimes) Interesting... Which possible and visible bugs (could) have occurred due to this? Cheers, -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany

2 2

Re: [RCD] bb5d72: Use also Envelope-To for identity selection (#1488...
by Michael Heydekamp 02 Jul '13

02 Jul '13

Currently Roundcube uses "Envelope-To:" and "Delivered-To:" for identity selection (besides "To:" and probably other standard headers). After we recently moved from a dedicated server to a managed server at df.eu (domainfactory), all messages do not have a header "Envelope-To:" anymore, but a header "X-Envelope-To:" instead. This often leads to a wrong identity selection (e.g. always when replying to the Roundcube lists). May I kindly request to support the header "X-Envelope-To:" as well? Cheers, -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany Am 12.12.2012 08:55, schrieb GitHub: > Branch: refs/heads/master > Home: https://github.com/roundcube/roundcubemail > Commit: bb5d7282855dd83ccdd211cb77d0776dce71468e > > https://github.com/roundcube/roundcubemail/commit/bb5d7282855dd83ccdd211cb7… > Author: Aleksander Machniak <alec(a)alec.pl> > Date: 2012-12-11 (Tue, 11 Dec 2012) > > Changed paths: > M CHANGELOG > M program/lib/Roundcube/rcube_storage.php > M program/steps/mail/compose.inc > > Log Message: > ----------- > Use also Envelope-To for identity selection (#1488553) > > > > > _______________________________________________ > Roundcube SVN commits mailing list > svn(a)lists.roundcube.net > http://lists.roundcube.net/mailman/listinfo/svn

3 6

File(skins/classic) is not within the allowed path(s)
by Reindl Harald 30 Jun '13

30 Jun '13

there should be used a full qualified path [23-Jun-2013 05:45:01 Europe/Vienna] PHP Warning: is_dir() [http://at.php.net/manual/de/function.is-dir.php]: open_basedir restriction in effect. File(skins/classic) is not within the allowed path(s): (/usr/share/roundcubemail:/var/log/roundcubemail:/etc/roundcubemail:/usr/share/pear) in /usr/share/roundcubemail/program/include/rcmail_output_html.php on line 156 _____________________ cronjob: umask 006; nice -n 19 ionice -c 3 php -d open_basedir="/usr/share/roundcubemail:/var/log/roundcubemail:/etc/roundcubemail:/usr/share/pear" /usr/share/roundcubemail/bin/cleandb.sh >> /var/log/roundcubemail/errors

2 1

Roundcube and Accessibility
by Paul Boddie 27 Jun '13

27 Jun '13

Hello, I have recently had reason to look at Roundcube's accessibility support, particularly for blind and visually impaired users who might consider using Roundcube with a screen reader. I am not in this audience, but I have been attempting to make myself more aware of projects, initiatives and specifications particularly related to Web development and accessibility. It has not escaped my attention that Roundcube is often deployed alongside other solutions, typically to offer users the choice of webmail client where Roundcube is perhaps regarded as the most "desktop-like", and other clients such as Horde and SquirrelMail are regarded as being less fancy. Some examples: https://calmail.berkeley.edu/ http://www.cms.hu-berlin.de/dl/kommunikation/email/webmail It did make me wonder whether the less "fancy" alternatives are being used because they offer a more accessible experience to screen reader users. As part of an evaluation of Kolab and Roundcube, I have been taking a look at the Roundcube interface in conjunction with accessibility tools such as Fangs [1], Orca [2] and Read2Me [3], also looking at the consensus around accessible Web application design. I also searched the mailing lists for discussion around accessibility issues with Roundcube, but found only the following things: http://trac.roundcube.net/ticket/1484257 http://trac.roundcube.net/ticket/1487041 It has been difficult to find much discussion in the last five years on the topic, and so I'm hoping to get some opinions on this matter now to see if anything needs doing and could be done fairly easily to improve Roundcube in this respect. To get started, I have been looking at what Fangs produces for the Roundcube calendar plugin provided with a full Kolab installation, trying to identify basic properties of the interface that could be enhanced to offer a potentially more navigable and accessible experience. According to various Web accessibility guides, exposing headings, page structure and links are all things that help people with screen readers. Roundcube uses headings quite successfully already, for example, although I haven't yet been able to assess how this translates to an improved screen reader experience. (My intention is to evaluate the experience with Orca and to try and devise concrete suggestions for improvements.) Another topic that has become prominent in recent times is that of the WAI-ARIA specifications/technologies. It appears that jQuery annotates elements in the DOM with ARIA attributes, but I haven't really investigated the specific Roundcube support for ARIA. It would be interesting to hear perspectives on such technologies from members of this list. At the moment, I'm really just testing the waters for the potential to improve Roundcube in this way. I'm not a major PHP/JavaScript developer, and the realm of Web accessibility is also rather new to me (in depth), but I'd like to know if developers on this list perceive any shortcomings of Roundcube in this regard and whether there might be convenient ways to make it better. Regards, Paul [1] https://addons.mozilla.org/en-US/firefox/addon/fangs-screen-reader-emulator/ [2] https://projects.gnome.org/orca/ [3] https://addons.mozilla.org/en-US/firefox/addon/read2me-speechify-the-web/

1 0

Roundcube Popups (IE9)
by Michael Heydekamp 23 Jun '13

23 Jun '13

Scenario: Popups are blocked in IE9. Double clicking on a message opens the message in a new popup window without any warning fom IE9. Pressing Enter on the same message does not open the message, but brings up a warning message of IE9, that Popups are blocked. Is this different behaviour a Roundcube or an IE9 issue? Cheers, -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany

2 2

Re: [RCD] sig dashes broken in 1.0-git?
by Michael Heydekamp 18 Jun '13

18 Jun '13

Arne, uh, I must admit that this standard (?) with three sig dashes (without WSP) for top-posted replies is totally new to me, thanks for the input. Is this documented somewhere (RFCs)...? And what's the sense of and reason for it? My default setting is indeed top-posting, because most people I'm in touch with, are unfortunately not familiar with inline quoting. The problem is, that, depending on the person I'm replying to, I do not always use top-posting. In those cases I'm moving the the sig to the bottom of the mail. This would lead to a sig with three dashes at the bottom, so I would have to remove one of them manually, whenever I'm moving a sig to the bottom. Not very convenient... So I think it's better to include a two-dashes-separator in the sig (as I had it before) and always use this one, no matter if top or bottom. Fortunately, RC doesn't touch this, when being part of the sig. But as we speak, I'd like to emphasize again my proposal to have an option in the addressbook, in which way I want to reply to this particular person. Cheers, -- Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany Am 06.06.2013 01:27, schrieb Arne Berglund: > The three dashes is correct for top-posted replies, and should only appear > when sig is inserted above the quote. If the sig is below the quote, 0.9.x > and earlier then inserts two dashes with WSP. > > I don't currently have a git version running, so I can't compare the > behavior to the production versions. > > This reply is top-posted from 0.9.1. > > --- > Arne Berglund > System Administrator, Internet Services > Lane Education Service District > Eugene, OR > ____________ > > > > On 2013-06-05 15:51, Michael Heydekamp wrote: >> I used to include the sig dashes "-- " in all o my my signatures, but as I >> realized today, Roundcube will add them anyway (if not existent). So I >> removed them in all signatures of all of my identities. >> >> This leads to the following behaviour: >> >> 1) Composing a new message: All OK. >> >> 2) Replying to to a message: Roundcube creates THREE sig dashes instead of >> two ("---"), and without the mandatory WSP at the end of the string. >> >> Strange, uh...? >> >> Cheers, > _______________________________________________ > Roundcube Development discussion mailing list > dev(a)lists.roundcube.net > http://lists.roundcube.net/mailman/listinfo/dev

7 12

I need help
by Paul Sosthenes 17 Jun '13

17 Jun '13

Hello, I have attached a screen capture, for the problem I have come across, please see the attachment, and help me. -- Digital Seven D7, Mr. Paul K. Sosthenes, P.O.BOX 1312, Tabora-Tanzania E-mail : moul.76(a)gmail.com Phone No : 255752476139 Skype : pasonet

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Dev