Mark

A couple of weeks ago, I wrote a blog entry discussing our efforts towards moderation features, and specifically the new warning system. Today I wanted to talk about another area of moderation, perhaps the most important area - managing content - and how we've improved that in IP.Board 3.3. Unapproved, Soft Deleted, Deleted IP.Board has some great functionality when it comes to managing content - you can set any user, group or forum to require manual approval before posts are made, and once content has been posted you can edit it, hide it, or delete it. The way that this is presented though can sometimes be confusing. Currently, the ability to hide a post (which we refer to as "soft delete" or "remove from view") is accessed by clicking "Delete". I see on a lot of communities, a moderator wants to hide a piece of content, but not delete it, and clicks "Unapprove". This of course works in that the content is hidden, but it re-enters the moderation queue and is indicated to moderators that it needs their approval when browsing the community or the moderator control panel, when in fact, moderators are aware of it, and have deliberately chosen not to approve it. We've made some changes to make this a little clearer: Currently when viewing a post, the options are: Unapprove Delete Remove from View (Soft Delete) Delete from topic (Hard Delete) [*]Edit This presents a few issues - firstly, as mentioned before - it's not immediately obvious that the "Delete" option contains sub-options, and in addition, "Unapprove" and "Remove from View" perform almost identical actions. In 3.3, we've merged "Unapprove" and "Remove from View" into a single action called "Hide", and "Delete" now simply moves the post to the Trash Can (accessible in the moderator control panel) without any additional dialogues. So the options now are:Edit Hide Delete All the same functionality, but much simpler. This change also applies to both topics and posts, and also the comments system used by Blog/Gallery/Downloads/Calendar/Nexus, which currently does not allow content to be hidden in any way once it's been approved. Interface Enhancements We've also moved a few things around to make moderation tools easier to access. The drop down menu When viewing a topic, there is currently a drop down menu at the bottom of the screen allowing you to perform moderator actions on the topic. The problem is, not only is it below all the posts, it's hidden behind a "Show Moderator Tools" link: We've moved this up the top, next to the reply button, and made the options a little easier to understand: We've also moved the drop down in the forum view to the same location. Multi-mod Also in that "Show Moderator Tools" bar is a long select box - when viewing a topic, there are little checkboxes next to each post which you can check, then select an action from that box to perform an action on several posts at once. This isn't great though because it isn't always obvious that it is that select box that the checkboxes are about, and also, even if you do know it, you have to scroll all the way down to get to it. The comments system used by Blog/Gallery/Downloads/Calendar/Nexus has a much better way of dealing with this - when you click the checkbox, an overlay appears in the bottom-right corner of your screen. We've implemented this same design: This is used both for the checkboxes next to each post when viewing a topic, and next to each topic when viewing a forum. We've also made it so that the options available are aware of the options you check - for example, if you check a post which is hidden, you'll see the option to unhide it, but not also to hide it (since it's already hidden). Feel free to comment on this blog entry below or, if you have feedback unrelated to this blog entry, start a new topic in our feedback forum.

Any community administrator knows how important moderation features are to a successful community, and the IPS Community Suite offers some great features in this area. The Spam Monitoring Service, for example, a unique feature that is completely unmatched anywhere else, keeps your community safe from spam content. Also in IP.Board 3.2, we introduced the Moderator Control Panel feature, giving your moderators a central location to manage all of their moderation tasks. In IP.Board 3.3 we wanted to spend some time researching what could be done in this area to even further help your moderators to keep your community running smoothly. One moderation feature which has remained largely unchanged throughout IP.Board's life is the warning system. It's a fairly simple system - if a user behaves in a way that is inappropriate for your community you can issue them a warning and along with that warning give a punishment, such as requiring moderator approval of their content or even banning them from your community for a certain amount of time. So how can we make it better? We set ourselves a few goals for how we could improve the warning system for all of your users: Control. Many administrators prefer to have more control over the way moderation happens on their communities. You may want the first time a user is warned to always be a verbal warning only; you may then want to the second warning to always be a 1 day suspension, etc.; you may want different punishments for different infractions. Or perhaps you want to allow your moderators to choose punishments themselves as they do currently. We wanted the warning system to be able to handle both of these setups so you can be as fixed or as flexible as you like. Communication. At the moment, if a moderator gives a member a warning, no other moderators know about it unless they happen to be looking at a member's warn logs. We wanted communication between the system and the moderators to be better. Moderators should be able to know when a member is warned. They should be able to see who warned them, why, and what post caused the warning. They should know looking at a member's profile if they're currently serving out a punishment for a warning, and if so, which warning. Clarity. If a member is warned, they need to know why and what the punishment is. They shouldn't be put on mod queue and not know about it and then wonder why their posts aren't showing up. Points, Reasons and Actions The new system works on a points based idea. When a user commits an offence (for lack of a better term) they will receive a number of points appropriate for the severity of the infraction. As an administrator, you will set up these different "Reasons" in the Admin CP. For each reason, you can determine if moderators are fixed to a certain number of points, or if they can change the number of points to give a member. You can also choose whether or not to allow moderators use of a generic "Other" reason, for which they can set any number of points. For each reason, you can also set how long the points last for - whether they stay on the user's account forever, or if they are removed after a certain period of time, and if that is set in stone or something moderators can change when issuing a warning. You can then also set up Actions. Actions are the punishment that a user receives when they reach a certain number of points. There are 3 different punishments you can give:Moderation queue - all posts the user submits must be approved by a moderator before they are shown. Restricted from posting - the user cannot post at all. Suspension - the user cannot access any area of the community at all. And each can be for a specified period of time or indefinitely. Again, you can specify if this rule is set in stone or if moderators can have free control over the punishment. If a moderator issues a warning and it gives the user a number of points that does not have a corresponding action - you can choose if that means moderators can set whichever punishment they like, or if that constitutes a "verbal warning only". Through this advanced level of control - you can allow the system to be as rigid (in that moderators have to give a certain number of points for each type of infraction, and punishments for each number of points is defined) or as flexible (in that moderators can give whatever number of points and whatever punishment they choose) as you like. Since points can also automatically be removed after a period of time you can also be as forgiving or not as you like. So this is what the warning screen looks like (you can get to it from a link in the member's profile or next to any of their posts): After selecting a reason, the punishment will be filled out and you may or not be able to change it as per the Admin CP settings: If a moderator has control over the number of points, they can also click the "?" icon which will explain all of the points levels and warning actions. Notifications As you will have noticed in the above screenshot - when warning a member, you can specify both a note for the member (in which you will presumably explain why you are issuing the warning) and a note which can only be viewed by other moderators. Neither are required, but will show up in the warning log. After issuing a warning, the member will be sent a notification which will take them to their warnings log page from which they can see the warning and what punishment they were given: Users and moderators can access the warning log from the profile or from any post. When a moderator views the log, they will see the note for moderators in addition to the note for the member. In addition to members receiving notifications when they are warned, all moderators who have the ability to view warnings can set their notification options to notify them when any other moderator issues a warning. Warning and Punishment Information Note that the details popup includes a link to the actual post which caused the moderator to issue the warning. When a moderator clicks on to the warning page, it remembers where they came from - this allows both them to be taken back there once the warning has been issued, and it allows other moderators to see the exact post the warning was issued for. When another moderator is viewing that post, it will also be indicated there with a red icon: This allows moderators to see that a warning was issued for the post and that they do not also need to issue a warning. Clicking the icon brings up the details popup: In addition, when viewing a user's profile, moderators will be able to see if they are currently serving out any punishments: And again, clicking on that badge will show the details: Acknowledgements Another additional feature is the option to require that all members "acknowledge" their warnings. If enabled, after a user is issued a warning, they will not be able to post again until they acknowledge it. When they click the reply button, they will be shown a screen like this: After acknowledging the warning, the user will be taken straight back to the post screen. If you have not enabled acknowledgements, or even just to remind the user even if you have - when a user is on moderation queue, a message above the post editor will remind them of this, so that they don't wonder why their post isn't showing up after they post: Integration Although we have talked about this feature from within the forums app - the integration you see will be included in all applications, and developers can add easily add support for their own. The integration will allow the following features in every app:The link backs to the content from the warning log, wherever that is. The red icon within the content if a warning has been issued for it. Honouring of the punishments given - moderation queue and restricted from posting. The message showing above the editor if on moderation queue. Prompting the user to acknowledge warnings before posting. We hope that the new warning system helps you to manage moderation on your community more easily. This is just the start of our plans for IP.Board 3.3 so watch this blog for more updates coming soon. Feel free to comment on this blog entry below or, if you have feedback unrelated to this blog entry, start a new topic in our feedback forum.

IP.Blog is our popular blogging platform for the IPS Community Suite. We've been working on updates and improvements to this platform for the upcoming 2.5 release which we wanted to talk about today. Interface Improvements We've spent a lot of time cleaning up the interface and making use of the new styles available in 3.2. The aim was to make it simple and intuitive to create, manage, post to and find blogs. Here's a few screenshots: Tags IP.Blog was our first product to make use of tags. In IP.Board 3.2 however, we added a more global tagging system with more advanced features (for example, an open or closed system and prefixes). In IP.Blog 2.5, we've updated the tags system to use that new global system, so the features and interface that you're familiar with will now be available in Blog too, including tag search. Existing tags in entries will be updated to the new system, so nothing will be lost. Friends Only Currently IP.Blog allows you to have blogs that are private or only viewable to those who you specify. We've integrated IP.Blog into the friends feature in IP.Board and added a new "Friends Only" option which allows your friends (and only your friends) to view your blog. Blog This IP.Blog currently has a hook called "Blog This" which allows you to blog about a post you find on the forums. We've extended this feature so that a new "Blog This" link now shows in the standard share links used throughout the IPS Community, in: Forum topics Blog entries Gallery images Downloads files Content articles Nexus products Calendar entries By clicking the Blog This icon in any of these locations, you can blog about the content on that page with just one click. The content will be quoted and a link to the content will be added automatically to your entry. Manage Comments IP.Board 3.2 added a global moderator control panel. In IP.Blog 2.5 we've deepened the integration with this feature and so unapproved comments on blog entries will now show under "Unapproved Content" in the moderator control panel. Entry Images We've added an additional field when submitting a blog entry for an "Entry Image". This allows you to upload an image which will then display in your blog entry both in the entry itself and on listings in the entry and blog lists. Entry Views In addition to seeing how many views a blog has, you can now see how many views a single entry has had.

To wrap up our series of blog entries on IP.Nexus 1.4, there's just a few more new features and enhancements that warrant mentioning. HTML Emails Matt recently blogged about the new HTML email support in the IPS Community Suite. IP.Nexus 1.4 makes full use of this feature to send out clear, description and well formatted emails. It's much more than just a new wrapper around the same text - we've reviewed every email that IP.Nexus sends to make it more informative. Here's a sample before and after shot of a payment received notification: Charts & Graphs (and Lists) Back in December last year, we added a feature to Nexus allowing you to generate charts and graphs with various data. All graphs can be viewed for any period of time (and any span of time), you can customise which data to to place on what series and you can view the results as a pie chart, bar chart or line graph. We're adding two new features to this. First, a new type of graph which allows you to generate graphs based on the income received based on the country of the user purchasing: We've also added a new option for viewing the data - as a list. Often people just want to know, for example, what are their best selling products, not necessarily in a graph form. By selecting list as the chart type, you can see just that: You can of course use this list view for any of the graph types, including the new markets type. AJAXification When viewing a support request, there's quite a few things you can do other than reply. We've made two often performed actions: managing the cc list, and tracking/untracking the support request work using AJAX, so you can perform these actions without having to reload the page, distracting you from the support request. Support Bounce Sometimes customers will reply by email to a support request which had been closed for a long time. Previously, IP.Nexus would simply reopen the support request, however, this can be annoying if you sort requests by the date they were opened, as they will have suddenly jumped to the top of the queue. In IP.Nexus 1.4, you have the option to have Nexus reply to the customer in this case, asking them to submit a new support request, rather than reopening the old. Coupons and Renewals IP.Nexus allows you to create coupons which can only be used against chosen products. In IP.Nexus 1.4, you can specify if the coupon can also be used against renewals of those products. Alternate Contact Management We've redesigned the interface for managing alternate contacts in the Admin CP. You can now search for the alternate account by name, id number or email address, and can edit existing alternate contacts. That's all for IP.Nexus 1.4. Beta testing will begin soon, so keep an eye on the testing forum. In the meantime, if you have any feedback or suggestions unrelated to this blog entry, as always, please post them in the IP.Nexus forum :smile:

A little while ago, I talked about the front-end store improvements for IP.Nexus 1.4. In addition to these front-end changes, we've also made a few changes to back-end order management which we wanted to talk about today. Tracking Numbers IP.Nexus has always had the functionality for viewing shipping orders and printing packing notes. In IP.Nexus 1.4 we're expanding the shipping features by adding support for tracking numbers. When you click the button to mark an order shipped, you'll now see a popup asking for the tracking number and the service you're sending the package by: If you fill this in, customers will be given a link in their shipping notification allowing them to track their shipment. PayPal Payer Status Those who manually review transactions know that it's importance of to be able to approve genuine orders quickly while ensuring that fraudulent orders are noticed. For customers that pay by PayPal, one of the important factors in this decision can be if the customer paid with a verified PayPal account or not. In IP.Nexus 1.4, you'll be able to see right on the transaction review page if the payment (if it's a PayPal payment) came from a verified PayPal account. Transaction Review Sometimes when you're reviewing transactions, you might want to leave one and come back to it later - perhaps you're going to contact the customer for additional information, or wait to see if the funds appear. This can sometimes cause issue if there's more than one person reviewing transactions - one person might contact a customer for followup, then another refuses the transaction, or contacts the customer again. In IP.Nexus 1.4, we've added an additional status to transactions allowing you to flag a transaction as being "under review". Transactions with this status are clearly indicated on the review screen (they appear in a blue box rather than pink) and who marked it as such, so everyone knows you already have it under control. Void Account It is inevitable that sometimes you need to terminate a customer's account. Perhaps they've filed a chargeback, or broken your purchase agreement. While IP.Nexus has the ability to refund transactions and easily cancel purchases, this can be time consuming if the customer has made several purchases. In IP.Nexus 1.4 we've added something of a kill-switch. One button that will refund all transactions, cancel all purchases, close all support requests and ban the account from logging in. As always, if you have any feedback or suggestions unrelated to this blog entry, please post them in the IP.Nexus forum :smile:

Following on from our first blog entry on IP.Nexus 1.4, one of the areas we wanted to focus on in this version is hosting integration. IP.Nexus integrates with CPanel and WHM to allow you to sell and manage hosting services to your customers. Monitoring Anyone who sells hosting services knows that it is important to always have a eye on your servers and you need to know as soon as one of them goes down. With version 1.4, IP.Nexus has you covered. We're including monitoring features to keep watch on all of your servers. Here's how it works: every 5 minutes, IP.Nexus will call gateway script which will in turn call a monitoring script which you'll upload to each of your servers, the response from this tells Nexus that the server is online and healthy. If Nexus does not receive a response from the monitoring script, it does one of three things: 1) It can check with a backup gateway script (which you'll locate on a separate server) to ensure the issue isn't with Nexus' communications. If that script can get a response, the server is online and everything is okay. 2) It will give the server a grace period. You can configure how many times Nexus should allow a server to not respond before sending out notifications - this allows the server, for example, 10 minutes to recover before sending out notifications. 3) It will send an email to the list of people you have configured to be notified. Once that notification gets sent, all those who received it can reply to it and their replies will be sent out to all other people in the list - this is helpful if you have more than one person that's going to be being notified and need to keep them all in the loop. Any person receiving the email can also acknowledge the notification (more on that in a moment) or reset the monitoring back to a default state (which they'll do once they've fixed the problem). If nobody acknowledges the notification, and the server is still down after a period of time you specify, additional emails will be sent out to remind all that the server is still down. The system also has a plan for if Nexus itself goes offline. On the server where your gateway script resides, you can set up a cron for a script which checks the last time Nexus called it. This script will email everyone in your notification list if Nexus has not called it in over 15 minutes. You don't even need to configure this script - Nexus will keep it up to date with any changes you make to the list of people to notify. You can at any time view the status of your servers in the Admin CP - a green tick indicates that everything is okay, a red cross means the server is reporting offline: With this of course, you can now create servers which are not integrated with CPanel/WHM but are monitoring only. There are also of course hook points so you can add your own code to run when a server goes down or comes back up. Every sysadmin knows that when a server goes down to expect a flood of emails, phone calls, etc. from customers reporting the issue. Now that IP.Nexus knows when a server is offline, we've added a little notification which appears if a customer goes to submit a support request while one of the servers they have an account on is down, notifying them you are already aware of the problem: Server Cost When creating a server you'll now have the option to provide the monthly cost of the server. IP.Nexus takes this information and along with it calculates the monthly revenue from that server (based off the information IP.Nexus already has). This allows IP.Nexus to show you a monthly profit/loss for each server. Dedicated Servers Those selling dedicated servers in IP.Nexus are used to creating simple custom packages to represent dedicated servers. In IP.Nexus 1.4 we've added a special kind of custom package which represents a dedicated server. This allows you to make use monitoring and viewing the monthly profit/loss while maintaining all the flexibility of custom packages. Little Changes We've also made a number of small changes to the hosting features in IP.Nexus: As you may have noticed from the first screenshot, the server list is now separated by tabs into server queues. For those who prefer the traditional all-in-one layout, there is an "All" tab which will show all servers in the system. When cancelling a hosting account, Nexus currently terminates the account on the server. In IP.Nexus 1.4 you'll have the option to suspend or terminate the account. IP.Nexus now retains the domain and previous server of a hosting account even once it's been cancelled, this allows even cancelled accounts to show up in search results. We still have a couple more blog entries planned for IP.Nexus 1.4. In the meantime, if you have any feedback or suggestions unrelated to this blog entry, as always, please post them in the IP.Nexus forum :smile:

