Re: [SM-DEVEL] option to turn off 'Bypass Trash' ?

[Fredrik Jervfors <sqm_admin@fi...>]

>>>> First of all, the issue of the 'Bypass Trash' link in
>>>> read_body.php being only a link, and easy to accidentally click.
>>>> This should *definitely* be changed, though to what is a tricky
>>>> question. All of the other message operators in that area are
>>>> links, so having one button would be weird.
>>>
>>> Make it a check box. If the box is checked, and you hit delete,
>>> then you remove permanently... that makes it a 2 step process
>>> instead of just one.
>>
>> Check box does not work with GET request (links). Not sure if
>> javascript popups (Compose/Reply/Forward in a new window) work with
>> POST (buttons).
>>
>> If "[delete] {} don't store in trash" is button, it would have to be
>> moved to the right in order to have UI consistency.
>
> I was thinking of the other "Bypass trash" option, which i noticed is
> already a check box... guess it'd be helpful if we were all on the
> right page (read_body instead of mailbox) ;)

Another way of doing this:

1. User tries to move a mail to the trashcan.
2. If it works, goto 7.
3. Open page in right frame saying "Mail is to big to fit in trashcan. Do
you want to [Delete mail] [Empty trashcan] [Cancel]?"
4. If [Delete]: mark mail for deletion, expunge. Goto 7.
5. If [Empty trashcan]: Empty trashcan, move mail. Goto 7.
6. If [Cancel]: Nothing happens.
7. Problem solved.

What are the arguments for and against a solution like the above? Or did I
completly misunderstand anything?

Sincerly,
Fredrik.

Re: [SM-DEVEL] option to turn off 'Bypass Trash' ?

[Jonathan Angliss <jon@sq...>]

Hello Tomas,
On Wednesday, March 24, 2004, Tomas Kuliavas wrote...

>>> First of all, the issue of the 'Bypass Trash' link in
>>> read_body.php being only a link, and easy to accidentally click.
>>> This should *definitely* be changed, though to what is a tricky
>>> question. All of the other message operators in that area are
>>> links, so having one button would be weird.

>> Make it a check box. If the box is checked, and you hit delete,
>> then you remove permanently... that makes it a 2 step process
>> instead of just one.

> Check box does not work with GET request (links). Not sure if
> javascript popups (Compose/Reply/Forward in a new window) work with
> POST (buttons).

> If "[delete] {} don't store in trash" is button, it would have to be
> moved to the right in order to have UI consistency.

I was thinking of the other "Bypass trash" option, which i noticed is
already a check box... guess it'd be helpful if we were all on the
right page (read_body instead of mailbox) ;)

-- 
Jonathan Angliss
(jon@...)

Posting Hints: http://article.gmane.org/gmane.mail.squirrelmail.user/16718

Re: [SM-DEVEL] option to turn off 'Bypass Trash' ?

[Tomas Kuliavas <tokul@us...>]

>> First of all, the issue of the 'Bypass Trash' link in read_body.php
>> being only a link, and easy to accidentally click. This should
>> *definitely* be changed, though to what is a tricky question. All of
>> the other message operators in that area are links, so having one
>> button would be weird.
>
> Make it a check box. If the box is checked, and you hit delete, then
> you remove permanently... that makes it a 2 step process instead of
> just one.

Check box does not work with GET request (links). Not sure if javascript
popups (Compose/Reply/Forward in a new window) work with POST (buttons).

If "[delete] {} don't store in trash" is button, it would have to be moved
to the right in order to have UI consistency.

-- 
Tomas

Re: [SM-DEVEL] option to turn off 'Bypass Trash' ?

[Jonathan Angliss <jon@sq...>]

Hello Joshua,
On Wednesday, March 24, 2004, Joshua Jabbour wrote...

> So, I think there are two issues here...

>> I wouldn't make it a user preference, I'd rather it matched the UI
>> of the message list. In other words, not a link, but a checkbox
>> modifier for the regular Delete link.

> First of all, the issue of the 'Bypass Trash' link in read_body.php
> being only a link, and easy to accidentally click. This should
> *definitely* be changed, though to what is a tricky question. All of
> the other message operators in that area are links, so having one
> button would be weird.

Make it a check box. If the box is checked, and you hit delete, then
you remove permanently... that makes it a 2 step process instead of
just one.

> Second issue, that being the ability to disable the entire feature of
> 'Bypass Trash'.

That should be easy.

> [..] If I really need to get rid of a message, I go into the Trash
> folder, and Delete the message from there. Then it's gone. True, a
> two-stepped process (but a better one than the other solutions I've
> heard of turning off the preference for 'Move to Trash' and then
> turning it back on...).

