dait

I went through PayPal's settings and could not find anything wrong there. Our business name is correctly filled in, so could you please check whether it is possible to change that appearance of the email to a company name? Most importantly in that "Return to XYZ" link because it really does not make sense to return to an email address.

To summarize this up - I am OK with what you wrote. I will give it a shot once more. I will do my best to overcome all of the obstacles, but I hope that in case I find this too difficult (for whatever reason - too many issues, lack of support, different points of view on security/bugs related definitions such as not accepting "if something does not work with defaults it is a bug", whatever) for me that you will not refuse to issue a refund to me. There are quite many opened issues where I now wait for your answers and how do you handle them will tell me whether I can go with Blesta in long term or not. So, let's work on it.

Now interesting is that Blesta sends email to the client and I believe it was just after step 5). This email is Invoice Due email. What is even more interesting that this email contains Pay Now (No login required) link and if that is clicked: 10) After clicking Pay Now in email: 11) Click PayPal Payments Standard and then REVIEW AND CONFIRM 12) Here I am not sure why there is Subscribe button. I am quite sure that my package was One Time payment only, no subscription allowed, so I think this might be a bug. I know that I have this "One time and subscription payments when possible" enabled under Manage PayPal Payments Standard in Company's settings, but the package does not allow subscriptions, so this should not be displayed, right? Anyway, I clicked the PayPal image on the right. 13) I like this page much more! You can see that there is an invoice number as an item name and the user does not enter this on himself. This is good! OK, so filled Email and PayPal password and clicked Log In. 14) Click Pay Now 15) Hey, there is Return to <email>! Except that I do not like that there is that email, I would rather see a project name or company name there, but maybe this is just problem of my PayPal account settings, I do not know this yet. It does not really make sense to return to an email, right? Anyway, if that Return to <email> link is clicked ... 16) OK, wait 10 secs. 17) Excellent, we are back. That is exactly what I was talking about. So, this works +- OK if we use Pay Now button. There is probably a bug that Subscribe button is displayed and I do not like the email address displayed (but again, this might be just my settings), but otherwise OK. I would like this to have this behavior in common order form so that client is not required to use Pay Now. Actually I am quite sure that the client paid for this invoice twice. I like that item name is filled with invoice number and I like there is a way back to the client area. There is no such thing if we go through the order form. But the main problem remains - even after payment with Pay Now button, Blesta did not recognize that the invoice has been paid. I have that @hotmail.cz in PayPal Account Email in Manage PayPal Payments Standard in settings, I have disabled Allow users to modify current and create new subscriptions, I have empty Page Style Name (I don't know what this is yet), I have filled in API Username, API Password and API Signature and I have enabled Developer Mode. I have 3 currencies selected including USD.

Sorry I have to divide this post to multiple parts because it is said to contain too much images ... Thank you. Our Module log is empty. I have now closed all support tickets, cleared all invoices and started again. Here is step-by-step 1) Order page 2) Click SELECT 3) Click CONTINUE 4) Click CHECKOUT 5) Click PayPal Payments Standard, click I have read and agree..., click CONTINUE 6) Click PayPal image 7) enter SOMETHING into name, fill in Email and PayPal password, click Log In 8) Click Pay Now 9) And now what? If I click Go to PayPal account, it goes to the paypal account, but I would like the user to be sent back. The payment is done if we check the paypal account.

I've been discussing this topic a little bit with Paul over support tickets. The thing is that we need invoices to be completely different from what Blesta is capable to generate right now. We are in EU and the regulations here are quite extreme, the requirements for invoices are insane, but there is nothing we can do about it. So, we have to completely change our invoices that are generated in Blesta. How do we do that? I would like to ask you for a help with following topics and please assume that we know nothing about Blesta and we have no experience with creating any kind of extensions for it: 1) Where do we start? What do we want? I think we want some kind of extension (but which one?). 2) What should we read (which part of the documentation)? Which functions are related to creating invoices. 3) How do we connect our extension to Blesta - i.e. how do we replace the current invoicing system with the new one? I decided to go this way because requesting such a feature from the devs would be very demanding. Understanding what is needed in our country on invoices is hard and explaining that would take so much time that I think we will faster create such an extension ourselves. But this holds only if we receive good support here. We need to understand the process of creating new Blesta extensions from the very beginning. Kindly asking for as much information as possible on this topic. I expect to be asking more question during the process. Thanks!