IP.Nexus is our hugely popular eCommerce and business management application for the IPS Community Suite. Over the past few weeks we've been working on lots of new features and enhancements for the next version of IP.Nexus (version 1.4). The first set of changes we wanted to talk about revolve around the storefront. The biggest change we've made in this area is a completely redesigned product page. This is what it looks like: The more perceptive of you will notice that a redesign isn't the only thing this screenshot reveals - we've added several new features to the storefront. Multiple Product Images Probably the most requested IP.Nexus feature, and coming with Nexus 1.4 is multiple product images. You can upload as many different images for a product you like and they are all displayed on the left-side of the product view. Clicking any image will bring it up in the larger box at the top, and clicking that will launch the lightbox to display the full-size image. We've made adding multiple images a quick and easy experience for administrators using an AJAX upload system, here's a video of it in action: http://www.invisionpower.com/uploads/nexus_multiple_product_images.mov As you can see, it's very easy to upload and manage multiple images. Product Reviews Another oft-requested feature coming in IP.Nexus 1.4 is product reviews. You can now set (on a per-product basis) if you want to accept reviews, and if you want to moderate reviews before they go live. Only customers who have purchased the product can review (they'll see a prompt both on the product page in the store and in their purchases list in the client area), and with it they provide a star rating out of 5. The average star rating is displayed on the product page. All members can click whether they found the review helpful or not, and the count for this is displayed just below the review. Product reviews of course integrate with the IPS Community Suite Moderator Center - so you'll be able to easily see a list of reviews pending approval, and members will be able to report reviews and these reports will show up in the Moderator Center. Tax Included IP.Nexus now has the option to include tax in the price which is shown to customers in the store. The text you see in the screenshot ("incl. vat.") can be customised to display whatever you like (so if you're not including tax in the price, it could say "excl. tax"). The calculation is based off of the member's location if known, or the fallback "All Locations" rate if the location is not known. Discounted Price IP.Nexus has long had the option to give selected members discounts based on their usergroup and previous purchases. In IP.Nexus 1.4, if a discount is applied, the original price will be shown striked out next to it so that users are aware that they're receiving a discount. Grid View As well as the product page itself, we've added a new viewing option to the category view. Rather than displaying products in a list, you can now display them in a grid format: You can of course set which view will be the default and disable the option for the user to choose. This is just the first blog entry we have planned for IP.Nexus 1.4. As always, if you have any feedback or suggestions unrelated to this blog entry, please post them in the IP.Nexus forum :smile:

