IPCommerceFan

Just because we've received a lot of requests for whether we support this payment method, I'm suggesting this as an addition to Commerce. https://docs.affirm.com/

Works perfectly! If you're open to suggestions, I'd humbly suggest "<> has replied to your support ticket" include something that describes which support request is being replied to? Either the support request title or ID, or both? "Member has replied to your support ticket - #1234 - Help!" Also, do you think this could be extended to also notify admins when any ticket in the system, based on their currently selected filter, is replied to? fwiw, @Aiwa created a similar app for us on 3.4.9 (https://aiwa.me/files/file/16-support-request-menu/) that is sorely missed, since once you've cleared all support requests, it can be distracting/cumbersome to keep checking for new tickets when there are other tasks that need doing. With the way IPS can do desktop notifications now, it would be great to know almost immediately after someone replies to a ticket so a prompt response can be provided. :) Thanks again!

Same. We'd love to be able to send an email to customers who bought <x> product, and where a particular custom field or fields for that purchase matches some criteria (boolean, regex, length). It'd be neat if "Filters" (searches) like this could be set up and saved in similar fashion to how Support Requests filters work. We get by currently by querying the database and exporting to Mailchimp via CSV. It works, but it would be so much better (and less costly) to keep it all in-house, we don't really rely on click tracking.

Hi, I think it would be beneficial to show Upgrade options on the storefront, instead of expecting customers to locate upgrade options within the "Manage Purchases" module. e.g. Imagine all the packages in this group are somehow related, and are upgrade-able. This customer owns 1x of Package A and 2x of Package B already. This way its easier to see that a package can be upgraded. Currently it is hidden away in the Manage Purchases section, so we are using Discounts instead. The issue with offering discounts for purchases that should be upgrades, is that when you base a discount off a previous purchase, it applies to all future purchases. e.g. If I bought 1x Package A, I'd get the discounted price on as many of Package B as I want. The above image of course may not be ideal for all use cases, but I just wanted to convey an idea of how upgrade pricing could be represented. Maybe it could work similar to product options, where the price changes to "From <lowest configurable price>" or in this case, "From <lowest cost upgrade path>", and the Add to cart button changes to "View purchase options", where upgrades are offered first. Just want to submit this for consideration, since I'd really like to start using Upgrades instead of Discounts. :) Thanks!