I would like to request a feature that is related to a topic discussed here: http://www.blesta.com/forums/index.php?/topic/1052-system-status-there-are-one-or-more-cron-tasks-that-have-been-executing-for-more-than-60-minutes/ The current cron log contains very little information (task started, task finished). But if something bad happens, which could mean that some unusual condition was not handled properly (and this actually should be fixed to prevent cron task crashing), we have no information on what happened. Cron debug log would be handy here and could help us trace the causes of such events. The more information the better, so I can imagine two levels of logging, one enabled all the time, the second one enabled on demand, if we know that something goes wrong and need further information. Thanks for considering.

I have received this message today. My case is about Support Manager's plugin that checks IMAP for new tickets. The odd thing is that it stopped working in the middle of the night (it is 7:20 AM here and it is reported that it failed at 3:30 AM). My understanding is that this has something to do with unhandled exeption conditions or unhandled error states so that CRON task never finishes. It would be nice to have more info from Blesta in some kind of debug log - what exactly happened and why. In other words, I agree with EmptyMind.

I see. When I reply to an email in my email client. There is always this line that introduces the quoted part. For example to emails from your forum it is "Blesta Community Forums wrote:" The obvious problem here is that if user does not use English localization to work with then the text is completely different. Gmail for example puts this there 2013/10/4 Name <mail@domain.com> However, seznam.cz goes differently, it puts this line in front of the old content ---------- Původní zpráva ---------- and does not quote the old content at all. I looked at some of my services for which I communicate with support using emails and ticket system. One solution is that they keep whole conversation intact (then don't remove a thing). And this is works perfectly for emails because when I reply to that incoming email from my email (and not online ticket system interface), I do see whole conversation history, which is good. They also use "do not reply below this line" and they have this there probably to help them parse the message before it is put into the ticket system. In their ticket system each reply has only its text and not the history. This works very well and I would be happy to see this in Blesta. A typical email from their support looks like this: New message (number 4) from Name2 person. ---------------------- Name1 on Date ------------------------ message3 body3 ---------------------- Name2 on Date ------------------------ message2 body2 ---------------------- Name1 on Date ------------------------ message1 body1 So, my vote for - using "Reply above this line" or "Do not reply below this line" (but you will still have to deal with the first line above that line, that "XYZ wrote" line) - saving only the actual message, not full history to ticket system (Blesta does this now) - sending whole history via email (or possibly some limited history, like last 10 posts or something configurable)

Hi Paul, you could see in my history of posts here that the number of issues I am reporting is quite big. I am just trying to turn Blesta on our machine to a usable piece of software. The reason why I chose Blesta was the open source code that I must say is written in a good code style and I find it easy to read. I am just unhappy that the current quality is on the level of a freeware solution and that I paid a bunch of bucks for it. But I can live with that if we can cooperate together and move Blesta on another level. For this, however, I really need positive thinking, fast reactions and a little trust. I do not need "this is not a bug" under half of my posts. I need you to agree that if something does not work in its defaults, it is a bug. There are very few exceptions to this and all such configurations have to be part of the installation process. I can not handle three things: 1) I do not want to create and manage my own version of Blesta that would be better than the official version just because we do not agree on what is and what is not a bug. 2) I do not want to spend whole days debugging Blesta on things that I reported days ago and just no one replied. 3) Wait several days for support tickets to be answered. I am not sure whether I should write things here on there, but either way, I do not want to way. I need something in production in less than 2 months. If we can not agree on these crucial things then OK, please refund my license and good luck with your software.

