Cody
-
Posts
1,574 -
Joined
-
Last visited
-
Days Won
74
Posts posted by Cody
-
-
OK, after further inspection - the files under "support_manager_files" folder are created with different rights than it is set by default. I mean if I use an account X to log into the machine create a file in that directory, it has certain rights inherited from its parent directory - i.e. "support_manager_files" folder. But if Blesta's cron creates the file it has different set of rights and does not inherit its parent folder rights correctly.
Please note this is Windows Server where our Blesta lives.
I have made an experiment:
I have logged into the machine and manually renamed the attachment file stored in "support_manager_files" folder. I have then created a new file with the original name of that attachment file. I have then tried to download the file from the Support Management ticket. It worked perfectly.
Experiment conclusion: If the file is created "normally", it inherits the rights correctly (and this work regardless the user that creates the file "normally") and is readable for all users and Blesta has no problem to work with it and provide its contents to the staff via SM ticket. However, if Blesta creates the file its rights are not inherited correctly and are not readable for all users.
I suspect that there is a code in Blesta that is responsible for creating these file and that it modifies the file rights in certain way.
Could someone point me to that code so I could do further inspection?I assume there is chmod() call, which does the mess on Windows as could be find in many discussions over the web.It sounds like the issue you're having here is that your CRON user does not have the same permissions as your WEBSERVER user. Ensure they have the same permissions to read/write files and you'll be fine.
Blesta does not set any special permissions on files it creates, only directories. It does this to ensure that when writing files to those directories CRON/WEBSERVER users can both use these file interchangeably. However, because Windows is funky with how it manages permissions if the user used to create the directory does not have permission to escalate the permission of that directory to allow other users to access it, it fails. Thus making the directory unwritable by other users (i.e. if CRON creates the directory then WEBSERVER can not write to it, and vice versa).
-
Have you taken a look at how errors are returned in the API docs?
-
Closed as not a bug in Blesta. If you continue to have issues with this please post in the support forum.
As per Tyson's response: http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html
- Bucket name must be a series of one or more labels separated by a period (.), where each label:
- Must start with a lowercase letter or a number
- Must end with a lowercase letter or a number
- Can contain lowercase letters, numbers and dashes
- Bucket name must be a series of one or more labels separated by a period (.), where each label:
-
Would just be nice to see a reminder of some post-install tasks. If someone would accidently leave the install.php file in place, someone might be able to mess everything up.
The install.php file can't be used to mess anything up. If it could, we'd require removing it. I think you're just used to other applications that require you to do that. Blesta is smarter than those applications.
-
I find scrolling results incredibly annoying, especially when looking for things that I know are 10 pages away. I find it much easier to click a pagination link to go to page 10, and look around page 9/10/11 than scroll down and search. But of course, that's just me.
Ditto on this. Especially annoying when my browser crashes because it exhausts too much memory/GPU trying to render all the results.
Dynamic loading is great for finite length pages that you want to load quicker, but for a set of results that could be essentially boundless it makes much less sense.
-
A good idea for a mass update plugin. I'm sure there are other settings users could find useful in mass updating as well.
-
As for HTTP vs HTTPS. I do not agree with you here. This is a bug regardless how a word "bug" is defined. The possibility for an easy fix does not make it non-issue, just lest severe. This is as bug as the "non-standard port bug" because Blesta by default generates invalid links. Invalid links implies bug. All these issues should be treated as bugs and resolved as other bugs. The default templates should just work, the user should not be forced to modify them if she has no need to.
My understanding of Blesta is not good yet, but I would suggest having PORT and SCHEME settings under company settings or something like that.
Setting the protocol in the templates as defaulting to http is not a bug. While we strongly recommend the use of SSL certificates, we can not make that a base requirement for using Blesta. That said, users can enable requiring https in their .htaccess file as explained in the manual, which would seamlessly redirect all non-https requests to their https equivalent. If you feel that users would fail to follow links in their email simply because they are not over https, then you can certainly update the email templates to contain the correct protocol.
Making the protocol for all email templates a company setting is a worthy suggestion, and I would encourage you to post that in the feature request forum.
-
What version of the universal module are you using?
-
Have you tried this: https://github.com/cloudrck/blesta-nginx/ (courtesy of cloudrck)?
-
CORE-795 is fixed for 3.0.4. To patch yourself update /components/email/email.php lines 260-276:
from:
$body_text = null; foreach ($this->message->getChildren() as $child) { if ($child->getContentType() == "text/plain") $body_text = $child->getBody(); } $vars = array_merge($vars, array( 'to_address'=>implode(',', array_keys((array)$this->message->getTo())), 'from_address'=>implode(',', array_keys((array)$this->message->getFrom())), 'from_name'=>implode(',', array_values((array)$this->message->getFrom())), 'cc_address'=>$cc_address, 'subject'=>$this->message->getSubject(), 'body_text'=>($body_text), 'body_html'=>($this->message->getContentType() != 'text/plain' ? $this->message->getBody() : null) ) );to:
$body_text = null; $body_html = null; foreach ($this->message->getChildren() as $child) { if ($child->getContentType() == "text/plain") $body_text = $child->getBody(); } if ($body_text === null) $body_text = $this->message->getBody(); else $body_html = $this->message->getBody(); $vars = array_merge($vars, array( 'to_address'=>implode(',', array_keys((array)$this->message->getTo())), 'from_address'=>implode(',', array_keys((array)$this->message->getFrom())), 'from_name'=>implode(',', array_values((array)$this->message->getFrom())), 'cc_address'=>$cc_address, 'subject'=>$this->message->getSubject(), 'body_text'=>$body_text, 'body_html'=>$body_html ) ); -
-
Logging just fine? Logging without content. We have no HTML emails, all we use is plain text. The HTML tab is empty for all of the templates, there is only content in the Text tab. Also, as I said, it works fine with PHP piping without changing the templates.
In that case,
Include your configuration settings, i.e. OS, version of Blesta, PHP & MySQL.
-
Looks like it's logging just fine, based on your second screenshot. To confirm, check the log_mail table for entries.
I believe the issue you're seeing is that only plain-text versions of emails are displayed in the UI, and it looks like you have no plain-text versions of your emails. Blesta should automatically convert your HTML emails to plain-text when delivered, but if the plain-text email template contains anything (including white space) that would prevent the automatic conversion from taking place.
-
Moved as not a bug.
-
What currency was this for (USD)?
What is the format of the currency (####.##)?
What was different about the first attempt (that failed) and the subsequent attempt? Was the first through an order form while the other was in the client interface, or...?
-
What do you guys think, a pop up window with an HTML invoice and an option there to download the PDF version? Or embed the invoice in the page in the client area?
Wouldn't it make more sense to offer an option under [settings] > [Company] > [billing/Payment] > [invoice Customization] to choose whether or not the invoice should be streamed or force download, since settings don't allow you to offer two different file types for invoices at one time?
-
Hey Paul,
Exported from 3.0. Never had 2.5
As Tyson pointed out, you need to have the same cipher keys in your /config/blesta.php config file as you did in the system you exported from.
Moved to support forum as not a bug.
-
I would find this a nice option. Perhaps it should be done as an option. I hate having multiple PDF files downloaded when I only need to look at an invoice and not actually download a PDF of it. Perhaps an option in settings or a checkbox under view invoice under each client's info that says, view in browser or download pdf.
Don't you get a similar popup to the following when you click to view an invoice?
You can click to open it in Adobe Reader, or if you have a PDF plugin for your browser of choice, you can choose to open it in a browser which would do the same as streaming.
-
There's no mechanism in place to associate custom fields with contacts. Custom fields can only be associated with clients. I don't really have any suggestions on how you might use custom fields for contacts as the database is simply not designed to work that way, and there's currently no event that would allow plugins to associate custom fields with contacts.
If you're modifying the default invoice template you should instead clone it and rename it. Then you should have no problem customizing it as much as you need. -
We want a similar thing in our project. We want accounts and users. A user would be either an end user or company - an entity that have its login credentials, address, can pay invoices. An account would be something that is related to our services. Each account has its administrator and then possibly other users that have access to its resources. The administrator manages which users are associated with his account. Administrator of the account can buy services for the account and these services can be consumed by its users.
This is similar to contact login accounts, which is a feature slated for a future release of Blesta. The database already supports contacts having login (i.e. user) accounts, but the interface doesn't currently have the option to authenticate or restrict access based on permissions. However, the contact-based user authentication system would only permit a contact under a client account access to that client account. It is not planned to support a single contact access to multiple client accounts (though the database does support such a thing).
Now the question is how to implement this with Blesta.
1) We could implement our own system of accounts and users without Blesta and then pair our users with Blesta users. This should be definitely possible, but obviously this has disadventage of having two separate interfaces that our customer would have to switch between.
2) We could implement this to Blesta. Is this possible? Is it possible without chaning the core (i.e. only implement some kind of extension/module/plugin)?
What would be the best way to do that? Are there any existing extensions for more complex account structure already? Or can Blesta do that on its own without modifications?
Thanks a lot!
Depending on the access you want these users to have on client accounts, you could do this with a simple authentication plugin. You'd create a plugin with a login form that would authenticate against Blesta's users system, and initialize the appropriate session values to permit the user access to a client's account. If you wanted to allow the user to swtich between client accounts you'd need to create a page in your plugin to allow them to select a different client account to migrate to (by updating their session with the appropriate client ID).
If you only wanted to grant access to certain areas you'd have to implement an Appcontroller.preAction event handler and evaluate each URI to ensure the user can access it based upon your plugin's own custom permissions.
-
The paid stamp is already available.
PDFs streamed to browsers are not supported by all major browsers on all major operating systems. Some browsers fallback to forcing download, while others do nothing but show a blank white page. The only way to ensure 100% delivery is to force download as Blesta does.
If Blesta did allow streaming we would undoubtably be inundated with misdirected bug reports. If there was an option to enable streaming it would have to be done in such a way that the user is aware of the incompatibility issues that will arise.
-
If you have phpMyAdmin you can import the .sql or .gzip file directly. If not, you can import by running the mysql command.
-
I am able to get it to communicate with the server when I have this as the HTTP code: HTTP/1.1 200 OK
The HTTP code you enter in Blesta should only be a number.
However I'm getting a 400 HTTP code back from the server (bad request.) It looks like it may be because Blesta is using post instead of POST. Does anyone have any insight into this?
x.x.x.x - - [28/Sep/2013:11:56:23 -0500] "post /manage/index.php HTTP/1.1" 400 166 "-" "-"
I don't think that's the issue. Without knowing the API requirements for that particular resource I can't really say what the problem is (a 400 response is vague). It could be that something else that's posted along with the request is throwing it off.
As a sort of work around, if necessary, you could have the universal module post to a script you create to capture the data and pass along only the variables the API requires using curl, for example.
-
Looks like you've just about got it, though the variables are not available in the URL (but that's an awesome idea). They'll automatically be sent via POST, however.
From your curl request you've specified both parameters to be sent via POST. To set rank as a variable configure it as a Secret or Hidden type, and specify it's value as VIP.
Most HTTP requests respond with a 200 response code. If a 200 response indicates success for that URL enter 200 as the HTTP Code. If, instead, the URL responds with some string that contains "success" or something similar, set that string in the Response Contains field.
Support Manager Ticket Created From Received Email With Attachment
in Support
Posted
How your Windows users are configured is beyond the control and scope of Blesta, and thus not a bug with Blesta.