Giving customers the power to organize open support ticket priority, on the fly!
Posted by Todd West Jun 11, 2009Out with the old
In the past, when a customer wanted to check on the status of any of their open cases they would log into their secure space overview page and use the Community Open Cases widget. This widget was designed with a very simple goal in mind, just display the open cases with a bit of extra information and an emphasis on Severity 1 issues. This proved useful for quite some time and gave customers a good overview of what was going on with their community from a support perspective.
However, there was one major flaw. Customers had no way of interacting with this information and often found it very difficult to organize this data in a manner that they could use quickly and efficiently. Welcome, open cases widget 2.0!
The new and improved open cases widget
Along with our upgrade of the Supportal to SBS 3.0, I took on the job of updating this widget to provide customers with better control over their open cases. There are two major upgrades that I gave this widget which have enhanced the way people use it:
1. Cases broken down by Severity
Instead of displaying all the open cases in a potentially enormous group, I've broken down the display into 3 distinctive parts. This is especially helpful for customers with more than 10+ open support cases at a time and allows customers to quickly see if they have any Level 1 issues that they need to attend to quickly.
2. New case option available: Priority
To the right of every case status is a set of up and down buttons which control the individual priority of every issue (within their respective severity).
Okay great, so how do I use it?
Step 1: Log in
Log into the Supportal and visit your Company's secure space "Overview" tab
Step 2: Organize open cases
Browse through any open cases and use the "move up/move down" buttons to re-order them. All the moving on the screen will be done in real-time thanks to our good old friend Javascript. You may recognize these buttons from SBS, as they are used to control the location of profile fields on the admin console registration settings page.
Step 3: Don't forget to Save!
As of right now, your cases will be in the order you want on the overview page, but there is one final step. You will need to click the Save Settings button at the bottom right hand corner of the widget. This will take the current ordering of your widget and persist the case priorities to the database.
You will receive a friendly notification at the top of the widget that your Priority changes have been successfully saved, and you are done!
Well that's easy enough, how does it all work?
I'm glad you asked--it's really quite simple.
Displaying the widget
First off, the widget loads up all the non-closed cases within a secure space and puts them into three different Collections (one for each severity):
for (String caseID : caseIDs) {
try {
SupportCase supportCase = supportCaseManager.getSupportCase(Long.parseLong(caseID));
String status = supportCase.getStatus();
if (status != null && !caseStatusManager.isClosedStatus(status)) {
String severity = supportCase.getSeverity();
String priority = supportCase.getPriority();
supportCase.setPriority(priority != null ? priority : "0");
if(severity.equals("Level 1")) {
openSev1Cases.add(supportCase);
Collections.sort(openSev1Cases, new CaseComparator());
}
else if(severity.equals("Level 2")) {
openSev2Cases.add(supportCase);
Collections.sort(openSev2Cases, new CaseComparator());
}
else {
openSev3Cases.add(supportCase);
Collections.sort(openSev3Cases, new CaseComparator());
}
}
}
catch (NotFoundException e) {
log.error("Could not retreive support case in OpenCasesWidget: " + e.getMessage());
}
}
(Ideally this will get refactored soon to allow for more or less than 3 severities instead of being hard-coded. But it will work for now.)
The CaseComparator() orders all the currently open cases by their priority in the database. If nothing has yet been set, it will be put in the order that the cases were created.
The fancy effects
The cases are now sent to the template, where they are displayed in their respective severity grouping and automatically hooked into the Javascript functions that allow the up/down buttons to work. When you click on one of the buttons the following Javascript magic happens:
1. References to the required objects on the screen are loaded up using Javascript:
var moveUp = function(e, type) {
Event.stop(e);
var ansc = this.up(".case-field");
if(ansc != undefined) {
ansc.previous().insert({before: ansc});
updateHiddenField(ansc, ansc.next());
}
updateOrderingAnchors(type);
}
2. A hidden priority field for each case is updated with the new ordering value:
var updateHiddenField = function(element, newElement) {
var temp = element.select(".case-priority")[0].value;
element.select(".case-priority")[0].value = newElement.select(".case-priority")[0].value;
newElement.select(".case-priority")[0].value = temp;
}
3. The ordering of the case above (or below if the down arrow was pressed) will be swapped on screen and the list rebuilt:
var updateOrderingAnchors = function(type) {
if(type == "1") {
var elms = $("sev1-case-list-body").select("tr");
}else if(type == "2") {
var elms = $("sev2-case-list-body").select("tr");
}else{
var elms = $("sev3-case-list-body").select("tr");
}
elms.each(function(tr, i) {
var anchors = tr.select(".field-moveup")[0];
if (i <= 0) {
anchors.update("<span class='move-up-disabled'>move up</span>");
}
else {
anchors.update(new Element("a", {"class": "anchor-move-up", href: "#"}).update("move up"));
}
anchors = tr.select(".field-movedown")[0];
if (i == elms.length - 1) {
anchors.update("<span class='move-down-disabled'>move down</span>");
}
else {
anchors.update(new Element("a", {"class": "anchor-move-down", href: "#"}).update("move down"));
}
});
bindAnchors();
}
4. Now that the ordering is complete, you click the Save Settings button which makes a call to this Javascript to call a DWR method and display the nice notification at the top of the widget:
CasePriorityAction.setPriorities( values, {
callback:function() {
$('save-button').enable();
$('jive-success-box').style.display = "block";
Effect.Fade($('jive-success-box'),{delay: 3, duration: 5});
}
});
Saving the data
The final step involves saving this to the database, which is done by the call to the setPriorities DWR method as noted above. This loops through all the cases on the screen and sets the priorities in the database accordingly:
public void setPriorities(List<String> values) {
try {
for(String value : values){
String[] vars = value.split("-");
SupportCase supportCase = supportCaseManager.getSupportCase(Long.parseLong(vars[1]));
supportCase.setPriority(vars[2]);
supportCaseManager.updateSupportCase(supportCase);
}
}
catch (NotFoundException e) {
log.error("Could not retreive case in CasePriorityAction: " + e.getMessage());
}
}
I hope this information provides you with interesting insight into how our custom development allows us to work smarter and more efficiently with all our customers. We want these new features to enrich your Jive experience!
As always, Jive welcomes any and all feedback about this feature and the Supportal in general. Please comment on this post or start a discussion in our Supportal Feedback space.
Introducing the CTF
When Jive SBS released this March with the newly developed Content Type Framework (CTF), it unlocked a world of limitless possibilities. Perhaps one of the greatest (and most overlooked) features in the Jive SBS 3.0 release, the CTF allows business owners the ability to dream big without taking a big hit to the wallet by providing developers with simple, easy-to-use hooks for creating new content types like events, ideas, forms and more. Customizations that would have previously taken several months or longer can be condensed into far shorter development cycles and can now all be done inside of a plugin. This has the added benefit of reducing long-term cost of ownership, as it ensures developers will be insulated from core product changes, making upgrades and patch release updates a breeze.
Naturally, given all of the benefits of the framework, we couldn't resist taking advantage of it ourselves! In the latest release of the Supportal we introduced a new customer environment tracking feature built on top of the CTF that we hope will shape our customer support experience in the months and years to come.
What is a customer environment?
Simply put, it is a collection of structured data that gives Support details on your setup, e.g., which version of the product you are using, the database you're hooked up to, and special configuration options that you use. When published, they look similar to a document:
Because the environment form is built on top of the CTF, commenting, tagging, search and other extras are all features that essentially come along for free. The editing experience is just like a regular form:
Once an environment has been created, you'll want to use it when creating new cases in the Supportal:
Why should I create an environment?
I'm glad you asked! Well, first off, if you're an Enterprise SaaS customer, we already have you covered, so no need to worry. Jive Support will create an environment document for you with the correct details and name it clearly so you know which one to use when creating new support cases. If you're hosting the software internally, consider these benefits:
- Faster Response Times
Once you fill out an environment, we'll never again have to ask you which version you're running on or what Java options you're using! Less back and forth with our Support Engineers means less time spent gathering details and more time on fixing problems and answering questions. Plus, if you have multiple environments that you manage, the environment tracking feature clarifies which one your case pertains to for both your colleagues and our support team. - Transparency
We're all about keeping people in the loop and environment tracking does just that. If your system admin goes on vacation, you won't be struggling to find the information you need to help our Support team resolve the problem. Plus, if a technical person needs to come up to speed on a case you have submitted, all of the details are available in one central place. - Improved Customer Support in the Future
When you associate an environment to your case, you're helping us build a repository of information that enables us to identify areas of collective strength and weakness. Environment tracking opens the door for advanced reporting capabilities that were previously impossible or very difficult at the least. It also allows us to make better decisions about the direction of the product.
Is my data safe?
When you create an environment, it will only be visible within your secure customer space in the Supportal, so only those with access to your secure space will be able to see the information, even if your case is made public. And we're not evil, so we'll never share your data with third parties. Your data is safe with us!
Now, after all this, if you still have concerns about creating an environment to associate with your next case, please let us know why! We're hope you're happy with our constant improvements to our Support tool and invite all feedback, either on this blog post or in our Support Feedback space.
Thanks and enjoy!
Additional Reading
If you're still reading, you must be a developer saying "I'm excited about creating my own custom content type! Where do I start?" For a deeper look at custom content types, start here. After you have browsed through the documentation, download the example memo content type plugin from our public plugins SVN repository:
https://svn.jivesoftware.com/svn/dev/repos/jive/plugins/memo-type-example/trunk/
The memo custom content type is a simple example that demonstrates the power of the Content Type Framework. Check it out and start playing!
Welcome to Jive SBS! We just upgraded our Jivespace community to SBS 3.0.1, and along with it upgraded the Supportal customization, adding a few new features and improvements.
If you see any issues, please post a discussion in our Supportal Feedback space or create a public case there, and we'll get it addressed quickly.
Now, on to the new features:
An updated Open Cases widget allows prioritizing by the customer
We previously allowed you to view your open cases, but sometimes when you have a few open cases it can be helpful to rank them in importance--both for you and your company, but for us as well. Have a look at it here, and it will automatically be in your account's secure space next time you log in!
Account Member Management falls into the hands of the Customer
Prior to this Supportal upgrade, if you wanted to add or remove someone from your secure space, you needed to ask Support to do so. Well, with the upgraded Supportal, you can now put this power into the hands of someone that is currently a part of your account. There is still one manual step, asking Support to appoint one of your users as 'user admin' for your account. Once designated, the user admin can add and remove users, as well as add/remove the admin privilege should that assignment need to change. You can see the link to manage account members on the Group Membership Widget on your secure space overview. Don't see it? Ask Support to add it to your account space today!
First integrated Environment tracking on cases
Are you tired of Support continually asking what version you're running, or similar questions? Well, we're tired of asking it too 
! We've now taken the first step to associating Environments to each and every one of your cases. That way, if the version does matter, we can simply take a look at the environment you have associated with the case and dive right into troubleshooting. What's the catch? We are going to need you to keep these as current as possible in order to make this all work smoothly. We are hoping to evolve this to be able to eliminate the Product drop down and solely use Environments in the future. We welcome your feedback and help in shaping this new feature in the Supportal. Please visit our Supportal Feedback space to do this.
Lastly, some new UI when creating a case
As you can see from the screenshot above, we've added some indication of what fields are required when creating a new case, and something you may also not notice is that we have taken away the 'Stage' detail as it was not useful to us.
Again, please let us know if you see any issues, and we hope you enjoy the new Supportal and the overall upgrade to SBS!
Announcing: Jive Version 2.0.X Enters Legacy Support Phase April 13th 2009
Posted by meganc Mar 10, 2009
One very important feature of the Supportal that can sometimes be overlooked is the ability to make a case public. A public case is just a case that shows as a discussion thread in a community that can be viewed by anyone.
The Supportal makes it easy to change a case from just being a normal case in your secure account space into a public case that can benefit the whole Clearspace user base. Let's take a look at how this is done:
A private case
Let's suppose that you've already created a case in your secure account space. As a customer, when you view the case, the case fields will look like this:
Notice the "public" check box is not checked. Also, notice that the breadcrumbs at the top show that the case thread is in the secure account space as expected.
A public case
Being a good citizen of the broader Clearspace user community, you see that this question or issue that you had in this case is something that others may encounter as well. Making this case public would help others out because if they are searching for an answer to the same question, this case thread will then show in their search results and they can find that answer quickly. Who knows, maybe they will then return the favor by making a case they have public as well which could benefit you later on down the road 
.
Ok, so you look at the content of the case thread and ensure that there is nothing there that is sensitive information, and you decide to make the case public. How is this done? With just two easy steps:
- Click the "public" check box to indicate you want the case publicly viewable.
- After clicking the check box, you'll see a combo box showing the possible communities that you can put the public case in. Choose whatever community makes most sense for the content of the case thread.
Now, click the "Update Case" button. Looks like nothing changed right?
Take a look at the breadcrumbs. Notice that this discussion thread is now listed as being in the public community that you selected above.
Also, notice that the case now has a box that says "This is a public case which is tied to your support account. Your community is located here:" The "Account Community" link takes you back to the homepage for your secure account space.
But wait. You still want this to show as a case in your list of cases in your secure account space so you can easily reference it for yourself later right? No problem.
The case appears as expected in the list of cases in your secure account space, but it actually resides in a public community now. You can manage the case as you would any other private case, but the content of that case is now benefiting the whole community!
The code
Making the case a publicly viewable case was easy enough right? Surely, the code behind the scenes must be complicated!
Not at all!
When the "Public" check box is checked, some Javascript on the page fires to show the communities that the case thread can be moved to:
function changeVisibility()
{
if (document.getElementById('publicCase').checked==true) {
document.getElementById('publicCommunityTag1').style.display="table-row";
}
else {
document.getElementById('publicCommunityTag1').style.display="none";
}
}
The list of community options that are show in the community drop down is populated in the action class with this code:
public List<Community> getPublicCommunityOptions() {
List<Community> availCommunities = new ArrayList<Community>();
Community root = communityManager.getRootCommunity();
for (Community c : communityManager.getRecursiveCommunities(root)) {
if (!accountManager.isAccountContainer(c)) {
availCommunities.add(c);
}
}
return availCommunities;
}
The call to accountManager.isAccountContainer(c) calls a custom class in the Supportal that basically just checks to see if the community has an extended property set that marks it as a secure account space or not. If the community is not an account space, it is eligible for putting public cases into.
Here is the code from the method responsible for doing the move:
private void moveCaseThread(ForumThread caseThread, long targetContainerID) {
try {
Community publicCommunity = communityManager.getCommunity(targetContainerID);
forumManager.moveThread(caseThread, publicCommunity);
}
The first line gets the Community object for the community that the discussion thread is going to be moved to (the one that was selected in our example above). The second line is what causes the move of the discussion thread to occur.
What about the code responsible for having the public case still show in the open cases widget?
We store the account that the case was created in originally as an extended property on the ForumThread object. So, to get all the threads associated with a private account community, we use this SQL:
SELECT threadID FROM jiveThreadProp WHERE name='caseAccountID' AND propValue=<PRIVATE_ACCOUNT_ID> ORDER BY threadID DESC
This gives us a list of the thread ids for all threads that are associated with <PRIVATE_ACCOUNT_ID> no matter what community that thread actually lives in.
That's really pretty much all there is to it.
So the next time you open a new case with Jive Software Support, ask yourself, "Would the broader Clearspace user community benefit from the question and answer I just had?" If the answer is "yes," (and really, when is the answer not "yes?" ), make it public!
Last episode I explained how we create the secure spaces and setup permissions (see How do the account spaces get created anyway? Is it private?). This post deals with the default widgets that come with a newly created community, and how we had to customize this functionality to meet our requirements.
I. How it's done out of the box
To do this, let's first take a look at how it would be done out of the box:
- Create a new community
- Then get re-directed to the newly created community
Here, community.ftl will call CommunityAction's getWidgetLayout via:
<#if widgetLayout?exists>
<div id="jive-body-main">
<div id="jive-widget-content">
<div id="thread.watch.notify" class="jive-info-box" style="display:none">
</div>
<#include "/template/global/include/form-message.ftl" />
<#include "${widgetLayout.freemarkerTemplate}" />
</div>
</div>
</#if>
And within getWidgetLayout() you'll see that if we haven't customized a community and a layout doesn't exist yet, we'll just copy the default:
public WidgetLayout getWidgetLayout() {
try {
if (!isHasCustomized()) {
// if no draft widget frames exist, then no default layout exists
if (widgetManager.getWidgetFrames(getCommunity()).size() == 0) {
copyDefaultLayout();
}
.....
And to copy the default, we do this:
/**
* Copy the default layout (large left, small right) to the current community.
*/
protected void copyDefaultLayout() {
WidgetManager widgetManagerUnproxied = (widgetManager instanceof WidgetManagerProxy) ? ((WidgetManagerProxy)widgetManager).getUnproxiedObject() : widgetManager;
try {
WidgetLayoutDescriptor wld = widgetManagerUnproxied.getWidgetLayoutByName(TwoColumnLargeLeftColumnLayout.class.getName());
WidgetLayout wl = widgetManagerUnproxied.getWidgetLayout(wld);
widgetManagerUnproxied.addWidgetLayout(getCommunity(), wl);
.....
And at that point, you'll have the default layout with no widgets, and so further down the line you'll see a call to getWidgetFrames, and similarly to above it will copy the default:
public Map<Integer, List<WidgetFrame>> getWidgetFrames() {
if (!isHasCustomized()) {
if (widgetManager.getWidgetFrames(getCommunity()).size() == 0) {
copyDefaultFrames();
}
.....
which will add the default widgets:
/**
* Copy the default widget frames to the current community:
* <ul>
* <li>Left: Sub-Spaces</li>
* <li>Left: Projects</li>
* <li>Left: Recent Activity</li>
* <li>Right: Actions</li>
* <li>Right: Top Members</li>
* <li>Right: Tag Cloud</li>
* </ul>
*/
protected void copyDefaultFrames() {
try {
WidgetManager widgetManagerUnproxied = (widgetManager instanceof WidgetManagerProxy) ? ((WidgetManagerProxy)widgetManager).getUnproxiedObject() : widgetManager;
// column 1
int row = 0;
if (widgetManagerUnproxied.getWidgetByName(SubCommunitiesWidget.class.getName()) != null) {
widgetManagerUnproxied.addWidgetFrame(WidgetUtils.createWidgetFrameBean(getCommunity(), SubCommunitiesWidget.class.getName(), 1, row++));
}
if (isProjectsEnabled()) {
if (widgetManagerUnproxied.getWidgetByName(CommunityProjectsWidget.class.getName()) != null) {
widgetManagerUnproxied.addWidgetFrame(WidgetUtils.createWidgetFrameBean(getCommunity(), CommunityProjectsWidget.class.getName(), 1, row++));
}
}
if (widgetManagerUnproxied.getWidgetByName(RecentContentWidget.class.getName()) != null) {
widgetManagerUnproxied.addWidgetFrame(WidgetUtils.createWidgetFrameBean(getCommunity(), RecentContentWidget.class.getName(), 1, row));
}
// column 2, start row back at 0
row = 0;
if (widgetManagerUnproxied.getWidgetByName(CommunityActionsWidget.class.getName()) != null) {
widgetManagerUnproxied.addWidgetFrame(WidgetUtils.createWidgetFrameBean(getCommunity(), CommunityActionsWidget.class.getName(), 2, row++));
}
if (widgetManagerUnproxied.getWidgetByName(TopMembersWidget.class.getName()) != null) {
widgetManagerUnproxied.addWidgetFrame(WidgetUtils.createWidgetFrameBean(getCommunity(), TopMembersWidget.class.getName(), 2, row++));
}
if (widgetManagerUnproxied.getWidgetByName(TagCloudWidget.class.getName()) != null) {
widgetManagerUnproxied.addWidgetFrame(WidgetUtils.createWidgetFrameBean(getCommunity(), TagCloudWidget.class.getName(), 2, row));
}
}
......
II. How do the objects interact, and how are they displayed?
Sometimes these widget layouts, widget layout descriptors, widgets, widget frames, etc can get kind of confusing. I hope this illustration and ftl explanation can help paint a better picture, and deepen the understanding.
As an overview, you have the layout (red - WidgetLayout), the layout descriptor (blue - WidgetLayoutDescriptor) which tells how to display the widgets (green - WidgetFrames, contain widgets). A bit more technical tidbits from the database side of things, the container in jiveWidgetFrame is essentially the column, and the frameIndex is essentially the row. See more here:http://www.jivesoftware.com/builds/docs/clearspace/latest/DatabaseSchemaGuide.html#jiveWidgetFrame
We saw above how it will grab the widget layout, but I didn't show it returning from that method. This can be seen as the red box in the picture above (the layout)
<#if widgetLayout?exists>
<div id="jive-body-main">
<div id="jive-widget-content">
<div id="thread.watch.notify" class="jive-info-box" style="display:none">
</div>
<#include "/template/global/include/form-message.ftl" />
<#include "${widgetLayout.freemarkerTemplate}" />
</div>
</div>
</#if>
public WidgetLayout getWidgetLayout() {
try {
if (!isHasCustomized()) {
// if no draft widget frames exist, then no default layout exists
if (widgetManager.getWidgetFrames(getCommunity()).size() == 0) {
copyDefaultLayout();
}
return widgetManager.getWidgetLayout(getCommunity());
After returning the layout, we look to the layout FTL (which for this particular layout is ls.ftl) and CommunityAction for what happens next (this is the blue box above, the layout descriptor). Each different layout FTL asks for the widget frames associated with it, and will have them available via the CommunityAction. For our example, it looks for the widget frames in the left container, and then the right container.
This loads the widgets in the left container (green A)...
<div id="jive-body-layout-ls">
<div class="jive-body-layout-l">
<div id="jive-widget-container_1" class="jive-widget-container jive-widget-container-large">
<#if widgetFrames?exists && widgetFrames.containsKey(1?int)>
<#list widgetFrames.get(1?int) as widgetFrame>
<#if widgets?exists>
<@jive.editWidgetFrame widgetFrame=widgetFrame />
<#else>
<@jive.displayWidgetFrame widgetFrame=widgetFrame size=enums["com.jivesoftware.community.widget.Widget$ContainerSize"].LARGE />
</#if>
</#list>
</#if>
</div>
</div>
....and the rest of the file loads the widgets in the right container (green B)
<div class="jive-body-layout-s">
<div id="jive-widget-container_2" class="jive-widget-container jive-widget-container-small">
<#if widgetFrames?exists && widgetFrames.containsKey(2?int)>
<#list widgetFrames.get(2?int) as widgetFrame>
<#if widgets?exists>
<@jive.editWidgetFrame widgetFrame=widgetFrame />
<#else>
<@jive.displayWidgetFrame widgetFrame=widgetFrame size=enums["com.jivesoftware.community.widget.Widget$ContainerSize"].SMALL />
</#if>
</#list>
</#if>
</div>
</div>
</div>
They widgetFrames are available from this call to the widgetManager in CommunityAction.getWidgetFrames():
return widgetManager.getPublishedWidgetFrames(getCommunity());
And that's it! The widgets are displayed.
III. How we customized this
As you've seen, it's all initiated by NOT having anything setup the first time you are directed to the community.ftl file. So, we needed to ensure that there was a widget layout, and within that widget layout there are widget frames. So, during our secure space creation we need to hook into this ourselves. Have a look at how we're doing it:
1. Get a list of all the widgets in the system
Map<WidgetDescriptor, Widget> widgets = widgetManager.getAvailableWidgets();
2. Identify the two widgets we want to add initially, and loop through all the available widgets and hold onto them
Widget actionWidget = null;
Widget openCasesWidget = null;
for(Iterator<WidgetDescriptor> it = widgets.keySet().iterator(); it.hasNext(); ) {
WidgetDescriptor descriptor = it.next();
Widget widget = widgets.get(descriptor);
if(descriptor.getClassName().equalsIgnoreCase("com.jivesoftware.community.widget.impl.CommunityActionsWidget")) {
actionWidget = widget;
} else if(descriptor.getClassName().equalsIgnoreCase("com.jivesoftware.community.portal.widgets.OpenCasesWidget")) {
openCasesWidget = widget;
}
}
3. Then, as we saw above, we need to get the widget layout desired and add it to the newly created secure community
try {
WidgetLayoutDescriptor wld = getWidgetLayoutByName(TwoColumnLargeLeftColumnLayout.class.getName());
WidgetLayout wl = widgetManager.getWidgetLayout(wld);
widgetManager.addWidgetLayout(community, wl);
widgetManager.publishWidgetLayout(community);
}
4. Finally, setup our OpenCasesWidget (custom built by us) and the Actions widget. They are mapped to the correct lay out by the matching up of parentObjectType and ParentObjectID.
//load the widgets
WidgetFrameBean widgetBean = new WidgetFrameBean();
widgetBean.setWidgetID(openCasesWidget.getID());
widgetBean.setContainerID(1);
widgetBean.setParentObjectID(community.getID());
widgetBean.setParentObjectType(JiveConstants.COMMUNITY);
widgetBean.setPublished(true);
widgetManager.addWidgetFrame(widgetBean);
WidgetFrameBean actionWidgetBean = new WidgetFrameBean();
actionWidgetBean.setWidgetID(actionWidget.getID());
actionWidgetBean.setContainerID(2);
actionWidgetBean.setParentObjectID(community.getID());
actionWidgetBean.setParentObjectType(JiveConstants.COMMUNITY);
actionWidgetBean.setPublished(true);
widgetManager.addWidgetFrame(actionWidgetBean);
5. All done!
That is how we are creating the communities and customizing their overview tabs. Hope this has been helpful!
Let me know if there are any questions on the above functionality
-
-
Brian Provenzano on Releases: Jive SBS 3.0.4, Clearspace 2.5.13
-
Karl Cyr on Giving customers the power to organize open support ticket priority, on the fly!
-
russellharris on Releases: Jive SBS 3.0.4, Clearspace 2.5.13
-
rrutan on Giving customers the power to organize open support ticket priority, on the fly!