I have analyzed the issue for you, describe the problem to its very detail so you could just take the code and fix the bug. I would expect a little thank you, but instead you just twist the whole issue into something else. How should I be happy about it? You have not explained this: If a new user installs Blesta on Windows, he would have the default temporary directory there as Basic Settings Temp Directory. And it would not work. This is a bug on itself. Your solution does nothing about it. What you are doing here is creating glitches that your users will fall into. If you think this is a right way to go then please just confirm and we are done here. There is no point to discuss anything further. In such a case you do not care about your users, you do not want to create a glitch-free software that would just work. You would be creating something that would be hard to setup on production machine. I believe you that you have a testing Windows machine with WAMP. I do not believe that you run Blesta on Windows in production environment. I do not say this to offend you. I just know that your solution to this problem is not a real solution. You are probably a good Linux developer and you know something little about Windows and you are capable to work with Windows on a certain level. But from your comments it seems that your experience is not on the level it is required here. And I offered you a help with this. It is up to you how whether you want to accept this offer or not. If not, just tell me, OK? I will back off and ask you for a refund for my Blesta license and will move to another provider.

Please Google something about upload_tmp_dir, why does it exist and what are its problems on Windows. Just think about why upload_tmp_dir even exists? Why someone introduced it to PHP? It is there and you just need to use it, why you refuse to do that? There is no reason not to use upload_tmp_dir. Why is it called upload_tmp_dir? Why not just tmp_dir if it was the same?! But if you think the default rights of Windows default temporary directory should be manipulated then the whole discussion is pointless. I can't see why you keep persisting on your UNIX/Linux based point of view when we are talking about Windows!?

Thank you for accepting. However, [settings] > [system] > [General] > [basic Setup] does only allows you to set up temp directory and upload directory and neither should be used for this purpose. What we are talking about here is temp upload directory as I described in my post. If you change it to Temp Directory from [basic Setup] the bug will still be there because for most actions the default temporary directory is just good to be used (for things like create a temp file, do something with it and delete it). It is just unsuitable for actions where you want to move the file somewhere else. So I suggest to reconsider your fix as it would not fix anything. It should be OK to left [basic Setup] Temp Directory with the default value which is the default temporary directory. You have this hint - if your solution does not work with the default values, it is probably not good. And you will put all your Windows users to troubles if you do it that way. There is really no why not to use what PHP offers you here - upload_tmp_dir. If you want to allow users to have it changeable, OK, create a new setting under [basic Setup], but please do not mix it with Temp Directory. That is something else.

