sharepoinTony

@info – The practical side of SharePoint

Posts Tagged ‘Lists’

“New Item Added” Alert not working

Posted by sharepoinTony on July 23, 2010

I hope there is a happy ending to this story, I will update it when I find out. [Updated 7/26/2010]

Here is the situation

MOSS 2007, Alerts set on a Survey list.  Users complain that although they have set up Alert Me to tell them when a New Item is Added they are not getting the email alert.

I setup my own Alerts to test behavior, here is the run down:

  • Creating an Alert produces the “successfully create an alert” email message
  • Changing an item produces the item “has been changed” alert email message
  • Deleting an item produces the item “has been deleted” alert email message
  • Creating a new item DOES NOT produce the “New item added” alert email
  • Alerts on other lists in same site behave normally (all Alerts work as expected)

Some of the things I have done to troubleshoot/resolve this behavior:

  • Restarted the Timer service
  • Verified the Timer service was running
  • Checked the Timer Status in Central Administration – everything Successful and 100%
  • Checked the properties:

STSADM -o getproperty -url http://YourSiteURL -pn alerts-enabled
STSADM -o getproperty -url http://YourSiteURL–pn job-immediate-alerts

  • Re-registered the Alert Templates

stsadm -o updatealerttemplates -url http://YourSiteURL -f “c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\XML\alerttemplates.xml” -LCID 1033

Behavior after Re-registering the Alert Templates – same as before re-registering, ugh.

Decided to test more alerts on other sites, ah-ha!

  • Other sites in the collection with lists using Alerts behave as expected – “New Item Added” Alert works!

So what do we have?  Behavior is localized to this survey and only impacts New Item Alerts.  Wait, that sentence made me verify…other survey’s behave the same way!  So the problem is not with that “list” it is a problem for all survey’s.

Workaround’s

One workaround that was plausible was to create a workflow to send notifications when new items are created.  This seemed plausible only because in this situation, the users had already requested assistance creating an approval workflow for this survey.   I decided to do a quick test by setting up an approval workflow.  The workflow fails to start.

Following this trail actually helped me get to the bottom of all of this.  I finally came across this Microsoft support article explains how “starting a workflow from a survey response is not supported in Windows SharePoint Services 3.0” – and the article  “Applies To” MOSS 2007 as well.

That lead me to some blogs saying that Microsoft does not support “New item added” Alerts on SharePoint Survey’s in WSS 3.0 or MOSS 2007.   These blog postings were older, so I wanted to find either ‘new’ postings or something that I could consider more reliable.  After searching further I found a hotfix mentioning this behavior – KB983307 Description of the SharePoint Server 2007 hotfix package (sts-x-none.msp): June 29, 2010.

Resolution

What have we learned?

  1. The Alert behavior is a known problem in WSS 3.0 and MOSS 2007; there is a fix, but you will want to review that material and make a decision regarding installing it in your environment or not.
  2. Workflows are not supported for SharePoint Survey’s for WSS 3.0 and MOSS 2007, so keep that in mind to avoid the obvious issues and let your users know that they shouldn’t create Survey’s if they want to eventually attach a workflow.

Epilog (of sorts)

Using Alerts to notify people of Changes to items in Survey’s does work, however you should evaluate what you are trying to accomplish and choose the best tool.  Survey’s are quick and easy to build, so make use of this nice tool built-in to SharePoint when you need it…just be aware of the potential pros and cons associated with using them.

Advertisements

Posted in Alerts, Lists, SharePoint 2007, Survey, Workflow | Tagged: , , , | Leave a Comment »

Service Requests and Sensitivity

Posted by sharepoinTony on January 25, 2010

I recently implemented a customized version of the Microsoft Help Desk template for SharePoint 2007.  Quickly after launching I adjusted things based on feedback and input that never came prior to the launch.

Background

The service request system, implemented via the help desk template, by default requires that all employees have access to submit requests.  The open-nature of SharePoint (and most IT departments) also dictates that users be able to see the pending service requests.  This visibility is normally thought of as a good thing for IT and helps promote self-service internally.  One of the customizations that I put in place was a notification workflow that sent email to the help desk staff telling them of newly submitted requests.  This workflow also automatically responded to the customer via email providing confirmation that their submission was successful.  The email provides a link back to the service request list so the customer could see all of the pending requests, including their own.

The Request

One significant post-launch request came from Human Resources.  They occassionally make requests that are sensitive in nature, such as terminations.  HR felt that those requests should not be visible to all employees.  This posed a problem for the service request list.  There is no doubt that it is a valid request, and the desire to keep most requests visible to users hadn’t changed, so I now had an exception to deal with.
Options considered were limited for various reasons.  One option would be to simply make a duplicate request list for sensitive HR requests.  But that meant managing two lists for the help desk, tracking two lists worth of requests for IT management, and created a possibility that a request might sit un-noticed.
Another option was to avoid using the service request list for all sensitive requests.  HR could send an email request as they had done historically in this small company.  Everyone was already “comfortable” with that process, however no improvements would easily fit into the old email process.  Reverting back to an old process just didn’t sound good unless there wasn’t a better solution.

