Leaderboard

Only customers who have the restricted package set. Linking directly to a package that isn't on an order form, or which is restricted isn't currently supported. It may be a good idea to be able to link to order specific packages without them having to be on a particular order form, restricted or not.

This has been resolved for beta 2.

Closing as not a bug.

CORE-1402. Fixed for 3.3.0-b2.

Just to say Thanks to naja7host and cody for all the help We have since this morning optimise all our plugins for Blesta 3.3 now with the new Events is more easier Here is a working sample of what we did in our Blesta Live Chat Plugin: /** * Execute evet on Appcontroller.structure */ public function getEvents() { return array( array( 'event' => "Appcontroller.structure", 'callback' => array("this", "addCode") ) // Add multiple events here ); } /** * On Appcontroller.structure run this */ public function addCode($event) { // Fetch current return val $result = $event->getReturnVal(); $params = $event->getParams(); // Set return val if not set if (!isset($result['body_end'])) $result['body_end'] = null; // Set return val if not set if (!isset($result['head'])) $result['head'] = null; // Update return val -- ONLY set if client portal if ($params['portal'] == "admin") $result['body_end'] .= $this->liveChatAdminInclude(); $result['head'] .= ' <style type="text/css"> <!-- .bchat_badge { top: -8px; font-size: 10px; font-weight: 700; float: none !important; position: relative; padding: 2px 5px 3px 5px;color: #fff; background-image: linear-gradient(#fa3c45, #dc0d17); background-image: -webkit-gradient(linear, center top, center bottom, from(#fa3c45), to(#dc0d17)); background-image: -webkit-linear-gradient(#fa3c45, #dc0d17); -webkit-box-shadow: 0 1px 1px rgba(0, 0, 0, .7); box-shadow: 0px 1px 1px rgba(0,0,0,0.7); text-shadow: 0px -1px 0px rgba(0,0,0,0.4); -webkit-border-radius: 10px; -moz-border-radius: 10px;border-radius: 10px; } --> </style> '; if ($params['portal'] == "client") $result['body_end'] .= $this->liveChatClientInclude(); // Update return val $event->setReturnVal($result); } /** * On Appcontroller.structure add the code to Admin Side */ public function liveChatAdminInclude() { //print_r($GLOBALS); $nick = new Record(); $nick = $nick->select(array("first_name","last_name"))->from("staff")->where("user_id", "=", $GLOBALS['_SESSION']['blesta_staff_id'])->fetch(); $nick = $nick->{"first_name"}." ".$nick->{"last_name"}; $blc_include = file_get_contents(PLUGINDIR . DS . "live_chat" . DS . "views" . DS . "default" . DS . "admin_live_chat_include.pdt"); $blc_include = str_replace("{{base_web}}", WEBDIR.Configure::get("Route.admin")."/", $blc_include); $blc_include = str_replace("{{nick}}", $nick, $blc_include); return $blc_include; } /** * On Appcontroller.structure add the code to Client Side */ public function liveChatClientInclude() { $blc_include = file_get_contents(PLUGINDIR . DS . "live_chat" . DS . "views" . DS . "default" . DS . "client_live_chat_include.pdt"); $blc_include = str_replace("{{base_uri}}", WEBDIR, $blc_include); return $blc_include; }

Looks like you're blocking POST requests from PayPal's IPN, given that the POST data is empty: "a:0:{}" This could be one of two things: You have PHPIDS plugin enabled and it thinks PayPal's IPNs are attacks -- check your PHPIDS log, adjust settings as necessary, OR Your server is misconfigured and is not allowing POST data from PayPal's IPN service.

base_uri is defined in AppController, so it's only available to controllers that extend AppController. Plugin classes are not controllers, so they don't have this variable set. Use WEBDIR constant to give you the installation path, and Configure::get("Route.admin") or Configure::get("Route.client") to give you the rest of the URI.

Virtualizor update:

back again , yes is working now , i get it working for me yesterday withthe same condition , and ihave already told this toPAulov in my post #12 , but i don't know how i have chende this and it stop working . Another Question if possible ; how we can make $this->Base_Uri , $this->view_dir inside the myplugin_plugin.php ? answer this and go to sleep

See my updated post.

You're using the params wrong for this event.

Hello Cody yes, but the probleme is what i have and PauloV also . we can't specify wich side the output shoud returned (client/admin) now all returned data shown in client/admin side both . theQuestion now is howto display just in client or admin side

Didn't I post how to use this event in another thread? <?php class MyPluginPlugin extends Plugin { ... public function getEvents() { return array( array( 'event' => "Appcontroller.structure", 'callback' => array("this", "run") ) // Add multiple events here ); } public function run($event) { // Fetch current return val $result = $event->getReturnVal(); $params = $event->getParams(); // Set return val if not set if (!isset($result['body_start'])) $result['body_start'] = null; // Update return val -- ONLY set if client portal if ($params['portal'] == "client") $result['body_start'] .= "<p>your HTML goes here</p>"; // Update return val $event->setReturnVal($result); } } ?> See Plugin Events. Creating Events.

normally the cookies is created in pc visitor . not in blesta installation folder .

you can replcae $loggd_id var with $this->staff_id $this->staff_id = $this->Session->read("blesta_staff_id"); about $this->base_uri is returning anydata ? print_r($this->base_uri);

CORE-718 will allow for customers to order restricted packages, that exist on an order form, if they are logged in. Basically, any restricted packages on an order form would be hidden for most users. If the user is logged in, then they would see the restricted packages for which they have access. Not done yet, and the task in Private, not sure why though.

Step 4 is only necessary if the client didn't pay through the order form, and instead sent you a manual payment. The only steps you really need to be aware of as an admin is #2, 3, and 5. That process is necessary when you require manual review of all orders. I think it makes sense that if you "require manual review of all orders" that you manually review the order before you activate the service. This has been brought up before, but it seems as though you're getting ahead of yourself, or forgetting that the orders require manual review. In any case, CORE-1370 will be added to deny service activation before manual review, and to remind you of that fact. That will, at least, resolve the current issues that arise from activating a service with the module before manual review, where modules return errors and fail to add the service. #1 is planned in CORE-1229. #3 will be resolved in CORE-1370 as mentioned above

I added some lines to my config.php file in observium, and got the API menu to appear with API docs for billing, inventory, packages, so we'll see how it goes. I wish we could export the actual graphs, but it looks like just the data.

On the manage page you see Status > Active. On that you get 3 options: Upgrade / Downgrade | Change Tier | Cancel (Depending on what you've enabled) If you don't see this like in this video: http://screencast.com/t/JTM9pHqMu You must go to: Settings > Company > Billing / Payment > Invoice and Charge Options And tick any of the following boxes: - Allow Clients to Cancel Services - Allow Clients to Change Service Terms - Allow Clients to Change Service Package

you can edit the articles from the articles tabs . when you save change it return you to the index page .

One thing I'd like to see also, is a "test email" option where I can send a copy of the email to myself, perhaps randomly selecting a customer whos details will be used. This way, if I have a stupid error in the email I can correct it before sending it to everyone.

Paulov's suggestion of making it cron based would solve the issue of requiring the browser to be active while sending. Instead, the cron could send and log the message, and the browser would simply make ajax requests to Blesta to display that log dynamically. The downside is that you'd have to wait up to 5 minutes for the message to go out. Great suggestions

It would also be nice if it ran better than some of the other ones out there that it doesn't need to keep your browser open/connection when sending. Had an issue yesterday sending mass mail and internet died 1/4 of the way sending the email out so a bunch of clients never got the email from us. I'd like to see that not happen here.. The ideas posted above are also great.

Hello, The massmailler should have, (cron base), markting options such as: Client our Product related a ) If Client, should have the options: - Number of Days since Registration - Minimum and Maximum Number of Active Products/Services b ) If Product, should have the options: - Select multi Products/Services/Addons - Select multi Products/Services/Addons Status (Active/Suspended/Cancelled) - Select number of days to do an action like: - Number of Days After Order Date - Number of Days Before Next Due Date - Select multi (Not Have) Products/Services/Addons We use a lote this options (not in Blesta), and are very efficient