OK, so let's fix another bug in Blesta ourselves .. yeah \*/ In this case the problem goes as follows. When email arrives cron task detects that and ticket manager calls processTicketFromEmail. Email is being parsed in plugins\support_manager\components\email_parser\email_parser.php. In here, things fail. Let's see how for example getSubject fails: public function getSubject(MimeMailParser $email) { $charset = $this->getCharset($email->getHeader('content-type')); if (!$charset) $charset = "UTF-8"; $subject = $email->getHeader('subject'); // Convert to UTF-8 if needed if (strtoupper($charset) != "UTF-8") $subject = $this->convertEncoding($subject, $charset, "UTF-8"); return $subject; } Somehow the value in $charset is "UTF-8", this may seem OK, but the code really expect it to be just UTF-8, not "UTF-8". I really mean that if we wanted to put that value in $charset we would have to call $charset='"UTF-8"'; So obviously "UTF-8" != '"UTF-"' and so we call convertEncoding which fails. But it fails softly so that the result is empty string. Now, why on Earth do we have "UTF-8" in $charset instead of just UTF-8? The core of all evil is this piece of code in email_parser.php: public function getCharset($content_type) { $charset = null; preg_match("/charset=(.*);|charset=(.*)$/i", $content_type, $matches); if (isset($matches[1]) && $matches[1] != "") $charset = trim($matches[1]); elseif (isset($matches[2]) && $matches[2] != "") $charset = trim($matches[2]); return $charset; } In our case the relevant part of the email (sent by SeaMonkey) is this: Content-Type: text/plain; charset = "UTF-8" It should be noted that parsing code should recognize all following formats charset = something charset=something charset= something charset =something charset = "something" charset="something" charset ="something" charset= "something" charset = 'something' charset='something' charset ='something' charset= 'something' and possibly also things like charset=' something ' charset=" something " I believe that that code is able to parse only the first four samples, which means that lots of emails sent to Blesta goes into trash (or become "Ghost tickets" if you like). Either there should be better "trimming" part which would remove both double and single quotes if they are present within the value of charset, OR there should be more complex regular expression that would make this automatically. For a quick test that this function is the cause of the problem I have used the second parameter of trim() function and included ' and " (besides the default) characters in it. Tested with a couple of emails sent from SeaMonkey, all of them appeared correctly in the ticket system.

So, anyone interested in fixing this Ghost tickets issue?

OK, I've got it. As I mentioned previously, my previous claims were not verified, they were just guesses. I have to admit that my guess was wrong. chmod() was not the cause. Although I found a bunch of evidence that using chmod() on Windows does not do what you expect it to do and actually can harm access rights inheritance, these issues are related to using chmod() on folders only. There are no reported issues with chmod()ing files on Windows. I have verified that chmod() is not the cause by removing the only chmod() in Blesta's code and indeed, it did not help. X:\blesta\up\1>icacls support_manager_files support_manager_files SRV\WWW User Group:(I)(OI)(CI)(M) SRV\Web Server User:(I)(F) CREATOR OWNER:(I)(OI)(CI)(IO)(F) NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F) BUILTIN\Administrators:(I)(OI)(CI)(F) BUILTIN\Users:(I)(CI)(S,WD) BUILTIN\Users:(I)(CI)(S,AD) BUILTIN\Users:(I)(OI)(CI)(RX) Successfully processed 1 files; Failed processing 0 files X:\blesta\up\1\support_manager_files>icacls "20131006T093011+0000_b4f5b5c6fdc628a143089a0e42aee5a7.txt" 20131006T093011+0000_b4f5b5c6fdc628a143089a0e42aee5a7.txt NT AUTHORITY\SYSTEM:(F) BUILTIN\Administrators:(F) SRV\Cron User:(F) Successfully processed 1 files; Failed processing 0 files X:\blesta\up\1\support_manager_files>icacls x.txt x.txt SRV\WWW User Group:(I)(M) BUILTIN\Administrators:(I)(F) NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Users:(I)(RX) Successfully processed 1 files; Failed processing 0 files What is going on here? "icacls.exe" is a program to work with ACL from command line on Windows. If you run "icacls.exe file" or "icacls.exe directory" it will just display the access rights that the file or the directory have. OK? That "2013100*.txt" file is the one created by Blesta. The x.txt file is created by me manually. Both were created under support_manager_files folder. What is important here? The important thing here is the difference of their access rights. You can see a bunch of inherited (I) access rights that x.txt has. Why? Because the file was created normally and no one manipulated that rights. So this file was created in a directory which does use access rights inheritance feature and so it inherited those rights. Most importantly, the BUILTIN\Users read+execute right has been inherited. Now please take a look at "2013100*.txt" file. What are its rights? The inheritance was revoked and only SYSTEM and Adminastrators have full rights + the creator user Cron User. But this means that no other user in the system is able to touch the file, read its contents or do anything with it. FTP users with full access to X:\blesta folder can not download this file. If Cron User != Web Server User (as it should not), then Web Server User can not touch the file. This is a problem, this is the bug. But what is the cause? Took me a while but I found it and managed to fix it. This actually pointed me to the right way during my analysis - see Dan Danley's comment in the discussion here - http://php.net/manual/en/function.move-uploaded-file.php There is a known issue with PHP and files uploaded to PHP on Windows systems. In case the server has no value for upload_tmp_dir set in php.ini, uploaded files are created within the default temporary directory of the user that PHP (web server in our case) runs under. The well known problem here is that this default temporary directory is not suitable for file uploads. More correctly, the access rights of files under the default temporary directory are crippled in the way we can see in case of that "2013100*.txt" file. In other words, files created in default TEMP on Windows do not inherit access rights. This is not a bug or mistake in default Windows behavior, this is an intention and it should not be manipulated, it should be kept the way it is. Files created in default TEMP are not intended to be moved to other folders. But this is what is commonly done with uploaded files. This is exactly why PHP on Windows should have upload_tmp_dir defined and set to a directory that is not within the reach of your web presentation and also is not the default TEMP directory. You should create a new folder for this. If you configure upload_tmp_dir properly, your uploaded files will be created there and the file rights will be just OK even if you move the file to another directory, which is what you commonly do. OK, so where is the problem now? The problem is that we do have upload_tmp_dir set in php.ini properly. It is just Blesta that ignores it. Here is the responsible function from plugins\support_manager\components\email_parser\email_parser.php: public function getAttachments(MimeMailParser $email) { $files = array(); $tmp_dir = "/tmp"; if (function_exists("sys_get_temp_dir")) $tmp_dir = sys_get_temp_dir(); foreach ($email->getAttachments() as $attachment) { ... SOLUTION: I have rewritten this code to this: public function getAttachments(MimeMailParser $email) { $files = array(); $tmp_dir = "/tmp"; $sgt_dir = function_exists("sys_get_temp_dir") ? sys_get_temp_dir() : $tmp_dir; $upl_dir = function_exists("ini_get") ? ini_get("upload_tmp_dir") : $sgt_dir; $tmp_dir = $upl_dir ? $upl_dir : $sgt_dir; foreach ($email->getAttachments() as $attachment) { In other words, the original Blesta code goes to temporary directory. My code goes to upload_tmp_dir, which is the folder that should be used for uploads and similar operations. Blesta in its components\upload\upload.php has this code: if ($this->uploaded_files) $result = move_uploaded_file($index !== null ? $file['tmp_name'][$index] : $file['tmp_name'], $this->upload_path . $new_file_name); else $result = rename($index !== null ? $file['tmp_name'][$index] : $file['tmp_name'], $this->upload_path . $new_file_name); In case of file being downloaded from IMAP, it is the rename() function that is called to move the file from the temporary directory to "1\support_manager_files" folder. If there was copy + delete, it would work. rename() just moves (renames) existing file and its rights are intact, hence if they are wrong (because the file was created in the default temporary directory) then will be wrong after renaming too. So, this has nothing to do with Cron and Web users, nothing to do with chmod(), this is about using the default temporary directory for the purpose for which it should not be used. Finally, we have the result of a new attachment that was processed after the SOLUTION was applied to our Blesta 3.0.4: X:\blesta\up\1\support_manager_files>icacls "20131008T095510+0000_94e4df435b1b2d6e0b34ba10faf0a0c2._txt" 20131008T095510+0000_94e4df435b1b2d6e0b34ba10faf0a0c2._txt SRV\Web Server User:(I)(M) SRV\WWW User Group:(I)(RX) SRV\Web Server User:(I)(F) NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Administrators:(I)(F) BUILTIN\Users:(I)(RX) Successfully processed 1 files; Failed processing 0 files Beautiful, right? Perfectly correct access rights. I hope that this evidence is enough for you to admit this is a bug in Blesta. Feel free to use my patch, free of charge, free to use license for whatever purpose forever. Windows rights are not funky, they just work on different principles than UNIX/Linux. I admit that understanding of Windows rights and principles might be crucial for understanding of what I am talking about here, but PLEASE at least try if you are not familiar with Windows. Also, please note that you use sys_get_temp_dir (and e.g. store it to temp_dir value, which is used on many many places) function on other places in Blesta's code. I highly suggest that you check all places in the code in which this default temporary directory from sys_get_temp_dir is used. If in any case you create a file there and then move it (rename) somewhere else then this is likely to cause similar problem again.