IP.SEO is a free extra from IPS which provides tools to enhance the Search Engine Optimization of your community. It includes features like sitemap generation, the ability to set meta tags on any page, search engine statistics and SEO-related advice on your configuration. The IPS Community Suite itself has many built-in SEO features that are suitable for nearly all communities however IP.SEO expands upon them with more advanced SEO features. We've been busy working on an update to IP.SEO which will be available soon. New features include: Live Meta Tag Editor IP.SEO has long had the ability to add custom meta tags to any page within your community, allowing you to modify the title, add a meta description and more on an individual-page basis. While working on IP.SEO 1.5, we looked into ways we could make this important tool more accessible, and have taken concepts we learned from the Visual Skin Editor in IP.Board 3.2 and applied them to this. Much like how with the Visual Skin Editor you can modify the skin live on the front-end, the Live Meta Tag Editor allows you to browse the front-end of your community and view and edit the meta tags configured for each page you visit. This allows you to customise the meta information on every page in your community easier than ever before so you can make sure all of your pages have exactly the right information you want to show search engines. Improved Sitemap In IP.SEO 1.5, we've added support for IP.Calendar, IP.Nexus and IP.Chat to the sitemap, so now all IPS applications are supported and your entire community can be accessed by site maps easily. But not only that, we've also added some new settings for forums. You can now exclude a forum from the sitemap, or even set a priority level for forums on an individual basis. This allows you to rate your important content such as focussed user discussions higher than for example, site-related announcements or off-topic discussion. Acronym Expansion Users on a community will often post acronyms or abbreviations about the topic of your community, which can cause those posts to be missing the important keywords your community targets. For example, we often have users post "IPB" as an abbreviation for "IP.Board". Search engines of course, don't know these are one in the same and when someone searches "IP.Board", posts that say "IPB" won't match. This can be a problem. In IP.SEO 1.5, we've added a feature we call Acronym Expansion, which will automatically either replace an acronym with the specified long version, or wrap an acronym in a HTML <acronym> tag so that search engines know what the user means. This allows you to ensure that even user-generated content includes the important keywords your community targets. Miscellaneous Enhancements We've also of course included many miscellaneous enhancements. For example, in IP.SEO 1.5 it will be easier to get started with automatic sitemap.xml generation and a tool to download a blank sitemap.xml file if one cannot be generated automatically. In addition, in an effort to improve the SEO within all of our base products, the next releases of IP.Board and IP.Content have had some links removed when viewing the community as a guest which are inaccessible to spiders like the "Like" button. Beta Available Now If you are comfortable testing beta software, IP.SEO 1.5 is now available for beta testing in our pre-release forum. As always if you have any suggestions for future versions of IP.SEO, please post them to our feedback forum. If you're not already using IP.SEO, make sure you download this free extra now!

IP.Gallery 4 introduced a fresh look and lots of new features to our popular gallery application. We've had substantial feedback since 4 and so with Gallery 4.1 (which will be released alongside IP.Board 3.2) we've taken this feedback on board to refine some areas and add frequently requested features. My Media IP.Board 3.2 introduces a feature called "My Media". This allows you to quickly drop content from other areas of your community (attachments, blog entries, etc.) into posts in the forum. Gallery is of course no exception and you can now easily add images and albums created in the Gallery to your posts with a few simple clicks. Default View IP.Gallery 4 introduces a new "portal" home page showing recent images and albums. Some users though prefer a more structured view - viewing albums like categories on the forums. Gallery also has a view for this which we call the "Browse" view. In IP.Gallery 4.1, you can make the "Browse" view the default, and optionally completely shut off the portal view if you prefer. Square Thumbnails IP.Gallery 4 crops and resizes images to a square for use in thumbnails - this gives a clean and consistent view across the Gallery. Some users however, prefer images not to be cropped. Therefore, in Gallery 4.1 we've added a setting to disable this. When disabled, images will not be cropped and will be centered in a transparent square canvas - this allows the rows in the Gallery to remain consistent, but without cropping images. Other Miscellaneous Changes Stats (number of images, comments, etc.) is now on the gallery home page again - both the portal and browse views. We've removed the limit of 10 images at a time, you can now upload as many images as you like in one go. We've moved the slideshow button to a more prominent location, at the top of the page, next to the upload button.

Following our IP.Nexus 1.3 updates, here are the changes made to customer and purchase management: Screenshots shown are subject to design change. Refunds Occasionally, it may be necessary to refund a customer's payment. Authorize.Net provides an API for refunding transactions and as of IP.Nexus 1.3, transactions can now be refunded right from the Admin CP. When you refund a payment, the transaction will automatically be refused and any purchases cancelled. Redesigned "Transactions On Hold" page IP.Nexus may place a transaction on hold for review for several reasons: if it has a high fraud score, if there was a possible problem with the payment detected, or if you have IP.Nexus set to hold all transactions. Previously, you would see a list of transactions and click into each one to review and then accept or deny the payment. We found in our own usage that this was a slightly long-winded process, especially if you have lots of transactions - approving pending transactions is something which should be done as quickly as possible to appease customers. In IP.Nexus 1.3, we've redesigned the "Transactions On Hold" page so that all of the information for all transactions is shown on one page. All of the information you need to make your decision, including information from the anti-fraud service, is right on that page. Clicking "Approve" or "Refuse" will cause the box to disappear using AJAX so that you can move right onto the next one. We've also added a checkbox "Also ban customer" when refusing a transaction, which allows you to ban the member who made the transaction quickly - useful if the transaction is fraudulent for avoiding repeat attempts. Alternate Contact Improvements IP.Nexus allows customers to add "alternate contacts" which can view purchases and submit support requests to their allocated purchases. We find many of our own customers, particularly in large corporate environments, may have several different people for paying invoices and interacting with technical support. In IP.Nexus 1.3, alternate contacts can now optionally be allowed to pay invoices as well, so the person paying the bills doesn't have to be the account owner. Card Management When purchasing an item using the Authorize.Net gateway, IP.Nexus allows customers to store their credit card information for future sales. Card information can now be viewed and edited in the client area, allowing customers to update their card details without making a new purchase. Associations IP.Nexus allows purchases to be associated with each other. For example, here at IPS we allow addons (IP.Blog, Gallery, etc.) to be associated with an IP.Board license. Previously, this had to be done at purchase or in the Admin CP. In IP.Nexus 1.3, customers can do this themselves from the client area. Customer Search The customer search feature in the Admin CP has been improved to allow more kinds of searching and improved handling of internationally-formatted phone numbers. Purchase Expiry Warning When editing a purchase, if you change the expiry date to a date in the past, you'll now see a warning message when saving the purchase to indicate that the purchase will expire immediately. This is useful for avoiding accidental changes (which can be particularly troublesome if the purchase is, for example, a hosting account) and gives you a better idea of what Nexus is doing before it does it. There is also a similar warning for setting the date to a date in the future if the purchase is already expired. Auto-Charge Warning IP.Nexus will automatically charge a credit card on file if one exists when a renewal invoice is generated. There is now a setting to allow you to optionally send customers an Email before this happens to let them know in advance. You can specify how far in advance to warn the customer. Feel free to comment on this blog entry below or, if you have feedback unrelated to this blog entry, start a new topic in our feedback forum. If you have feedback related to changes beyond what this entry is referring to, please start a feedback topic.

Following our IP.Nexus 1.3 updates, here are the changes to hosting integration: Screenshots shown are subject to design change. Improved Error Log If a server experiences temporary issues, Nexus is unable to make calls to the server to create, suspend, terminate accounts, etc. When this happens, a log is made so that you can review and resend the failed commands. In IP.Nexus 1.3, we've improved the interface for dealing with errors so that you can quickly locate the account it relates to, and view the full API call information. On the subject of dealing with API errors - there may be times when an account cannot be created or it is manually edited on the server. IP.Nexus now has an easy interface for associating a record in it's database with an account on the server. You can just enter in the username on the server, and Nexus will figure it out. Improved Server List IP.Nexus lists the current load average when viewing the list of servers in the Admin CP. When there are lots of servers, this can sometimes cause the page to load slowly. In IP.Nexus 1.3, the load will be fetched by AJAX after the page loads so that there is no delay. Editing Account Information Sometimes you may need to edit the Nexus database without calling the server, for example, if a username is changed on the server and you just need to update the Nexus database.] In IP.Nexus 1.3, when editing a hosting account, Nexus will notify you which fields will be updated on the server and allow you to override that if you desire. Along with the above, when cancelling a purchase, Nexus will allow you to optionally not terminate the account on the server (which it previously did automatically). Partial Domain Search I previously mentioned the Live Search support in IP.Nexus 1.3. This supports partial searching for domains and account usernames which was not previously supported. Feel free to comment on this blog entry below or, if you have feedback unrelated to this blog entry, start a new topic in our feedback forum. If you have feedback related to changes beyond what this entry is referring to, please start a feedback topic.

Following our IP.Nexus 1.3 updates, here are the changes to the support request system: Screenshots shown are subject to design change. New Reply Warning Sometimes when working on a support request, the customer or another staff member will reply while you're in the process of typing your reply. This can be both an annoying and embarrassing situation. In IP.Nexus 1.3, before your reply is submitted, Nexus will check if there has been any replies since you opened the support request (this is done by AJAX) and warn you if there has been. "Viewed By" Often when viewing a support request you might wonder who else has viewed it. This can be useful to see who forwarded a support request, or perhaps to see if anyone opened and didn't reply. In IP.Nexus 1.3, a new button appears on the support request view which will open an AJAX popup showing you which other staff members viewed the support request and when. "View My last Responses" Sometimes, I'll reply to a support request and later remember some additional information. However, it can sometimes be difficult to find a support request again particularly if you can't remember the title or customer who submitted it. In IP.Nexus 1.3, we've added a new button to the support request listing called "View My last Responses" which will list all of the support requests where the last reply was by you. Staff Audit When running a support desk, it is important to be able to monitor staff performance, both the quantity and the quality of the support being given. In IP.Nexus 1.3, we've added a new tool called Staff Audit, which shows you the number of replies across time for a staff member: You can click on any number to see the replies: Email Bounce IP.Nexus supports receiving support requests and replies by incoming Email. We sometimes find that customers will send a new email to the "reply only" address, causing it to be bounced, which looks unprofessional and creates confusion for users. In IP.Nexus 1.3, you can specify a message which Nexus will reply with if it receives an Email it does not know how to process. CCs Sometimes when a customer sends a support request by Email, they may CC another recipient on the Email. In IP.Nexus 1.3, this is detected and indicated in the support request view - when a staff member replies, the notification Email will also be CCd to the additional people. Signatures Staff members can now use their signatures in support request replies. Feel free to comment on this blog entry below or, if you have feedback unrelated to this blog entry, start a new topic in our feedback forum. If you have feedback related to changes beyond what this entry is referring to, please start a feedback topic.

Development of IP.Nexus 1.3 is well underway and the time has come to share some of the new features and improvements we've been working on. IP.Nexus 1.3 shall be released alongside IP.Board 3.2 - but is much more than a compatibility update. Our focus for Nexus 1.3 has been to examine and improve each component rather than making large changes. Many of you will have noticed our client area is now using IP.Nexus - the feedback and experience this change has provided, as well as the ever appreciated suggestions posted in our feedback forum have been invaluable, and we can't wait to show off the improvements. I'm going to write blog entries focussing on each component of IP.Nexus in detail over the coming weeks, but for today, I'm going to focus on global changes that affect the entire application. In particular, there's a few little things which I've seen suggested a few times... IP.Board 3.2 IP.Nexus 1.3 will be 3.2-compatible only and includes all of the improvements the IP.Board developers have been discussing in this blog over the past few weeks - the new ACP skin, language, hooks and search improvements are all of course in Nexus 1.3. Live Search IP.Nexus has always had a global search box displaying on every page allowing you quick access to type in an invoice number, customer name, or lots of other information and get access to it. The search box currently appears in the left-side menu, and you are required to manually select what the information you're providing is. In IP.Nexus 1.3, we integrate right in to the ACP Live Search - you can enter in the same information here you currently can and be given a list of items it could apply to - no need to select what information you're providing. If you're in IP.Nexus already, that tab will even be automatically selected. Attention Icons There are several areas of IP.Nexus which might require your attention, such as transactions on hold or open support requests. In IP.Nexus 1.3, any areas needing your attention are indicated by icons above the left-side menu. Clicking any of these will take you to the area in question. From left to right, the icons are: open support requests, transactions on hold, pending shipping orders, payout requests and hosting API errors. If the value is 0 or the user does not have permission to deal with it, the icon won't show and if they're all 0, the strip will disappear entirely. 2CheckOut Gateway IP.Nexus 1.3 includes support for the 2CheckOut payment gateway. Subscription Mode I often see people using IP.Nexus for selling "subscriptions" - an item which can only be purchased by a member once, and then renewed. Sometimes, users find this confusing and end up buying a new item rather than renewing the old. In IP.Nexus 1.3 you can set a product to be a "Subscription" - users will only be able to purchase it once, and if they try again, they'll be prompted to renew their current purchase instead. Return Group IP.Nexus has the ability to move users into a different primary group when a user purchases an item, and remove that group when an item expires. In IP.Nexus 1.3 we've expanded this functionality to be more tiered - if a user purchases an item which moves them into "Silver Members", then another to move them into "Gold Members", when one expires, they'll still keep the group provided by the other, rather than being returned to the default group. PayPal Subscriptions IP.Nexus has an option to enable PayPal Subscriptions, which gives the user an option when checking out to pay normally or start a subscription. Many users found the two options confusing and so as of IP.Nexus 1.3, if PayPal Subscriptions are enabled and the item has renewal fees, PayPal Subscriptions will be used automatically. This is the behaviour formerly used by IP.Subscriptions. Notification Copies Administrators often tell me they'd like to be notified when an order is made, or when an item expires. In IP.Nexus 1.3, you can select any type of invoice notification and when it is sent to the customer, a copy will be sent to you. This allows you to easily keep track of expiring purchases, be instantly notified if a transaction is placed on hold, and lots more. This is of course just the tip of the iceburg - stay tuned for more information on IP.Nexus 1.3! Feel free to comment on this blog entry below or, if you have feedback unrelated to this blog entry, start a new topic in our feedback forum. If you have feedback related to changes beyond what this entry is referring to, please start a feedback topic.

IP.Board allows you to set "ACP Restrictions" which allow you to restrict which administrators have access to which areas of the Admin CP. The two main pieces of feedback we hear about the ACP Restrictions system are: - It should be easy to set up and manage ACP Restrictions, without having to check lots of boxes, but still remaining the high level of control of the current system. - Administrators should only see the areas of the Admin CP that they have access to. Administrators should not get a "permission denied" error from clicking a link. We recognise that particularly with addons such as IP.Content and IP.Nexus which mean the Admin CP is controlling many different sensitive aspects of your community, it is important that using ACP restrictions is becoming more common, and in IP.Board 3.2, we have improved on both these areas. Setting Up Setting ACP restrictions is granular - you give access to the application, the module and then areas in that module. In previous versions of IP.Board, to give access to every area except one, you would need to check every checkbox. Now in 3.2, checking a checkbox which has "children" will automatically select all children. So if you want to give access to all areas except the "Forums" tab, you simply need to check 1 checkbox on each tab except Forums. On the other hand, if you want to give access to just the "Forums" tab, you simply check the 1 checkbox under the "Forums" tab. If you don't want to grant access to a whole area, you can select individual permissions which will automatically select the required parents. Restrictions In Action The ACP will now only show areas that you have access to. For example, an Administrator who only has access to the Look & Feel section, will only see the Look & Feel section: (The System tab always shows as the "Change My Details" page is always available) The menu, both from the dropdowns at the top, and the menus at the side, only show the items that you have access to. In addition, for a user likes this which can only see the Look & Feel tab and not the Dashboard, when they log in, they will be taken straight to the look and feel tab. Feel free to comment on this blog entry below or, if you have feedback unrelated to this blog entry, start a new topic in our feedback forum. Be sure to check the What's New in IP.Board 3.2 topic for a running list of announced changes!

To round up our development updates on IP.Nexus 1.2, I'd just like to mention in brief some additional features not already mentioned in previous blog entries. Go back in Checkout When going through the checkout, a progress bar at the top indicates what steps are still required. Previously, once you had completed one step, you could not go back and change the information provided. In IP.Nexus 1.2, you can click on any step in the progress bar that you have already completed and will be taken back to that step. Change Package You can now "swap"the package that an existing purchase is using in the Admin CP. This will apply all properties of the new package to the purchase (renewal dates, etc.) and apply any usergroup et al changes that the new package allows. Split Support Requests You can now split support requests and delete individual replies in the Admin CP. Each reply now shows a checkbox in the top-right corner, when this is checked, options will appear at the bottom of the replies. The system works across multiple pages - simply check the replies on one page, change to the next page and select any additional replies - the checked items from the first page will be remembered. Task Frequency Change In order to prevent time-outs when handling large amounts of data, and to generate invoices and expire purchases closer to their specified dates, all tasks in Nexus now run more frequently, with a limit on the number of items to process. This number should be fine for most users, but can be adjusted if necessary.

IP.Nexus has always had the ability create "custom packages" - you can specify a price and renewal terms and IP.Nexus will keep a log of the purchase and generate renewal invoices. However, some options like member group promotion, custom modules, etc. are not available in this setup - and with the addition of advertisements and hosting packages, it is necessary to be able to generate custom packages of these types also. In IP.Nexus 1.2 we've completely rewritten how custom packages are handled to allow this flexibility. When generating an invoice, the normal "Custom Package" option appears in the dropdown - choosing this will show you a menu of available package types just like when creating a normal package. The next screen shows all of the options that would normally be available to normal packages (except settings which don't make sense for custom packages, such as if the product should display in the store or only be available to certain member groups): After creating the custom package and the invoice has been paid for, it displays just like a normal purchase, both in the Admin CP and the client area: Administrators can of course edit any of the custom package settings from this page.

Currently in IP.Nexus when a package is edited, certain factors, like the group a user is moved into when purchasing the package, only apply to new purchases. While less of an issue for traditional products there are times, particularly with advertisement and hosting packages, where you will want to apply these changes to existing purchases. Let's say for example, a user has purchased a product called "Premium Membership" - note how the customer is in the group "Members": I now decide that I'm going to create a new group for people who have purchased this group called "Premium Members" and change the product settings to move members into this group when they purchase the package - note that I'm editing the package that the member bought, not creating a new package: When I save this, I will now see a new screen which indicates the change I've made can be applied to existing purchases: If I choose the bottom option, no further action will be performed - the package will save and the changes will apply to new purchases only. If I choose the top option, IP.Nexus will go through all existing purchases and make the change: And all of the appropriate changes will be applied: You can change almost any field for similar behaviour - removing the usergroup for example would move everyone back into their original groups, enabling the license key settings would cause license keys to be generated, for hosting accounts changing the allowances will update the account on the server, etc. The system will also notice if you have customised a purchase and keep your changes in such a situation. For example, let's say you've manually edit a customer's bandwidth allowance on their hosting account - when IP.Nexus goes to update the purchase it will notice the value has been customised and leave that particular setting alone (and update other settings as usual). Of course, changes made in this way are logged on the customer page as normal, as if done manually.

IP.Nexus can ask the customer for various information (like their full name, postal address and phone number) when registering purchasing an item. This information is required for shipping, some payment gateways and the anti-fraud system. Up until now, these fields were static - only the hard-coded fields were available and you could only specify all or no fields were required at registration or checkout. In IP.Nexus 1.2, we've made these fields customisable - you can choose which should show where, which should be required and add and reorder fields as you see fit. This means, that you could, for example, add a "Company" field, which would show alongside the others: Of course, users can also edit custom fields in the client area, and administrators can edit them from the customer page. Whenever the details is changed, it is logged to the customer history page as one would expect: Administrators can also search by custom fields both from the quick-search in the menu, and the main customer search form: This also means that since existing fields can be edited, you can now reorder or remove options from the "Country" field. You can also specify if "State" should be required or not.

IP.Nexus aims to give you the tools you need to monetize your community, and the core of that is the actual transaction process. We've made a number of changes in IP.Nexus 1.2 not only to make managing payments and gateways easier but to protect you against fraud, encourage renewals and generally make it easier for you to make more money. Authorize.Net Recurring Payments IP.Nexus has since version 1.0 supported the Authorize.Net payment gateway. In IP.Nexus 1.2, we're adding support for two systems which will automatically bill customers renewal charges: The first is their "Automated Recurring Billing" system. This works very similar to PayPal Subscriptions - a profile is created on Authorize.Net with the payment information. Then when the renewal is due the card is automatically charged, and Nexus is notified. For more information about Automated Recurring Billing, please see Authorize.Net's website. The second is their "Customer Information Manager" system. This works by having Authorize.Net store the credit card information. IP.Nexus then calls Authorize.Net to make payments, when renewals are due or manually in the Admin CP. This system gives greater flexibility as Nexus chooses when to charge, and you don't need to manually cancel recurring payments with Authorize.Net when a purchase is cancelled. For more information about Customer Information Manager, please see Authorize.Net's website. For both systems the user sees an option on the checkout asking if they want to be charged automatically: PayPal Website Payments Pro PayPal Website Payments Pro is a service provided by PayPal that allows merchants in the US, Canada and the UK to accept credit card payments directly on their website. We're pleased to say that IP.Nexus will support PayPal Website Payments Pro, including recurring billing support. For more information about PayPal Website Payments Pro, please see PayPal's website. Improved Gateways Page Different payment gateways have different requirements such as HTTPS, supported currencies and maximum transaction amounts. In IP.Nexus 1.2, we've added more information to the gateways page, including a warning box that will notify you of any misconfigurations: Anti-Fraud Protection MaxMind offers a Credit Card Fraud Protection, which here at IPS we've been using for years to help audit transactions for fraud. In IP.Nexus 1.2, we will be adding integration for this service. MaxMind returns a score between 0 and 100 indicating how likely a transaction is likely to be fraud. All the service needs is the user's address (which you can require on checkout), however it works best with gateways that use credit cards, i.e. Authorize.Net and PayPal Website Payments Pro. Depending on the score returned, you can choose to manually approve or decline the transaction: The purchase screen will also contain detailed information indicating the reasoning behind the score: For more information about this service, please see MaxMind's website. As always - if there's anything you'd like to see not mentioned here (including other payment gateways), please post in our feedback forum.

As was hinted in the blog entry last week, IP.Nexus 1.2 shall bring support for selling hosting packages. Right away I'd like to mention that this at the moment will work with any server using cPanel and WHM - we will of course gauge interest for other control panels for future versions. Hosting Packages You set up hosting packages just like regular products and advertisement packages. There is a contextual settings tab which displays hosting-specific settings, and these packages then show up in the store: Each package is assigned what we call a "Server Queue" - this is a collection of servers which the account may be created on. So for example, you could have your "advanced" packages only use higher-powered servers. Servers can be part of multiple queues. When the account is created, the server in the queue which has the least accounts is chosen to create the account on. Purchasing a Hosting Package When purchasing, users will be asked if they want to choose their own domain or use a subdomain of one of your domains. You can of course make only one of these options available. If the customer chooses their own domain, they'll be shown your nameservers, and if they choose a subdomain, they'll be shown a list of options - both of these you can set up in the Admin CP. Client Area Management Customers can view their account information in the client area along with all other purchases: From here they can also launch the control panel, FTP and change their password. You can also configure options to allow users to purchase additional bandwidth for that billing cycle, if their bandwidth limit is reached. Admin CP Management The purchase page in the Admin CP shows the same information that is available in the client area, along with the control panel and FTP buttons: Clicking the edit button will allow the administrator to edit specific allowances on the account, without the need to log into WHM: The administrator of course, does not need to manually suspend and terminate accounts. If the customer does not renew their account, it will be suspended, and, after a certain number of days (configureable in the Admin CP), terminated. Of course, using the normal package cancel function allows administrators to manually suspend accounts. Server Management In the Admin CP, you can view all of your servers along with the current load. From this page you can also reboot a server. Clicking on a server will show you a list of accounts on that server. You will also see an overview of how much diskspace is in use and how much is allocated (so you can see if you're overselling). Nexus will also check all the accounts in it's local database against the server to check for any discrepancies: Discrepancies can include an account not on the server but in the database (and vice versa), domain names not matching and account is suspended on the server but active in the database (and vice versa): In addition to auditing each server, there is an "Audit All Servers" button which will check all servers for discrepancies. We're sure that there will be many questions and comments about this new functionality - if there's anything you'd like to see not mentioned here, please post in our feedback forum.

IP.Nexus features an advertisement system which allows administrators not only to set up circulating advertisements on their community, but sell advertising space too. Currently in IP.Nexus, advertisements are purchased through a special location in the client area. In IP.Nexus 1.2 we will be removing this area and moving advertisements into the store. When adding a package to the store, you will be shown a screen which asks you what type of package to add: Then, when filling in the settings, there will be a contextual tab which shows settings for that package type. For products you'll see options about shipping and license keys, and for advertisements you'll see the usual advertisement package settings: Users can then purchase advertisements through the store just like a normal product. They will be asked to provide their advertisement link and image on the same screen that custom package fields appear: And view information about the advertisement on the normal purchase screen: Not only does this make the process of purchasing advertisements easier, but all of the options available to packages are now also available to advertisements, including: Only make certain advertisement packages appear to certain groups. Give discounts on advertisements to certain members, for example, members who have purchased advertisements in the past. For time-base advertisements, use renewal price settings to allow members to continuously pay for advertisement space. Move users who purchase an advertisement into a different usergroup. Allow users to upgrade to a higher package (for example, with more clicks) from within the client area. Finally, this change opens the door for us to add more types of packages all of which display in the store. Like, for example, hosting packages...

