Hi Tommy
I have worked around this in the past by configuring the forms library so that
general staff do not have direct read/write access. I then set up web services
to handle the creation and retrieval of forms.
This allows you to add custom business logic to handle whatever security you
want. So for example you can create a web service that returns all the forms
where the submitter matches a particular form property ("Forms I created",
"Forms assigned to me", etc).
These web services can be used by data view web parts, or custom developed web
parts to create a user interface that allows staff to view their submitted
forms. Sure, you have to do some coding, but on the up side, it isn't a lot of
work, and you get very granular control on what users can see and where they
can access the information from.
One danger with taking the other approach of an event-handler customizing
permissions is that you will end up with a lot of "Limited Access" entries in
your sub-site security. I hear that anything around 1000 or 2000 security item
entries starts to degrade performance. Some information about this is also
listed on http://technet.microsoft.com/en-us/library/cc262787.aspx
On the "easy to do" side of things, consider enabling version history for your
forms. This gives an audit trail of who changed what, when they changed it, and
a before/after copy of the content.
Ivan
From: [email protected] [mailto:[email protected]] On Behalf Of Tommy Segoro
Sent: Wednesday, 11 February 2009 2:45 PM
To: [email protected]
Subject: RE: Infopath forms and security
You can attach an event handler on the list on ItemAdded event to automatically
detached the permission inheritance of that document. This way every time
someone submits a leave form, that form is detached and your event handler will
give access to whoever should have access to that form to programmatically.
From: [email protected] [mailto:[email protected]] On Behalf Of Nigel Hertz
Sent: Wednesday, 11 February 2009 12:31 PM
To: [email protected]
Subject: Infopath forms and security
Afternoon all
We've recently started looking into converting our many paper based forms into
InfoPath forms, hosted on MOSS.
Fortunately, a lot of InfoPath Forms Services limitations can be overcome one
way or another, and we'll be using Nintex workflow as the workflow engine.
One issue we foresee is security of forms. As forms need to be saved in a forms
library, I'm assuming the person filling in the form needs contribute access to
the library, and the approver would need contribute access to the workflow
tasks list.
The concern I have is who can read the forms once they're saved.
Take an 'application for leave' for example. It's highly likely that whoever
submits an application wouldn't want anyone else in the company to be able to
read their leave request, so it should only be readable to them and their
manager (and a group of people like HR)
Audience targeting wouldn't really work, as it's not secure. Views could work,
if there was a way to secure a view so that you can prevent people from
choosing another one. I'm not sure if item level security permissions would
work, and if you could set that up automatically in the workflow.
I recall reading somewhere in the not too distant past about someone
experiencing similar issues, but cannot for the life of me remember where it
was. I thought it was on this list, but can't seem to find anything (I blame a
HDD crash for that)
Does anyone have any tips / suggestions on how to proceed? (We're expecting at
least 30 forms to only be accessible by the submitter, approver and Group-X)
Kind regards
Nigel Hertz
Software Developer | Information Technology
Stockland
Level 25 | 133 Castlereagh Street | Sydney NSW 2000
T: 02 9035 2617 | F: 02 8988 2617
________________________________
Stockland Notice: If this communication has been sent to you by mistake, please
delete and notify us. If it has been sent to you by mistake, legal privilege
is not waived or lost and you are not entitled to use it in any way. Stockland
and its subsidiaries reserve the right to monitor e-mail communication through
its networks.
________________________________
Support procedure: https://www.codify.com/lists/support
List address: [email protected]
Subscribe: [email protected]
Unsubscribe: [email protected]
List FAQ: http://www.codify.com/lists/ozmoss
Other lists you might want to join: http://www.codify.com/lists
________________________________
Support procedure: https://www.codify.com/lists/support
List address: [email protected]
Subscribe: [email protected]
Unsubscribe: [email protected]
List FAQ: http://www.codify.com/lists/ozmoss
Other lists you might want to join: http://www.codify.com/lists
--------------------------------------------------------------------------------
Support procedure: http://www.codify.com/lists/support
List address: [email protected]
Subscribe: [email protected]
Unsubscribe: [email protected]
List FAQ: http://www.codify.com/lists/ozmoss
Other lists you might want to join: http://www.codify.com/lists