I am not sure if this is a fault of my settings or whether this is a bug or whether this is caused by the fact that I am testing PayPal in testing mode - i.e. PayPal Sandbox. There are three issues I have: 1) When a user orders a packages and pays with "PayPal Payments Standard" in Test Mode, Blesta did not recognized the payment was made, the Invoice is put to "Past Due" and it is just not finished, the user keeps getting those "Invoice Due" emails. 2) When the payment was done, the user was not taken back to Blesta Client area, but remained on the PayPal page. This actually happened to me when I paid for Blesta's license, so I assume this is an issue even in production environment. I am not sure whether there PayPal API supports this (but I would be very surprised if it does not), but if yes, I think it should be implemented and if not then it might be a good idea to change the anchor's "target" attribute of that PayPal button to "_blank" so that Blesta page keeps existing in the user's browser and it then it would be great if Blesta detected the payment user just made and refreshed that page after that to something that makes sense in the particular context - "Thank you for your purchase" or something like this. 3) When the PayPal payment web page is loaded after clicking the payment button from the Blesta's order page, the user is allowed to enter the name of the item (This also happended to me when I paid for Blesta's licence). I would rather want to have the name of the item fixed by the package/product creator, not by the client. Could any of these issues be mitigated using some kind of settings I have missed?

The result now is that the HTML page contains: <link href="/plugins/order/views/templates\standard/css/order.css" rel="stylesheet" type="text/css" /> </head> Please compare with the original state: <link href="/plugins\order\views/templates\standard/css/order.css" rel="stylesheet" type="text/css" /> You can clearly see, the new result IS BETTER, but not fixed - Firefox still displays the page poorly. Invalid slashing is still there in the "$this->view->view". This leads us to a final solution - moving that closing bracket even further to the left. From your suggested code: "<link href=\"" . Router::makeURI(str_replace("index.php/", "", WEBDIR) . $this->view->view_path) . "views/" . $this->view->view . "/css/order.css\" rel=\"stylesheet\" type=\"text/css\" />" to final version: "<link href=\"" . Router::makeURI(str_replace("index.php/", "", WEBDIR) . $this->view->view_path . "views/" . $this->view->view) . "/css/order.css\" rel=\"stylesheet\" type=\"text/css\" />" This final code generates: <link href="/plugins/order/views/templates/standard/css/order.css" rel="stylesheet" type="text/css" /> </head> which is correct. Cody: Please update your newly suggested code so that the closing bracket is put after $this->view->view instead of just after $this->view->view_path. There were two back slashes in the originally created HTML code, we have to fix both of them.

Thank you, will do and will report back.

checking

By default Blesta contains email templates that do not respect HTTPS if it is used. This issue has been discussed in the following thread: http://www.blesta.com/forums/index.php?/topic/1173-links-in-support-manager-emails-do-not-respect-https-mailto-problem/ It would be nice if Blesta offers this as some kind of setting - possibly a single company setting for all templates as the title suggests.

The suggestion on having it as a feature request is fair enough: http://www.blesta.com/forums/index.php?/topic/1188-making-the-protocol-for-all-email-templates-a-company-setting/ Thanks.

OK, here are solutions for those who are interested. Please note that mentioned reasons are my best guess, I have not verified all my claims properly, I am just happy that it works and I want to move on: 1) ideal problem resolution Blesta should not use chmod() on files on Windows, because it does not do what you expect. It breaks the access rights inheritance on Windows. 2) non-ideal problem resolution Do not use CLI for CRON on Windows. It is a good security practice to run Web server under a user that can not log in on the machine, the user is just used for running the web service and is very limited. This is why if you use this security practice your CRON task should not be able to run under that user. Unfortunately, using another account for CRON task here does not work since Blesta uses chmod() function which corrupts access rights inheritance, which is described in my previous post. So, instead I suggest you to avoid running CLI for CRON and actually run e.g. wget to access your CRON page so that web server takes care of it. Why is 2) non-ideal? Regardless whether you use CLI under the web server user or you avoid CLI and run it through wget, the files created by Blesta have obscure access rights. No other users will be able to access those files. If you have users for e.g. FTP that does have access to these folders, those users would not be able to access those unless they are under Administrators group. This violates ACL hierarchy that one designed on his server and thus should be considered as a bug. Edit: The correct solution of this is completely different. See below.

Evaske: Are you a Windows user of Blesta? Anyway, please check my recent posts here on this forum. At least two of them seem to me to be related to Windows platform - slashing problem and file rights not inherited problem.

No problem, we have some time. We have bought and installed Blesta 4-6 weeks before we actually need it in the production environment, so I can handle reasonable delays. What I am looking for in this topic is step-by-step tutorial how to make Blesta working on Windows Server. By "working" I mean production level quality of features such as ticketing system, order forms, invoices and a like. And it would be nice if the tips respect the architecture and nature of Windows (especially concerned about security here). But even nicer would be if Blesta could run on Windows by default without hacks and tweaks.

I am starting to get a little desperate. From the very first moments after the installation, we literally run into one problem after another. And it starts to be clear that it is because we run Blesta on Windows Server. I would be very happy if someone here could confirm that they run Blesta on Windows and managed to make it working flawlessly. If such a person exist and is willing to help, please respond here. Our configuration is Windows Server 2008 R2 Datacenter Blesta 3.0.3 PHP Version 5.4.10 MySQL 5.5.29 Apache 2 with API version 20120211