Jump to content

jas8522

Level 2 Member
  • Content count

    206
  • Joined

  • Last visited

Community Reputation

12 Good

About jas8522

  • Rank
    Level 2 Member
  1. Awesome, thanks for the hook!
  2. On multiple occasions now I've set a date for override auto-suspend and managed to miss checking the box beside it. While this is obviously user error, it's not the first time it has happened and unfortunately results in some serious problems where client's systems are auto-suspended because of my negligence. I think that to prevent this, the checkbox should auto-check when you click in the date field to select a date.
  3. Huh, indeed. The other template I was working with did have those kinds of conditional checks. But that doesn't explain why this one didn't work. I've got URLs within the conditionals of my final (working) template as well and no issues now. Color me stumped.
  4. Support set me straight. My variable checking model was the problem. We should not be using {if $variable} to check if it exists or is not empty. As suggested by WHMCS staff, we should instead be using {if isset($variable)} or this worked fine for me as well: {if !empty($variable)} Once I switched up the conditionals to check variables in that manner, all syntax errors stopped.
  5. Fixed up the $invoice_payment_method variable and tried swapping quotes for single quotes. All of my quotes applied to URLs were changed back to double quotes upon save. But I was able to change all my conditional comparison strings to single quotes and have them stay that way. Sadly it didn't make a difference. As @brian! hinted at, once I removed all links from within my conditional text, the syntax error stopped showing up in the logs. I'm going to submit this as a bug.
  6. @brian!Good point regarding the $ticket_department variable... can't even remember how that got in there. Must have been a copy/paste error from way back when. I'll definitely get that fixed up. It was supposed to be: {if $invoice_payment_method eq 'PayPal'} My other template exhibiting the same issue does *not* have conditionals with quotes in them, but it *does* have a link with double quotes. I wonder if perhaps switching all my URLs to single quotes will help. Worth a try! I'll update here with the results.
  7. Ah! Thanks for the tip: I'll give that a try Sadly their sample code uses double quotes: {if $ticket_department eq "Sales"} If single quotes solves this, I'll submit that sample code as a bug
  8. I've been having an odd issue with multiple email templates. It seems like using an {else} results in the following errors in the activity log: Smarty Error: Syntax error in template "mailMessage:mailMessage:plaintext" on line 33 "{$signature}" unclosed {if} tag I'm getting this with at least two different email templates. Here's one such template in plaintext for "Invoice Created" the one that the above error is specifically referring to: <p>Hey {$client_name},</p> {if $ticket_department eq "Sales"}Since you normally pay with PayPal, you should already have a subscription which will automatically renew on {$invoice_date_due}. If your subscription was previously canceled, then you should use the link below to complete payment manually.{else}According to our records, you normally complete payment with {$invoice_payment_method}, however {$invoice_payment_method} does not support automatic renewal! This means you will need to click the link below to complete payment manually for every invoice we create for you. If you'd like your invoices to automatically renew, without your intervention, we suggest switching your default payment method to a Credit Card or a PayPal Subscription. Just <a href="[snipped]/clientarea.php?action=details">click here to change your default payment method</a>for all invoices within your account. If you'd prefer to continue paying with {$invoice_payment_method}, simply click the link below to proceed.{/if} <p><strong>Invoice Details</strong></p> <p>Invoice #{$invoice_num}<br />Default Payment Method: {$invoice_payment_method}<br />Amount Due: {$invoice_total}<br />Date Created: {$invoice_date_created}<br />Due Date: {$invoice_date_due}</p> <p><strong>Invoice Items</strong></p> <p>{$invoice_html_contents} <br /> ------------------------------------------------------</p> <p>You can login to your client area to view and pay the invoice here: {$invoice_link}</p> <p>{$signature}</p> Yet the messages seem to send and display just fine. Is it possible the syntax parser is reading the word "if" in the body and thinking it's another {if} statement?
  9. Currently, a change of radio box selection can cause the selection to appear correct, but in the actual order summary, the wrong option ends up applying. This is because the javascript in base.js triggers recalctotals(); on both ifChecked AND ifUnchecked, which works great for checkboxes, but not for radio boxes. To fix this, I edited base.js as follows: Original: jQuery("#productConfigurableOptions").on('ifUnchecked', 'input', function() { recalctotals(); }); Modified: jQuery("#productConfigurableOptions input[type=checkbox]").on('ifUnchecked', 'input', function() { recalctotals(); }); This way, radio boxes don't cause both a Check and Uncheck to be triggered whenever a different option is selected -- only actual checkboxes trigger an uncheck recalc.
  10. Project Management Integration

    The WHMCS built module isn't bad. It definitely links properly to clients and tickets and has a great client-facing interface. The downsides to it are: - No email notifications (though these can be rigged up with a quick addon module, to a certain extent) - The to-do list functionality is functional, but not great compared to other to-do management systems. This is frustrating for us as most of a project is managing its tasks effectively. -Jordan
  11. Quick update: I also just tested the functionality of that checkbox out with a sub-account user. Here's the results: 1. When the "Support Emails" checkbox is NOT checked, the sub-account receives email notifications for any ticket he opened. 2. When the "Support Emails" checkbox is checked, the sub-account receives email notifications only for tickets he opened. In other words, regardless of the status of that checkbox, the support ticket notification emails are sent in seemingly the same conditions. Call me even more confused now...
  12. Hey John, I see the part that says: But that doesn't really clarify what the Email Preferences checkbox does because this sounds like default behaviour (regardless of the checkbox). In fact, nothing there talks about how the email preference section works. Take a close look at the screenshot shown on the page. Reasonable assumptions to make from how each checkbox under "Email Preferences" works are as follows: 1. When the "General Emails" checkbox is checked, this sub-contact will receive a copy of announcement and password reminder emails 2. When the "Product Emails" checkbox is checked, this sub-contact will receive a copy of Order details and welcome emails 3. When the "Domain Emails" checkbox is checked, this sub-contact will receive a copy of all renewal notices and registration confirmation emails 4. When the "Invoice Emails" checkbox is checked, this sub-contact will receive a copy of all invoices and billing reminder emails It then logically follows that: 5. When the "Support Emails" checkbox is checked, this sub-contact will receive a copy of all support ticket emails On the other hand, if the description there is right, which states: "Allow this user to open tickets in your account" then this isn't an email preference at all, it should be under "Sub-Account Permissions" instead because it's providing permission to open tickets.... except that already exists with the permission called "View & Open Support Tickets" Could you explain how these two differ? Why are there two different options that seemingly do the same thing? Once a user has permissions to view and open support tickets, then I'd assume they also get email notifications about *their* tickets only by default (which is what the documentation states)... no need for a checkbox to confuse people over this. Given this, shouldn't the "Support Emails" checkbox under "Email Preferences" be consistent with the rest of the Email Preferences and allow *all* support emails to be received by the sub-account? -Jordan
  13. Hey guys, I'm not sure if this is a bug or the way it's supposed to behave and instead there's just not a very informative UI, but here's what's up: A client, Ashley, has a master account and their developer, John, has a sub-account. John's sub-account is configured (confirmed from WHMCS admin UI) such that "Support" email notifications are enabled. When Ashley submits a ticket, John's sub-account should receive an email notification (from what I assumed from the Support email notification checkbox), but he does not. If John submits a ticket he gets email notifications about it, but again, when the master account does, he does not. The behaviour we're seeing right now is exactly how I would assume it would work if there were NO option to enable support ticket notifications in sub-accounts; any user (whether master or sub-account) that creates a ticket only gets notifications of updates to their own ticket. But the existence of an Email Notifications section for sub-accounts would have me believe that if a sub-account is configured to receive support email notifications, they would get notifications for all tickets under the entire client/master account regardless of who submits them. Can you confirm how that checkbox is supposed to behave? Is this a bug or expected behaviour? Thoughts on what I've written above about how I assumed this should work compared to how it actually works? Thanks! -Jordan
  14. I had a ticket without about 20 messages in it. I realized that about 60% of those messages were another topic, so I selected them and split them into a new ticket. All went well, except for one thing: The oldest message that moved over to the new ticket (client-message, not admin. Not sure if this is relevant) took on today's date and was moved to the very top of the ticket as if it were the latest reply. I would imagine that it should have maintained its original date and been the last message in the list (since they're sorted newest first). WHMCS Version: 6.3.1
  15. Thanks Cole! I had a feeling it would be difficult to reproduce. I think I've figured it out though! It's all 'merged tickets' that are the issue. In the DB a ticket that has been merged (ticket 0) into another (ticket 1) results in an active singular ticket (ticket 1). This is good. Ticket 0 shows as it's prior status (mostly "Open" in my case) in the DB. The WHMCS web admin seems to know that these are to be ignored, probably because it's got a value set for the field "merged_ticket_id" but iWHMCS doesn't seem to be taking this into account. I'm betting because the API call hasn't been updated to check that field. So to reproduce this, this should work: 1. Create a ticket (ticket a) 2. Create another ticket (ticket b) 3. Ensure both are "Open" 4. Merge the tickets such that ticket a merges into ticket b (ticket b is the winning ticket) You should now find the WHMCS web admin is showing only ticket b (as it should) but iWHMCS still shows ticket a as being open and awaiting reply. -Jordan
×

Important Information

By using this site, you agree to our Terms of Use & Guidelines