However, your two step solution doesn't work if the user is over
quota, which I believe was one of the main reasons the option to
bypass trash was introduced in the first place.

> On another note, as I mentioned before, I have simply commented out
> the 'Bypass Trash' lines as shown below. Is there any reason that
> having this commented out, but still existing in the Delete
> functions, would be a problem? (i.e. is just commenting the 3 lines
> below fine and dandy?)

No, because it just means nothing gets passed on to tell it to be
permanently deleted, so the code never runs. It should be fine.

-- 
Jonathan Angliss
(jon@...)

Posting Hints: http://article.gmane.org/gmane.mail.squirrelmail.user/16718

Re: [SM-DEVEL] option to turn off 'Bypass Trash' ?

[William Hooper <whooperhsd2@ea...>]

Joshua Jabbour said:
> If I really need to get rid of
> a message, I go into the Trash folder, and Delete the message from
> there. Then it's gone. True, a two-stepped process (but a better one
> than the other solutions I've heard of turning off the preference for
> 'Move to Trash' and then turning it back on...).

IIUC the "Bypass Trash" was implemented for the issue with large mails and
a quota.  Since "Move" is really "Copy then delete", large messages might
not be deletable (is that a word?) when using the trash.  This is probably
the context that you see the preference changing mentioned in.

-- 
William Hooper

[SM-DEVEL] Embedding html mail

[Marc Groot Koerkamp <marc@sq...>]

Hello,

I was thinking about the way we render html mail inside read_body.php and
came to the conclusion that we should embed the html mail as object. The
object tag is part of the html 4 spec and is supported by:

MSIE 	3.0
MOZ 	1.0
NN 	4.0
OP 	4.0

The reason for this is the existence of STYLE tags, which must be located
in the header of an html document, inside html mail. Of course we can
rewrite the entire html email and revert to style attributes but using th=
e
OBJECT tag is much cleaner and easier.

This raises a few questions, namely:
1) Are there browsers around which cannot handle this.
2) If yes, does that bother us ? (SquirrelMail supports HTML 4, we do not
say we support older HTML specifications)
3) Do we need browser detection and simply drop style tags if we cannot
make use of object embedding because the detected browser does not suppor=
t
it?
4) Are there better alternatives?


Regards,

Marc Groot Koerkamp.

Re: [SM-DEVEL] option to turn off 'Bypass Trash' ?

[Joshua Jabbour <lists@wa...>]

So, I think there are two issues here...


 >I wouldn't make it a user preference, I'd rather it matched the UI of 
the
 >message list.  In other words, not a link, but a checkbox modifier for 
the
 >regular Delete link.


First of all, the issue of the 'Bypass Trash' link in read_body.php 
being only a link, and easy to accidentally click. This should 
*definitely* be changed, though to what is a tricky question. All of 
the other message operators in that area are links, so having one 
button would be weird.

Second issue, that being the ability to disable the entire feature of 
'Bypass Trash'. I personally don't use it, and think many other people 
would like to be able to get rid of it. (It may not be a problem if we 
can solve issue one from above, but even then is the issue of having 
another button there that I'd probably never use.) I like having my 
Deleted msgs sent to the Trash for a week to cool off; I've pulled many 
accidentally-deleted msgs out of there. If I really need to get rid of 
a message, I go into the Trash folder, and Delete the message from 
there. Then it's gone. True, a two-stepped process (but a better one 
than the other solutions I've heard of turning off the preference for 
'Move to Trash' and then turning it back on...). Anyway, I like the 
extra confirmation of the two-step process. Many people would agree, I 
think. If not, then they could enable 'Bypass Trash' in the 
(hopefully-implemented) preference)


On another note, as I mentioned before, I have simply commented out the 
'Bypass Trash' lines as shown below. Is there any reason that having 
this commented out, but still existing in the Delete functions, would 
be a problem? (i.e. is just commenting the 3 lines below fine and 
dandy?)

read_body.php
// $delete_link .= '&nbsp;(<a href="' . 
$delete_url.'&amp;bypass_trash=1">'
//               ._("Bypass Trash").'</a>)';

mailbox_display.php
// echo '<input type="checkbox" name="bypass_trash">' . _("Bypass 
Trash");


-j

Re: [SM-DEVEL] $msgs array

[Gustav Foseid <gustavf-squirrel@in...>]

Marc Groot Koerkamp:
> What Squirrelmail always did (as far as I know) is downloading the
> complete header list for a mailbox in order to achieve client side
> sorting.

As a vintage developer I think I can confirm that (although I never
worked on that part of the code). However, it is still as inefficient
as it has always been.

-- 
Gustav Foseid, Initio IT-løsninger AS
http://www.initio.no/