Thanks! It does appear I was using the old template.xml (due to some customizations I didn't want to lose) with the new plugin. My mistake, thank you for the support!

Hi, I recently upgraded my site from 4.3.5 to 4.3.6 and SuperGrid seemed fine, but upon doing a FRESH install of 4.3.6 (on my test site) then immediately installing the supergrid templates and plugin, I ran into this error on the articles front page (/index.php?/articles.html/): Error: Call to undefined method IPS\cms\Records1::reputation() (0) #0 /home/testsite/public_html/applications/cms/sources/Theme/Theme.php(610) : eval()'d code(697): IPS\Theme\class_cms_database_Supergrid_FrontPage->entry(Object(IPS\cms\Records1), Object(IPS\cms\Databases)) #1 /home/testsite/public_html/applications/cms/modules/front/database/index.php(142): IPS\Theme\class_cms_database_Supergrid_FrontPage->index(Object(IPS\cms\Databases), Object(IPS\Patterns\ActiveRecordIterator), Object(IPS\Http\Url\Friendly), Array) #2 /home/testsite/public_html/applications/cms/modules/front/database/index.php(51): IPS\cms\modules\front\database\_index->view() #3 /home/testsite/public_html/system/Dispatcher/Controller.php(96): IPS\cms\modules\front\database\_index->manage() #4 /home/testsite/public_html/applications/cms/sources/Databases/Dispatcher.php(325): IPS\Dispatcher\_Controller->execute() #5 /home/testsite/public_html/applications/cms/widgets/Database.php(130): IPS\cms\Databases\_Dispatcher->run() #6 /home/testsite/public_html/applications/cms/sources/Pages/Page.php(1257): IPS\cms\widgets\_Database->render() #7 /home/testsite/public_html/applications/cms/sources/Pages/Page.php(2191): IPS\cms\Pages\_Page->getWidgets() #8 /home/testsite/public_html/applications/cms/modules/front/pages/page.php(73): IPS\cms\Pages\_Page->output() #9 /home/testsite/public_html/applications/cms/modules/front/pages/page.php(43): IPS\cms\modules\front\pages\_page->view() #10 /home/testsite/public_html/system/Dispatcher/Controller.php(96): IPS\cms\modules\front\pages\_page->manage() #11 /home/testsite/public_html/applications/cms/modules/front/pages/page.php(33): IPS\Dispatcher\_Controller->execute() #12 /home/testsite/public_html/system/Dispatcher/Dispatcher.php(146): IPS\cms\modules\front\pages\_page->execute() #13 /home/testsite/public_html/index.php(13): IPS\_Dispatcher->run() #14 {main} also this one here /index.php?/articles.html/articles/: Error: Call to undefined method IPS\cms\Records1::reputation() (0) #0 /home/testsite/public_html/applications/cms/sources/Theme/Theme.php(610) : eval()'d code(779): IPS\Theme\class_cms_database_supergrid_listing->recordRow(Object(IPS\Helpers\Table\Content), Array, Array) #1 [internal function]: IPS\Theme\class_cms_database_supergrid_listing->categoryTable(Object(IPS\Helpers\Table\Content), Array, Array, NULL, true) #2 /home/testsite/public_html/system/Helpers/Table/Table.php(548): call_user_func(Array, Object(IPS\Helpers\Table\Content), Array, Array, NULL, true) #3 /home/testsite/public_html/applications/cms/modules/front/database/category.php(533): IPS\Helpers\Table\_Table->__toString() #4 /home/testsite/public_html/applications/cms/modules/front/database/category.php(40): IPS\cms\modules\front\database\_category->view() #5 /home/testsite/public_html/system/Dispatcher/Controller.php(96): IPS\cms\modules\front\database\_category->manage() #6 /home/testsite/public_html/applications/cms/sources/Databases/Dispatcher.php(325): IPS\Dispatcher\_Controller->execute() #7 /home/testsite/public_html/applications/cms/widgets/Database.php(130): IPS\cms\Databases\_Dispatcher->run() #8 /home/testsite/public_html/applications/cms/sources/Pages/Page.php(1257): IPS\cms\widgets\_Database->render() #9 /home/testsite/public_html/applications/cms/sources/Pages/Page.php(2191): IPS\cms\Pages\_Page->getWidgets() #10 /home/testsite/public_html/applications/cms/modules/front/pages/page.php(73): IPS\cms\Pages\_Page->output() #11 /home/testsite/public_html/applications/cms/modules/front/pages/page.php(43): IPS\cms\modules\front\pages\_page->view() #12 /home/testsite/public_html/system/Dispatcher/Controller.php(96): IPS\cms\modules\front\pages\_page->manage() #13 /home/testsite/public_html/applications/cms/modules/front/pages/page.php(33): IPS\Dispatcher\_Controller->execute() #14 /home/testsite/public_html/system/Dispatcher/Dispatcher.php(146): IPS\cms\modules\front\pages\_page->execute() #15 /home/testsite/public_html/index.php(13): IPS\_Dispatcher->run() #16 {main} Can anyone else corroborate this? Fresh 4.3.6 install (using utf8mb4 if it matters), then installing ONLY the supergrid templates and plugin (and assigning the templates to the default database). Thanks!

Would be nice, especially since categories have a 'Cover Image' now. Could use that for the embed.

Hi, Quick one: We should be able to filter tickets via custom fields. Add "Custom Fields Contain" below this line. Equivalent of WHERE `r_cfields` LIKE '%searchquery%' I figure if we have custom fields available for support requests, it would only make sense to be able to search by them as well. Bonus would be searching by Purchase custom fields where a ticket has an associated purchase, but I figure that'd be more resource intensive. Thanks!

Great news! I'm hoping this eventually leads to receiving notifications for support requests as they come in, based on the currently selected ticket filter!

Idea time! Wouldn't it be great if a Commerce Package could exist in more than one Package Group? In database speak, have a packages' p_group be an array, instead of a constant. Like this: p_group='{"1","2"}', and in the ACP, call it "Groups" instead of "Group", and it be a multi-select instead of a single select. This way, you could have a store where products that pertain to more than one package group can be listed in each group without having to be separate, distinct, listings of the same product. It'd be better for sales tracking and SEO this way too. If a package absolutely must belong to only a single group, then perhaps some sort of functionality to "also display in" would be suitable? Thanks!

Actually, I just realized this functionality exists within nexus --> support --> requests --> preferences! Now all we need is for those tags to be available via Stock Actions, or perhaps even when composing any reply to a support request.

Second this, especially the Support Ticket ones!

Hi, Here's an idea for Support Requests. Similar to how Pages allows you to insert tags into a page like {block=""}, {pageurl=""}, and Emails have {$email} plus other app-specific tags, I think it'd be great if Commerce adopted a similar system for Support Requests for pulling in basic customer information. e.g. Stock Action: This would add a bit of personalization to stock actions, while keeping workflow at the same pace as not including any personalization. If the member doesn't have customer information, simply display nothing. Thanks!

Hey Mark, I really appreciate the reply! Yeah, in the spirit of keeping the software "lighter", I'll agree with that solution even though its not the same as what we had before. Creating a dummy account, using email filters, etc. The job is still getting done I suppose. Thanks for hearing me out.