[SM-DEVEL] Re: [SM-USERS] Re: 'From' and 'To' columns

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[SM-DEVEL] Re: [SM-USERS] Re: 'From' and 'To' columns

Daniel Watts
Marc Groot Koerkamp wrote:

>>Fredrik Jervfors wrote:
>>
>>
>>>>>Hi,
>>>>>is there any way to create folders where i can save sent and
>>>>>received mails and see them correct with "from" and "to" columns?
>>>>>The problem is
>>>>>that if i save sent messages with received ones in a folder i only
>>>>>see "from" and so i know i have sent them but i dont know whom i
>>>>>sent them. The best solution would be to have two columns in a
>>>>>folder one with "from" and one with "to". Is this possible? Has
>>>>>anybody experience with that?? Thanks, bye, b52
>>>>>
>>>>
>>>>We discussed something similar - the ability to assign folders as
>>>>containing sent or received mail items. It would be a a waste of space
>>>>to have a TO column in your inbox!
>>>
>>>
>>>
>>>I have serveral e-mail accounts (aliases) using the same inbox, so I
>>>have to disagree. The possibility might come in handy from time to time,
>>>so I wouldn't consider it a complete waste of space. Still, such a
>>>feature must be configurable since not everyone would have use for it.
>>>
>>>Sincerely,
>>>Fredrik.
>>>
>>>
>>
>>Specifically to the SQM admins -
>>Are there any plans to address this issue? I have had more requests for
>>something to help with this problem. Personally I think why not move the
>>whole "OPTIONS>INDEX" settings into a small square box on the folder page
>>that sits to the right side of all the column headings (much like an
>>offline mail client). Clicking this would bring up a window allowing you
>>to configure the folder columns *FOR THAT FOLDER*. Why  not have an "Apply
>>to all" butotn as well?
>>
>>This would lead to the possibility of more columns - eg flags,
>>importance levels etc which would bring squirrelmail in line with standard
>>email clients.
>>
>
>
> A While ago I was working on this. Actually I made it possible to show the
> following columns:
> checkbox, from, date , subject, flags, size, attachment, receive date, to,
> cc, bcc.
>
> The plan is to store the column order and the columns to show per mailbox
> so you can i.e. choose to show 'from' and to for certain mailboxes.
>
> The internal coding is done but the big showstopper is how to store these
> settings cleanly in an associative array together with other mailbox
> related settings (i.e. sort order per mailbox).
>
> Another thing what is needed is an interface where you can change the
> column settings per mailbox. We have one but it doesn't support settings
> per mailbox and stuff like inherit column order from parent or recursive
> change the column order on current mailbox and the subs. Last but not
> least, disable all this because sometimes a webmail provider likes to keep
> it simple which means hiding or disabling the complicated
>
> Current model for storing preferences isn't realy good enough (I'm a
> perfectionist and don't do hacks anymore) for it so I started on
> restructuring the our preference system. That was also the moment for a
> change in priorities,  I was a little busy with playing tim the toolman in
> my new home.
>
> The next few months I want to finish where I started on and make the
> changes ready for the masses. (this also includes templates ;) )
>
> To summarize:
> 1) Create a preference/config system where we group settings per module in
> associative arrays (easy to extend) and add support for access control
> list. A squirrelmail admin should be able to do the following actions per
> setting:
> * make settings visible or hide them
> * set default values
> * override user settings
> * permissions on settings with acl support
>
> Internally we need to tune our config system and see how we can combine
> current config widgets with templates. I didn't make up my mind yet about
> how to deal with that. I only know we should autocreate configpages just
> as we do now so leaving it all to a template is probably not an option.
> Probably introducing template widgets for each kind of option (boolean,
> optionlist, dropdownlist, groupbox, whatever) and a config template wich
> includes the widget templates is an option but hey i'm not a template
> specialist.
> 2) finish a template class
> 3) create templates for the mailbox option page
> 4) create templates for all other regrouped option pages
> 5) ...
>
> A lot of work !!!
>
> If we want to speed up development a littlebit then we have to make
> appointments about the internal format of userpreferences and
> configsettings (config.php). As far as me concerns they are the same. In
> other words, we should use the same code for handling userprefs and config
> settings. A config settings is nothing more then a readonly setting for
> normal users.
>
> If we agree on the internal format we can work on a system to build up the
> interface. Current system is pretty good but contains to many custum made
> interface stuff so if we can replace the custum interface stuff by common
> useable widgets we have a good start. (we need to autogenerate the option
> pages so we can extend it very easy)
>
> To keep our code running we need to map all old config and preference vars
> to the new internally used associative config arrays. We can do that piece
> by piece (module by module).
>
> Probably we should also make differenation between interface related vars
> which need to be passed forward to a template and internal, non interface
> related vars. I.e:
> $aConf['compose']['template']['width'] = 600
> $aConf['compose']['template']['height'] = 800
> $aConf['compose']['template']['whatever'] = "whatever"
>
> $aConf['compose']['deliver']['type'] = smtp
> $aConf['compose']['deliver']['port'] = 25
> $aConf['compose']['deliver']['username'] = marc
> $aConf['compose']['deliver']['pass_encrypted'] = whatever
>
> Anyway, enough to think about. Comments, volunteers? Please reply to this
> message or contact me.
>
> Regards,
>
> Marc Groot Koerkamp.
>
>

Digging this up from Janurary 2005.

I'm not going to ask "when will this be done" as it's a lot of work to
do I know.

However, is there any way at all a plugin or a simple source patch will
allow the inclusion of a "to" column in folders other than the INBOX?

Perhaps a plugin that shows a list of folders with checkboxes next to
each one "Show TO Column". This writes preferences:

show_to_column = "folder1:folder2:folder3"

Then mailbox dislpay references the user prefs and for any columns who's
names are in the show_to_column preference get the to column shown.

Daniel





-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
--
squirrelmail-devel mailing list
Posting Guidelines: http://squirrelmail.org/wiki/wiki.php?MailingListPostingGuidelines
List Address: [hidden email]
List Archives: http://news.gmane.org/thread.php?group=gmane.mail.squirrelmail.devel
List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=7139
List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel