when i set the vacation and i type a body with a newline is show oke on de display but in de database it stores a
/r/n ( slash r and slash n ) for every newline.
if go in vacation again it also shows it now.
when i change the mesage with phpmyadmin it show correct again in vacation.
the same is so for the supject field
testing it on svn 1137
Regards Jan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In other words: remove the escape_string() calls in edit-vacation. The only exception is the SELECT query - you'll have to use escape_string($fUsername) for it (or better use $vh->get_details() ).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Christian,
I have a few questions regarding the vacationsettings.
Question 1:
Is it a conscious choice that the user returns to its main menu. And that the administration remains in the window where he can adjust the vacation notice until he cancel the window. Or is this traditionally come about.
Question 2:
I have test several Senario with edit-vacation, both with vh-get_detail() As with removing esscape_rting(t$body) but I still at the /r/n stored. Even though I use the original template and edit-vacation.php of svn 1137. I have no problem if I use the user-vacation. Do you have this problem or it may be a browser problem i a using a mac.
Question 3:
what do you think about putting variable into the body whith will be replayed.
by example <$dateform> with activeform and <$dateunitl> with activeuntil.
Regards, Jan Kruis
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Q 1: traditional behaviour ;-) Redirecting the admin to list-virtual after editing vacation settings is probably a good idea. Bonus points if you add a flash_info with a success message(hint: users/vacation does this) ;-)
Q 2: I just replaced all "escape_string" with "trim" in edit-vacation.php (quick and dirty to save time - trim shouldn't do any relevant changes) and get the correct behaviour regarding escaping (no additional \ added). I'd guess you have overlooked an escape_string somewhere. (Warning: my quick and dirty way is dangerous as long as you have the SELECT query.)
Maybe you just have an old/broken database entry with too much escaping - that won't go away magically. Edit the vacation message (remove all backslashes), store it and then check again.
Q 3: It's a good idea, but the implementation is more difficult then you might think ;-)
It is quite easy when someone enables vacation for the first time - in these cases you have the <date> placeholders. However, we store the vacation message for future use (even after disabling vacation), which means you'll have a text like "I'm away from 2011-07-30 till 2011-08-10". Finding and replacing the date in this text might become difficult…
We might be able to handle it in another way: store "_DATEFROM_" and "_DATEUNTIL_ in the vacation message and let vacation.pl replace it based on the activation dates. Unfortunately this opens another can of worms - vacation.pl would need to be aware of the date format to use (30.7.2011 vs. 7/30/2011 vs. …).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
when i set the vacation and i type a body with a newline is show oke on de display but in de database it stores a
/r/n ( slash r and slash n ) for every newline.
if go in vacation again it also shows it now.
when i change the mesage with phpmyadmin it show correct again in vacation.
the same is so for the supject field
testing it on svn 1137
Regards Jan
See what I wrote about escape_string in https://sourceforge.net/projects/postfixadmin/forums/forum/676076/topic/4626822 - basically the texts are escaped twice, which causes the behaviour you describe.
In other words: remove the escape_string() calls in edit-vacation. The only exception is the SELECT query - you'll have to use escape_string($fUsername) for it (or better use $vh->get_details() ).
Hi Christian,
I have a few questions regarding the vacationsettings.
Question 1:
Is it a conscious choice that the user returns to its main menu. And that the administration remains in the window where he can adjust the vacation notice until he cancel the window. Or is this traditionally come about.
Question 2:
I have test several Senario with edit-vacation, both with vh-get_detail() As with removing esscape_rting(t$body) but I still at the /r/n stored. Even though I use the original template and edit-vacation.php of svn 1137. I have no problem if I use the user-vacation. Do you have this problem or it may be a browser problem i a using a mac.
Question 3:
what do you think about putting variable into the body whith will be replayed.
by example <$dateform> with activeform and <$dateunitl> with activeuntil.
Regards, Jan Kruis
Q 1: traditional behaviour ;-) Redirecting the admin to list-virtual after editing vacation settings is probably a good idea. Bonus points if you add a flash_info with a success message(hint: users/vacation does this) ;-)
Q 2: I just replaced all "escape_string" with "trim" in edit-vacation.php (quick and dirty to save time - trim shouldn't do any relevant changes) and get the correct behaviour regarding escaping (no additional \ added). I'd guess you have overlooked an escape_string somewhere. (Warning: my quick and dirty way is dangerous as long as you have the SELECT query.)
Maybe you just have an old/broken database entry with too much escaping - that won't go away magically. Edit the vacation message (remove all backslashes), store it and then check again.
Q 3: It's a good idea, but the implementation is more difficult then you might think ;-)
It is quite easy when someone enables vacation for the first time - in these cases you have the <date> placeholders. However, we store the vacation message for future use (even after disabling vacation), which means you'll have a text like "I'm away from 2011-07-30 till 2011-08-10". Finding and replacing the date in this text might become difficult…
We might be able to handle it in another way: store "_DATEFROM_" and "_DATEUNTIL_ in the vacation message and let vacation.pl replace it based on the activation dates. Unfortunately this opens another can of worms - vacation.pl would need to be aware of the date format to use (30.7.2011 vs. 7/30/2011 vs. …).
Is it an idea to store two body into database.
one to a display and one for vacatipn.pl to use to send email.
jan kruis