The Solution

The solution concept chosen was to install a CodePlex feature that would allow a workflow to change the permissions on specific requests.
The concept was that sensitive requests could easily be identified since HR knew at the time of submission whether or not the request was sensitive, and could simply ‘mark’ the request as sensitive.  The workflow could check the column used for this purpose and based on its value could change permissions on that specific item.  We could limit the visibility to the appropriate staff without significantly changing the existing service request system.

The “Useful SPD Workflow Activities” feature from CodePlex was installed on a test server and the concept was examined closer.  After successful examination and testing it was decided that this would provide a very acceptable solution to the situation, and a quick response to the request from HR.
I created a new workflow to manage these permissions changes for two reasons.  First, I like keeping workflows as simple as possible.  Second, I wanted to be able to provide the flexibility to execute this behavior without sending emails that may be confusing which might come from adding these steps into the existing notification workflow.
The new workflow is very simple.  I check the designated column in the service request list and if it indicates that the item is sensitive then I remove a SharePoint Group’s permissions to the list item. I use several SP Groups to provide access, one contains all users, one contains appropriate HR staff, and one contains help desk staff.  When I remove all permissions from the group containing all users then only the members of the HR and Help Desk groups can see the item in the service request list.  There is no impact to other users or other requests.

Because the workflow can be started manually, we have the flexibility to “hide” any request that comes in by simply modifying the designated field and initiating the workflow.  This means that if HR forgets to “flag” a request, or if any other request is deemed sensitive we can quickly and easily “fix” it without having a workflow running all the time to monitor changes to requests.  Everyone is happy with this solution and it took longer to write this blog post than it did to implement in production.
Footnote: This CodePlex feature was installed and implemented on a 64-bit Windows Server 2008 system running MOSS 2007.

Posted in Lists, Permissions, SharePoint Tools, Workflow | Tagged: , | Comments Off on Service Requests and Sensitivity

SharePoint Blog Category Pagination

Posted by sharepoinTony on August 29, 2009

Quick and easy.  That is what it sounded like.

It’s Friday about 3pm, a department manager wants ‘something’ added in his department site.  They want to post information for another group to view.  They want to categorize the content so the users can easily sort through the various postings.  They wanted a blog.  For the sake of brevity I won’t go into more details on what, why, etc. related to the choices, just the interesting tidbits.

I quickly created a SharePoint Blog site under their SP 2007 department site, did the few obligatory things to make it nicer and fit the theme and the department and let it go.    The department manager was happy, the end.

4-ish pm – he is back. Gee, we notice that when we select a Category from the QuickLaunch and the posts display, there is this little “1-10 >” thing down on the very bottom…and we don’t like it.  We want to see everything posted in that Category on one page, we don’t care how long it is or if we have to scroll down for days.

OK, I will take a look…there must be a setting in the Blog settings somewhere.  Nope, can’t find it anywhere.

I look at the page, it is … Lists/Categories/Category.aspx, so I decide to open it up in SharePoint Designer (SPD).  If I try to modify the view in ‘design’ mode it hangs SPD.  Nice touch. Did I mention it was late Friday afternoon?  After much searching around in Code mode, I find what I am looking for – that is the tidbit controlling pagination.  I knew it had to be a page or item view limit somewhere in there. 

Here is what you do to adjust pagination:

Go and find the <ListViewXML> tag (in the Category.aspx or other page where pagination control is desired), search there for the section of code that looks something like this:

/Query&gt;&lt;RowLimit Paged=&quot;TRUE&quot;&gt;10&lt;/RowLimit&gt;&lt;

Notice that “Paged” is equal to TRUE and has a value of “10″.  You can set the value to whatever number of blog posts you want to display.  I suspect that you could just set “Paged” to “FALSE” if you want to display every post from any chosen Category.  I plan to try that out very soon…but the critical knowledge has been gained and shared.

Enjoy your SharePoint Blogs!

UPDATE: I tested out setting Paged to “False”, which works fine, as long as you remove the number from the RowLimit (example above displays “10”).  If you leave a number in there, SharePoint will display that number of posts without pagination at the bottom to get to the additional posts.  Your code should look something like this:

/Query&gt;&lt;RowLimit Paged=&quot;FALSE&quot;&gt;&lt;/RowLimit&gt;&lt;

Posted in SharePoint 2007 | Tagged: , , , | 3 Comments »