Custom data view forms in SharePoint Designer and source redirects within workflow e-mails to hide administrative fields

17Jul09

Key takeaways:
– Create custom data fields to hide fields
– Add custom source characters to workflow e-mail links to take users to other pages
– Use a SharePoint Designer workflow to direct users through the process

Project overview:
Submitters will fill out fields on a list’s “New” data entry page, and an alert will be sent to a group of reviewers who will read submissions and respond. Reviewers can ask for more information from the submitter, or mark the status as ‘in progress’,’on hold’, or ‘complete’. If more information is required, submitters would need to then update the item, then resubmit. Submitters receive updates on status changes, and a completion message when it is marked ‘complete’.

Tools of choice to complete project:
– SharePoint Designer data views
– SharePoint Designer workflow
– SharePoint custom list

There are two groups of fields for this list/form:

  1. Submit fields
  2. Review fields

Requirements:
Submitters cannot edit the review fields
– Submit interface needs to only show pertinent fields
– Review interface needs to show submitted information plus review fields
– Reviewers need a way to view the entire list, and edit using the review fields directly from the AllItems.aspx view

Issues:
This is not as easy as restricting editing rights. Can you see the dilemma? Using SharePoint’s cut of the box options, you cannot restrict permissions on only certain fields while leaving others as read/write. Also, everyone needs at least edit rights to their own items so that they can submit in the first place. So, how do we get around it? How do we hide those fields from the submitter so they are never presented with that option?

Let’s think about how they might get there:

  1. If all fields are added as columns within the same content type, then the submitter would see all fields (including the review fields) when they are adding a new item. This is a messy interface.
  2. After submitting a new item to the list, a submitter would normally be taken to the AllItems.aspx view, or whatever view is set as the default. From there, they could potentially click on edit and edit the review fields.
  3. At various times within the process, the SharePoint Designer workflow will send status updates and/or request for more information to the submitter. Each e-mail will have a link to the item that they submitted, and by default they will have the option to edit the item from the DispForm.aspx page, and the EditForm.aspx page will have all the fields as well. This is a problem.

Possible solutions, and why these won’t work:

  1. Separate submit fields and review fields into separate content types, then drive people to the appropriate content type ID in the workflow e-mails. But…then the edit form will display the last content type used. This is fine for the workflow e-mails, but what about when the reviewers want to visit the AllItems.aspx list and then edit? They’ll see the submit fields only. You could allow allow all the content types to appear on the New button, and then reviewers can switch over to the review fields, but then that means that anyone could do that. Bad.
  2. Move items from a ‘submit’ list over to a ‘review’ list to manage the editing rights at the most secure levels. This would actually work, but you’d need to make sure that the IDs are synced up so that your workflow can match up each copy of the idea in the lists. This is definitely a more complicated solution, but it may be the only way to go if absolute security is a requirement. For this project, we don’t need to take it that far (see disclaimer at the bottom of this post).
  3. Create a data view using SharePoint Designer and add a security-trimmed “click here for review fields” link. However, security trimming does not work within the XSL portion of the data view area, and adding this link outside of the data view area removes the ability to include a lookup to the ID of the item. Catch-22, so I decided this was no longer an option.

Final solution – first trick:
I created several version of the default forms within the list, and each has a purpose:

  1. NewIdea.aspx: Replaced the default NewForm.aspx page, and using a custom list form in SharePoint Designer I removed all fields that weren’t pertinent for submitters.
  2. EditContributor.aspx: This is the page I give to submitters via the workflow e-mail so that they can enter in additional information whenever the reviewers request it (via checkbox visible to reviewers). This also only contains pertinent fields.
  3. EditAdmin.aspx: Replaced EditForm.aspx so that reviewers could edit easily from the AllItems.aspx view. This page only displays relevant fields.
  4. DispIdea.aspx: This is the page I give so submitters to view updates. This custom list form does not have the standard toolbar, therefore removing the ability to edit the item.

Note: I only replaced NewIdea.aspx and EditAdmin.aspx as default pages. The others are used by the workflow to take people directly to those data views via workflow e-mails as necessary.

Final solution – second trick:
After making sure the SharePoint Designer workflow was directing recipients to all the right custom list pages, I added a new source in the URL string so that people wouldn’t be inadvertently taken to the AllItems.aspx default view (where they could edit, which would be bad).

To do this, I created several confirmation pages:
– Thank you for submitting (after clicking OK on NewIdea.aspx)
– Thank you for updating (after clicking OK on EditContributor.aspx)
– Go back to the home site (after clicking CLOSE on DispIdea.aspx)

A sample of the source is as follows (included in the URL, replacing the default source characters for the above list pages):

Source=http%3A%2F%2Fprojects%2E5280%2Enet%2Finnovation%2FLists%2FInnovation%2520Idea%2520Form%2FAllItems%2Easpx

So, I added the source characters in the URLs that I included in the workflow e-mails, and voila – a system that completely hides the review fields from submitters.

Disclaimer: I know, I know…it wouldn’t take much for a savvy user to hack the URL and get to the edit fields. Very true, which is why the solution I describe above is not “secure” in the literal sense; it is simply a method to guide users away from fields they shouldn’t see. For most internal forms, this level of interface manupulation is sufficient for general business needs.

Advertisements


No Responses Yet to “Custom data view forms in SharePoint Designer and source redirects within workflow e-mails to hide administrative fields”

  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: