From: Ryo C. <ry...@il...> - 2003-01-30 00:08:32
|
I'm moving a discussion that started on the forum to the mailing list. If you're interested in the whole story, see: http://ilohamail.org/forum/view_thread.php?topic_id=5&id=1066 >Does it seem to be a much work? No, it should be relatively straight forward. The way I see it, there are two ways to implement this feature: 1) Simply add another text field to the compose window 2) Allow users to enter multiple name-email pairs (or "identities") and display them in a drop down menu. Personally, I prefer the second option. If we're going to do it, we might as well do it right. The second option could be a little more involved since I would want it to support both the file-based backend as well as any database backend (see how preferences and contacts are handled). Right now, the whole back-end code is kind of convoluted, but I'm thinking simplifying the whole process at some point as well. The only other requirement I have is that it should be admin configurable. The admin should have the options of: 1) Not allow users to specify multiple identities 2) Allow for Reply-To field only 3) Allow for From field This will kind of be an extension of the $TRUST_USER_ADDRESS directive. I might work on it sometime, but I thought I'd throw out my specs in case someone else wanted to give it a shot. Ryo |
From: Christian H. <to...@we...> - 2003-01-30 07:14:15
|
> 1) Simply add another text field to the compose window > 2) Allow users to enter multiple name-email pairs (or "identities") = and > display them in a drop down menu. > > Personally, I prefer the second option. I think it could be usefull to have the possibility to manually fill in an address (i.e. for debugging purposes, quick check of mail accounts=20 etc.). Maybe it's suitable to have two text fields call "override Reply-To" and "override From" for example, only visible in the form when configured. > If we're going to do it, we might > as well do it right. The second option could be a little more = involved > since I would want it to support both the file-based backend as well = as > any database backend (see how preferences and contacts are handled). After a first view I think it shouldn't be too complicate :) > Right now, the whole back-end code is kind of convoluted, but I'm=20 > thinking > simplifying the whole process at some point as well. What do you mean exactly? > The only other requirement I have is that it should be admin=20 > configurable. ACK How the options should be configurable? Only global and/or per user, with interface or only in the backend? > The admin should have the options of: > > 1) Not allow users to specify multiple identities > 2) Allow for Reply-To field only > 3) Allow for =46rom field Following the idea above there could be another option: Allow Overide (Both, Reply-To and From) > This will kind of be an extension of the $TRUST_USER_ADDRESS = directive. > > I might work on it sometime, but I thought I'd throw out my specs in=20= > case > someone else wanted to give it a shot. $TRUST_USER_ADDRES could be extended 1) by one flag for each option and/or 2) by one flag to allow per-user configuration where 2) is only suitable for a MySQL backend. What do you think? Christian Sch=F6nen Tag noch, Christian |
From: Ryo C. <ry...@il...> - 2003-01-30 07:33:32
|
On 1/30/2003, "Christian Horchert" <to...@we...> wrote: >I think it could be usefull to have the possibility to manually fill in >an address (i.e. for debugging purposes, quick check of mail accounts >etc.). >Maybe it's suitable to have two text fields call "override Reply-To" and >"override From" for example, only visible in the form when configured. I agree that this would be useful for debugging and also for advanced users, but it could confuse ordinary users and clutter the interface. One option is to have a user preference that says "Show textboxes to override sender addresses". >> Right now, the whole back-end code is kind of convoluted, but I'm >> thinking >> simplifying the whole process at some point as well. > >What do you mean exactly? For the MySQL backend, there's a file called "backend.MySQL.inc" that handles a lot of basic operations. I did this to make it easier to add support for other databases. With the file-based backend, there are no common functions that can be used to retreive data. So I was thinking of creating a "backend.FS.inc" file that handles the basic functionality for the file-based backend. > >> The only other requirement I have is that it should be admin >> configurable. > >ACK >How the options should be configurable? Only global and/or per user, >with interface or only in the backend? It should be a combination. If the admin configuration (in conf/conf.inc) allows users to over ride, then there should be an interface for users to enable/disable this on an individual basis. If the admin disables overrides, users shouldn't even know that it exists. >> The admin should have the options of: >> >> 1) Not allow users to specify multiple identities >> 2) Allow for Reply-To field only >> 3) Allow for From field > >Following the idea above there could be another option: >Allow Overide (Both, Reply-To and From) I wonder how often people would need to change both though. If you could specify the from field, why also specify a reply-to? >> This will kind of be an extension of the $TRUST_USER_ADDRESS directive. >> >> I might work on it sometime, but I thought I'd throw out my specs in >> case >> someone else wanted to give it a shot. > >$TRUST_USER_ADDRES could be extended >1) by one flag for each option and/or >2) by one flag to allow per-user configuration > >where 2) is only suitable for a MySQL backend. >What do you think? Actually, I was thinking of a combination. In conf/conf.inc we'd add a directive like $ALLOW_SENDER_OVERRIDE where the possible values are {"none", "from", "replyto", "both}. If this directive is set to anything other than "none", users can be presented with an interface that will allow them to enable this feature for themselves. My general philosophy is "give users the option of having it as well as NOT having it". For example, in 0.8, there's an option to hide the CC/BCC fields by default in the compose window. I added this because 95% of the email I send don't have CC's and BCC's and the text fields just use up space. Ryo |
From: Christian H. <to...@we...> - 2003-01-30 20:45:45
|
> For the MySQL backend, there's a file called "backend.MySQL.inc" that > handles a lot of basic operations. I did this to make it easier to = add > support for other databases. With the file-based backend, there are = no > common functions that can be used to retreive data. So I was thinking=20= > of > creating a "backend.FS.inc" file that handles the basic functionality=20= > for > the file-based backend. But backend.MySQL.inc is not used by all other MySQL includes. Does it have a special reason that read_contacts.MySQL.inc doesn't utilize this include? >> How the options should be configurable? Only global and/or per user, >> with interface or only in the backend? > > It should be a combination. If the admin configuration (in=20 > conf/conf.inc) > allows users to over ride, then there should be an interface for users=20= > to > enable/disable this on an individual basis. If the admin disables > overrides, users shouldn't even know that it exists. I first though about the admin could handle this per user in the=20 backend, but it was a stupid idea. > I wonder how often people would need to change both though. If you=20 > could > specify the from field, why also specify a reply-to? Not very often, sure. But if you spoof the senders address it can be=20 useful to have a different address which refers to another mailbox. >> $TRUST_USER_ADDRES could be extended >> 1) by one flag for each option and/or >> 2) by one flag to allow per-user configuration >> >> where 2) is only suitable for a MySQL backend. >> What do you think? > > Actually, I was thinking of a combination. In conf/conf.inc we'd add = a > directive like > $ALLOW_SENDER_OVERRIDE where the possible values are {"none", "from", > "replyto", "both}. If this directive is set to anything other than > "none", users can be presented with an interface that will allow them=20= > to > enable this feature for themselves. That makes sense. But how they linked all together? At the moment, $from and $reply_to=20 are set by the trigger $TRUST_USER_ADDRESS. This must be extented or completely rewritten. > My general philosophy is "give users the option of having it as well = as > NOT having it". I fully agree with that any way. Christian Sch=F6nen Tag noch, Christian Horchert= |
From: Ryo C. <ry...@il...> - 2003-01-31 19:13:14
|
On 1/30/2003, "Christian Horchert" <to...@we...> wrote: >> For the MySQL backend, there's a file called "backend.MySQL.inc" that >> handles a lot of basic operations. I did this to make it easier to add >> support for other databases. With the file-based backend, there are no >> common functions that can be used to retreive data. So I was thinking >> of >> creating a "backend.FS.inc" file that handles the basic functionality >> for >> the file-based backend. > >But backend.MySQL.inc is not used by all other MySQL includes. Does it >have a special reason that read_contacts.MySQL.inc doesn't utilize this >include? You're right, but that will change at some point. I'll be changing the contacts stuff to use backend.MySQL.inc in a similar fashion as the calendar stuff in 0.8. >>> How the options should be configurable? Only global and/or per user, >>> with interface or only in the backend? >> >> It should be a combination. If the admin configuration (in >> conf/conf.inc) >> allows users to over ride, then there should be an interface for users >> to >> enable/disable this on an individual basis. If the admin disables >> overrides, users shouldn't even know that it exists. > >I first though about the admin could handle this per user in the >backend, but it was a stupid idea. > >> I wonder how often people would need to change both though. If you >> could >> specify the from field, why also specify a reply-to? > >Not very often, sure. But if you spoof the senders address it can be >useful to have a different address which refers to another mailbox. Hm... I'll think about that. I have seen webmail programs (can't remember which) that lets users specify both the "from" and "reply-to" fields. It's useful, but also prone to abuse (of course, the header contains tracable information, but that won't help until after the fact). >>> $TRUST_USER_ADDRES could be extended >>> 1) by one flag for each option and/or >>> 2) by one flag to allow per-user configuration >>> >>> where 2) is only suitable for a MySQL backend. >>> What do you think? >> >> Actually, I was thinking of a combination. In conf/conf.inc we'd add a >> directive like >> $ALLOW_SENDER_OVERRIDE where the possible values are {"none", "from", >> "replyto", "both}. If this directive is set to anything other than >> "none", users can be presented with an interface that will allow them >> to enable this feature for themselves. Ah, right. I see what you're saying...and you're right. It doesn't make sense to have both directives. So I would probably prefer to use $ALLOW_SENDER_OVERRIDE and replace $TRUST_UESR_ADDRESS. >That makes sense. >But how they linked all together? At the moment, $from and $reply_to >are set >by the trigger $TRUST_USER_ADDRESS. This must be extented or completely >rewritten. > >> My general philosophy is "give users the option of having it as well as >> NOT having it". > >I fully agree with that any way. Ryo |
From: Christian H.H. <chh...@ve...> - 2003-02-03 09:20:21
|
I am nearly done with my stressful jobs. I am pretty experienced with PH, so if you say me what to do I can offer coding help from tomorrow on (husday). The most important thing for me/us is about the subject of this thread ;) IMHO there are three main tasks to get mutiple identities to work: The organisation of the identities data (I suggest to have id, uid, name and email since it's a 1-to-n-relation), the building of the global and user prefs and the control structure in addition (or as replacement) of the $TRUST_USER_ADDRESS. Just tell me what I shall do :) >>> For the MySQL backend, there's a file called "backend.MySQL.inc" that >>> handles a lot of basic operations. I did this to make it easier to >>> add >>> support for other databases. With the file-based backend, there are >>> no >>> common functions that can be used to retreive data. So I was >>> thinking >>> of >>> creating a "backend.FS.inc" file that handles the basic functionality >>> for >>> the file-based backend. >> >> But backend.MySQL.inc is not used by all other MySQL includes. Does it >> have a special reason that read_contacts.MySQL.inc doesn't utilize >> this >> include? > > You're right, but that will change at some point. I'll be changing the > contacts stuff to use backend.MySQL.inc in a similar fashion as the > calendar stuff in 0.8. BTW: Is there a possibility to use MySQL for caches and attachments, too? Since we are on a shared host and the Apache is running as nobody, only root can handle FS probs. >>> I wonder how often people would need to change both though. If you >>> could >>> specify the from field, why also specify a reply-to? >> >> Not very often, sure. But if you spoof the senders address it can be >> useful to have a different address which refers to another mailbox. > > Hm... I'll think about that. I have seen webmail programs (can't > remember which) that lets users specify both the "from" and "reply-to" > fields. It's useful, but also prone to abuse (of course, the header > contains tracable information, but that won't help until after the > fact). It's not too important to have both, but it would be a good option and maybe it's not to complicate to code both things in one pass. I have a bunch more ideas, so what do you prefer: shall I post these ideas in the forum? Or send a mail to you or ilohamail-devel? Christian |
From: Ryo C. <ry...@il...> - 2003-02-03 18:34:38
|
On 2/3/2003, "Christian H.Horchert" <chh...@ve...> wrote: >IMHO there are three main tasks to get mutiple identities to work: The >organisation of the identities data (I suggest to have id, uid, name >and email since it's a 1-to-n-relation), the building of the global and >user prefs and the control structure in addition (or as replacement) of >the $TRUST_USER_ADDRESS. Just tell me what I shall do :) If you would like to work on this, that would be great. I'd like the interface to be in a separate pane in the prefs page (and then there should be a "Show identities" preference in the main preference page -but I'll take care of that part). Since I'll probably be redoing the file-based backend code, if you could implement it for a MySQL backend for now, that would be good. Just make sure the backend code is separated so I can go in and add file-based backend support later one. It's difficult for me to try and explain every detailed spec (after all, I might as well just do it) so I'll let you take a stab at it based on what we've discussed so far, and we'll go from there... If there's anything you're not clear about, though, please feel free to ask. Thanks, Ryo |