Tyson

You can't access the database from template files. There are several (hopefully obvious) reasons why you cannot. To fetch information that is not available to the template, you will need to update the controller to make it available.

If you want to know the last time the user was active in the system (last visit), then call Logs::getUserLog($user_id) from the API or your plugin.

I don't know where you got the date_added property from, but you should be calling Logs::getUserLog($user_id) if you want to know the last time a user was active.

Why do you want to make an AJAX request to login? Why not use the API?

I'm not sure I understand your problem. Could you clarify and provide steps to duplicate?

You shouldn't be calling php functions from template files. That is contrary to the MVC design and breaks the separation of business logic from presentation. Any data that should be available to a template should be set by the controller.

While I can't tell you exactly why you had this problem, I can say there are a couple problems with the code you had written. Here, you have two constructors for the class. I don't know how PHP handles an instance of a constructor and a constructor by name, but I'd guess it could be a source of the problem. You should only use __construct(). More on this in the style guide. The proper use of loading a model and calling it is: $this->uses(array("PluginName.ModelName")); $var = $this->ModelName->modelMethod($arg1, $arg2, ...); You may want to re-evaluate your naming conventions. For instance, I might name the plugin StaffNotes, and create a model Notes, with a method get. Thus, $this->uses(array("StaffNotes.Notes")); $notes = $this->Notes->get($this->staff_id); I don't see a need to include the company ID, as you can simply use the company already set in Blesta as referenced with Configure::get("Blesta.company_id"); Also, you don't need to load the Input and Record components from your model, since it inherits that from AppModel.

The module will select the first available dedicated IP and daemon from the list you've defined in the module, and set the server to them. Multicraft chooses the port.

If it works without setting arrays or querying the database, then I suspect the issue could be with the models you're loading or the data you're setting, which causes an error. To see what the error is, you can take a look at the php logs, or check the AJAX response in the browser when it fails to display the widget content.

I'll close this thread as completed for v3.3.

Does your widget appear in the "Manage Widgets" section of the dashboard or billing overview pages? Did you remember to define an action for it in MyprivateNotesPlugin::getActions()? You can always take a look at other plugins that define widgets, if you haven't already.

Not selecting one by default isn't really a bug. There currently is no feature in Blesta to specify which, if any, should be the default option. That might be a good feature request.

You'll need to keep the $render_section in there. Have you checked the response sent back to your browser after the widget is fetched? There may be an error shown in the response, which could be why the widget is not displayed.

That means that you are attempting to reference $this->Record, but that component has not been loaded. I think your widget should be created with a $render_section set for AJAX support: $this->Widget->create($this->_("MyprivateNotesPlugin.notes.heading_notes", true), array('id'=>"widget_myprivate_notes_admin_main", $this->Html->ifSet($render_section, null))); The reason it works when you comment out $this->set("data", $data); is because $data is undefined in index(), and attempting to reference it generates a php error.

Not sure I fully understand the problem here, but based on your example, I don't see $vars set in $data. $vars = array('field' => "value"); $data = array( 'test' => "test", 'user_id' => $tuser_id, 'company_id' => $this->company_id, 'vars' => $vars );

We're going to look into adding support for this. But if you have the currency setting Use Package Pricing for New Services Only checked, then configurable options need to be explicitly defined in the same currency and term.

I'm not able to duplicate this issue. The expected outcome of setting the renew date to a day in the future is for it to not be invoiced/renewed for an additional day, which is the behavior that I'm observing. I would need more clarification on the details necessary to duplicate this issue consistently.

This problem may be resolved as apart of CORE-1321, in relation to a separate issue, since your plugin name conflicts with predefined routes set for Blesta.

This is scheduled as an improvement in CORE-1344 for v3.4 of Blesta. I'll move this thread to the Support forum.

The thing is, we can't protect you from yourself. It's difficult, and sometimes impossible, to provide a user with both the freedom to do what they want in the system, and protecting them from making mistakes. While documentation might help, not many people look at documentation before they perform an action anyway. And I don't think anybody wants to see notes/messages on most pages that warns them and describes what not to do, in case they perform an action whose consequences are unfavorable to their expectations. While some additional documention may help, I think the best solution is to exercise additional responsibility in management of products. I imagine most people understand that changing a product's settings changes it only for future use, and leaves existing services alone. That said, your example of changing the Name field retains the old service information, but it is simply not shown any longer for existing services. Maybe it should be, and maybe there should be an option to remove it for a service. Something like this might be a good feature request.

What is your purpose in changing the Name field? The Name field acts as the key, and the expected behavior for key=>value pairs is to maintain the key's association with a variable value. You are also expecting the converse; to maintain the value's association with a variable key. Such a requirement is only logical for one-to-one relationships, which is not the case here. Additionally, if the module were to support propagating updates from the Name field with existing service fields (and I'm saying it should not), I would expect that it should also enforce the Required and Values settings under the Universal Module product. And enforcing those would be problematic as well. So I don't see this as a bug, but rather that it is currently working as intended. You may want to re-evaluate your intent on modifying the Name field since it does not maintain backward compatibility with pre-existing service fields, as you've already discovered.

Blesta's not open source software. However, the codebase is 99% open (unencoded). I agree making changes to the code after every update is a pain. Blesta supports independent extensions (modules, gateways, plugins), so it is possible to create stand-alone features in some respects. If you'd like to modify core code in Blesta without worrying about having to merge files after every update, you may want to look into doing so with vQmod.

As I mentioned above, the tags that are available to the universal module Welcome Email on the package depend on the universal module product you are using for that package. What are the universal module Package and Service options you have setup for the product? This example image shows a service option, (e.g. "hostname") in the Name column. So in the Welcome Email for the package, you can use the tag {service.hostname}. If a value exists for that field when the service is created, the email will show it. This Welcome Email is inserted into another email: the Service Creation email template, which can be found under [settings] -> [Company] -> . Make sure that the Service Creation email template contains the tag {package.email_html} in the HTML tab, and {package.email_text} in the Text tab. The contents of {package.email_html} and {package.email_text} is the Welcome Email you set for the package. Once you have set the tags in the email templates, you can try adding a service for a client using that package, and fill in all of the information to activate it. After it's activated, it will send the Service Creation email. You can check the Mail Log for that client (under Actions) on the client profile page to view the email that was sent.

New language file exports have been generated, available from the download links on the translator.

Yes, it doesn't look like you're passing in a reference to the session. Users::login() requires the first parameter to be the session, followed by the vars, but you have vars as the first paramater. You should also perform a post request, rather than get for that action. If you're attempting to setup a shared login with another system, you may want to use the Shared Login plugin instead.