IP.Nexus 1.1 was released at the beginning of this month bringing a number of new features such as product options, reporting tools, advertisement system improvements and more. Already we have started work on IP.Nexus 1.2 - while release is still a while away, we'll be posting blog entries during development to show you the upcoming new features. The first new feature in IP.Nexus 1.2 that we wanted to talk about is a license key system. Many users are using IP.Nexus to sell digital products, and currently there is no way to keep track of where your products are being used. In IP.Nexus 1.2, you will have the ability to generate license keys and use an API to call back to Nexus to activate and check license keys. Generating License Keys When creating a product, there are now a number of options regarding how to handle license keys: License keys are by default generated either as a random md5 hash or several blocks of random letters and numbers - developers can also upload a simple PHP file to a certain folder to add more methods if you have your own way of generating license keys. You can also choose an "identifier" for the license keys. Identifiers are provided to the API when activating the license key (for example, your program could ask users for their license key and their name or Email address) - as an additional security measure. Identifiers can be the customer's name, Email address or any custom field with the purchase. This is of course optional. Managing License Keys In the Admin CP, there is a new box on the purchase screen which displays information about the license key: The grey box shows you the license key, when it was generated and it's current status and the table below shows where it's being used (you can set how many times a license key can be used). The dropdown menu at the top with the other buttons contains options to reset (which will clear uses and generate a new key) or cancel (which will make API calls to check the license key fail) the key. Of course, all actions related to license keys is also logged in the customer history page. Users can see their license keys in the client area: Using the API The API uses XML-RPC to send and retrieve data. Full developer documentation will be available when Nexus 1.2 is released, but to give you an overview, there are four methods: activate This is what you call when the user enters their license key, for example, on an installation screen. You send Nexus the license key, the identifier (if necessary) and any additional information you want to save (for example, the version number). If the license key is invalid, or the key has already been used the maximum number of times, Nexus will return an error - otherwise, Nexus will log the IP address used to activate and the additional information you sent and return a success message along with the "usage id" which is an ID number given to that installation for that license key. check This is used to check that a license key is still valid, for example, you may call this periodically from your application. You send Nexus the license key, the identifier and the usage ID (returned from the activate method) and Nexus will return the status of the license key (if it's active or cancelled). info This is used to fetch information about a license key. You send Nexus the license key and the identifier and Nexus returns data about the key (when it was generated, how many times it's been used, etc.) the purchase associated with it (it's ID number, when it expires, all custom fields, etc.) and information about any child purchases (that is, purchases associated with the purchase the license key is associated with. updateExtra This is used to update the additional information send in the activate method. You send Nexus the license key, the identifier, usage ID and new information and Nexus will update the information locally and return a success message.

For our final entry on IP.Nexus 1.1, I'd like to sum up some of the additional general tweaks and enhancements since our last blog entry. Marking an invoice unpaid In IP.Nexus 1.0, once an invoice has been paid, there is no way to mark it "unpaid". While for most circumstances this makes sense, in the event a check bounces or something similar, you may want to undo everything done when the invoice was marked paid. In IP.Nexus 1.1, when you attempt to mark a paid invoice unpaid, you'll see a screen like this: This explains clearly what will happen, including: Which purchases will be deleted. Which purchases will have their renewal dates changed (if the invoice was a renewal invoice). If anyone will have any commission revoked. Which shipping orders will be deleted. It will also warn you of any unexpected circumstances, such as if a purchase has been transferred to a different member, commission earned from the purchase has already been spent, or if any shipping orders have already been shipped: Purchase Page In IP.Nexus 1.0 there are specific pages in the Admin CP for viewing invoices, transactions and shipping orders. In 1.1, we've also added a page for viewing all the information about to a purchased item. This allows you to view all information about a purchase which could sometimes be difficult to find previously, such as the invoice which created it, any renewal invoices, if the member will be returned to a different group when the purchase expires, and more. Cancelling a Purchase It could sometimes be confusing what "cancel" means when referring to a purchase. Sometimes you just want to disable renewals, sometimes you want to revoke any privileges gained by owning a purchase, and sometimes you want to delete it entirely. In IP.Nexus 1.1, when you select cancel, it will present all of these options to you, explaining which does which, so that you can decide what action to take: Share Links We have added share links to the Store's product pages. Print Invoice While customers could always print invoices from their client area, we've also added a print button to the invoice page in the Admin CP. Usability tweaks We've made a few small tweaks to the interface to make things easier to use, including:We've added a "duplicate" button for packages, to save you having to select the same settings for similar packages. We've added a link to the customer page when viewing a shipping order. We've added a "Save and Reload" button when editing packages. We've added a button when viewing your purchases in the client area to submit a support request associated with a purchase right from the list.

Email on new order You can now set packages to send an email when a member purchases that package. Usergroup Discounts You can now provide discounts to users in a particular group. Auto-resolve Support Requests You can now set support requests to automatically be set to resolved after a given time of inactivity. Group Name Limit We've increased the length package group names can be to 255 characters. https In IP.Nexus 1.0, there was a setting which when enabled would make the payment screen server over https. The scope of this setting has been extended to the entire checkout process, the client area when providing information and support requests. Delete Transactions Transactions can now be deleted. Support Request API We have introduced two central models for handling support requests, one for support requests and one for support replies. This allows you to create support requests and replies using a simple API. For example, to create a support request: supportRequest::create( "Title", 1, 1, NULL, 1, NULL, NULL, supportReply::create( supportReply::REPLY_MEMBER, 1, "Message" ) ); Complete developer documentation can be seen here.

IP.Nexus has an advertisements feature, allowing administrators to display advertisements on their community and sell advertising space to third parties. We've spent some time going over some of the suggestions we've received for the advertisements system and have made the following enhancements for IP.Nexus 1.1. Start/End Time Advertisements can now be specified with start and end times for time-specific campaigns. Advertisement Packages: Expire by length In hand with the option to set a start/end time, you can now specify that purchased advertisements last a certain length of time, opposed to a number of clicks or impressions. Advertisement Package Descriptions You can now specify a description for advertisement packages which will display on the purchase screen. Admin Image Upload Currently, when an administrator adds an advertisement they must specify a URL to an image (or HTML code). As of Nexus 1.1, administrators will see an option to upload an image too. Circulation Mode In IP.Nexus 1.0, if there is more than one advertisement per location, a random advertisement is selected from the pool. In IP.Nexus 1.1, we've added a setting which allows you to continue using this behaviour, or to always use the most recently added advertisement. This is useful if you want to have a generic advertisement set up by the administrator but allow purchased advertisements to override that for their duration. Maximum Number of Advertisements You may only want one advertisement in each location at a time, so that advertisements don't circulate at all. In IP.Nexus 1.1, we've added a setting allowing you to specify the maximum number of advertisements per location. Administrators of course can oevrride this, but if there is the specified number of advertisements in a given location, users will not be able to purchase advertisement packages which add advertisements to that location. Alignment We've added a new setting which allows you to choose how to align your advertisements. Size Restrictions You can now specify in an advertisement package the maximum size for advertisements created by that package. External Access Currently, IP.Nexus displays advertisements in pre-set locations on your community. As of IP.Nexus 1.1, you can include advertisements in other areas of your skin, in IP.Content blocks and even in external pages and applications outside of IP.Board. To place an advertisement in a template or IP.Content block, you can simply use the tag: {parse advertisement="1"} The tag can take either the ID number for the advertisement to display, or the key for the location, which will use IP.Nexus' normal logic for fetching the advertisement. For example, using this tag: {parse advertisement="ad_code_board_index_header"} Would display whatever advertisement is configured to show in the board index header - if more than one is configured, Nexus will either pick a random one, or the most recent one (as per the circulation setting described above). To place an advertisement on an external site, you can call a new REST API which will out put the contents - the file is located at: http://www.yoursite.com/interface/advertisements.php You simply need to pass a single variable in the query string which is the same as the parse tag above (ID number or location key). For example, you might use something like this to add your advertisement to a website outside of IP.Board: <?php echo file_get_contents( "http://localhost/ipbdev/interface/advertisements.php?ad_code_global_header" ); If you have more in-depth feedback or ideas please use our feedback forum so your suggestions can be given proper attention. Otherwise, feel free to comment on this entry below.