InfoPath Form Security with WSS 2.0

[random]

I have the following scenario:

1. WSS 2.0 sharepoint site

2. on this site i've setup a form library

3. in this form library I have built an InfoPath form template for users to
submit requests to our administration staff for scheduling special events.

4. when the user submits the form, it is placed directly into the form
library and then sends a WSS alert via email to the administration staff of
the new form submission.

5. the administration staff can view all the forms in the form library and I
have special columns setup to display key information from the form (e.g.
submitter's name, submission date, status, meeting location, etc. etc.)

So far soo good...

However, there is a problem with this environment. Users can go back in and
edit (and also delete) any form that is submitted into the form library. This
also means they could go in and edit or delet another users form. This is not
good.

My attempt to correct this is as follows:

1. all users are set on the "Reader" access group.

2. I've changed the "reader" group permissions specfically to use "add
lists" and "view lists" rights. Technically this should give them the ability
to add a form, and view their forms in read-only mode.

The problem that arises with setting these permissions is that InfoPath
generates an access permissions error when the user submits the form, rather
then generate the "form submitted successfully" message. And what is even
stranger is that even though InfoPath generates the access permission error,
it still submits the form.

I would like to be able to get rid of this permission error so as not to
confuse the users, plus it doesn't look good in general when the submission
actually does work.

any insight is greatly appreciated.

 

[Patrick Halstead [InfoPath MVP]]

Hi Random,

This is a very common scenario and a great architectural question. So far as
I know, there is no way to configure user permissions on SharePoint to allow
submit for readers. I would love to hear about a way to allow readers to
submit, but it doesn't make sense that they can do this given the "reader"
status.

Here are some ideas for how to resolve your problem:

0. Use User Roles and Rules to switch submitters to the read-only view if
the open a form which has been filled out previously
Pros: simple declarative change, adding a read-only view that looks the
same is not too hard (could take some hours though)
Cons: people can still use notepad to modify the XML
1. Use e-mail for the first step and have the second Admin submit save to a
form library that is locked down (users are readers).
Pros: very simple to implement and works around rogue notepad editing
Cons: what happens if one of the admins forgets to open the e-mail?
2. Use two separate form libraries - one for "pending" requests and one for
"approved". Admins open the form and when they submit it goes to the
"approved" form.
Pros: Better tracking than e-mail.
Cons: requires deploying two form libraries and form templates and some
minor hardcoding to suibmit from pending to approved
3. Use digital signatures
Pros: This is the future of workflow approval. Adds functionality around
auditing, etc.
Cons: users must install digital certificates. Users can still delete
forms.

I hope this gives you some idea of possible soltions to your problem.

Regards,
Patrick Halstead
http://www.infopathdev.com/

 

[random]

Patrick...

Thank you for your detailed and concise response. I really appreciate it.

I think im going to go with option 0 (funny enough, I found this very
information poking around late last night.). The reason for this is I still
want users to be able to simply go back to the form library page to checkup
on the status of their request. So I want to keep it all in the same form
library. I did this by adding a field in the form for "status" with
"processing / approved / declined" options. I set this field only to be
viewable and editable by the administrators (using the user role function).
This "status" field is then viewable in the form library page as a column,
which easily allows the users to get a quick update on the status of their
request WITHOUT having to generate unecessary calls to our administration
staff.

My solution to keep users from deleting submitted forms from the library is
by removing the following columnes from the view and disabled users from
changing the view:

-name (linked to document with edit menu)
-edit (link to edit item)

With this, it removes the option for them to delete the item.
Im not too concerned with users being able to use notepad to edit the XML as
only a handful of our users are that savy, and they are the ones least likely
to even use the form


As far as suggestions go:

1. It would be great to see some enhanced InfoPath specific functionality
built into Sharepoint Services to address the need to secure form submissions
and build an architecture that allows for basic user submisstion / admin
approval scenarios. I would think this is a pretty common scenario in almost
EVERY form based application use when using InfoPath.

2. Enhanced security options in Sharepoint for document and form libraries
that specifically address form submission.

Im sure others may have more ideas as well.

thanks again patrick!!

cheers.

----
random




--
-random

Hi Random,

This is a very common scenario and a great architectural question. So far as
I know, there is no way to configure user permissions on SharePoint to allow
submit for readers. I would love to hear about a way to allow readers to
submit, but it doesn't make sense that they can do this given the "reader"
status.

Here are some ideas for how to resolve your problem:

0. Use User Roles and Rules to switch submitters to the read-only view if
the open a form which has been filled out previously
Pros: simple declarative change, adding a read-only view that looks the
same is not too hard (could take some hours though)
Cons: people can still use notepad to modify the XML
1. Use e-mail for the first step and have the second Admin submit save to a
form library that is locked down (users are readers).
Pros: very simple to implement and works around rogue notepad editing
Cons: what happens if one of the admins forgets to open the e-mail?
2. Use two separate form libraries - one for "pending" requests and one for
"approved". Admins open the form and when they submit it goes to the
"approved" form.
Pros: Better tracking than e-mail.
Cons: requires deploying two form libraries and form templates and some
minor hardcoding to suibmit from pending to approved
3. Use digital signatures
Pros: This is the future of workflow approval. Adds functionality around
auditing, etc.
Cons: users must install digital certificates. Users can still delete
forms.

I hope this gives you some idea of possible soltions to your problem.

Regards,
Patrick Halstead
http://www.infopathdev.com/