I have a custom action in a workflow and would like to report an error to the user when something goes wrong. What's the best way of doing that?
UPD: Ideally I would like to put the workflow in the error state and log a message to the workflow log. That doesn't seem possible. What's the closest I can get to it? I want to a reusable solution,something that's easy for users to set up when using my custom action in SharePoint Designer.
Added more details to the question.
#mauro that takes care of storing the error, but how do I display the error to the user in a way which makes sense?
#AdamSane That's seems like a rather fragile solution. It's not a matter of setting this up once on a single site. I need something others can add using SPD.
when you throw the error your error handler can then email the user, or better if the list is massive, add the error state to the workflow item - i think this is default functionality though as the error would be mentioned there.
http://www.sharepointsecurity.com/blog/sharepoint/sharepoint-2007-development/fault-handling-in-sharepoint-workflows/
Personally I would log it to either a log file or the event log depending on the issue. I think storing it using a users permissions would be a bad idea, what happens if that user does not have the correct rights? or worse still they get elevated permissions by browsing the list in explorer view?
The log file would be the best way, that way you rely only on the file system being available - you dont have to worry about trapping errors happening whilst connecting to the database etc.
Mauro
Add the error to a hidden list with that users name. Set the visibility on the list (for users) to only read/write their own values. Then use a custom web part or FlexListViewer to view the contents of that list and display it to the user. Once they acknowledge that error, remove it from the list.
If necessary, you can add a different workflow action on that message list, that says pause for 2 days and then email. Whatever, depending on your requirements.
Otherwise you can have a custom db table that you use for pretty much the same thing, this way sharepoint does most of the work for you.
Update This can be packaged up as a feature and deployed to each site as needed. The strengths of this approach (adding a list item to a list, querying, alerting a user, and emailing a user) are all built into the sharepoint itself. In this case you can focus on your custom logic only, while letting sharepoint focus on the implementation details.
If you need the user to take some action as a result of the error (e.g. retrying the workflow) is it possible to create a task for that user with information on the error and the location of the workflow?
Related
We have a (super)user who has been using VBA in an Excel spreadsheet to create and manipulate documents in a Domino database application.
The user has 'Editor' access to the application, and should normally be able to create/edit the document contents.
They have been, however, creating documents using VBA. That logic doesn't consider such important document fields as Readers, Authors, etc. .
We would like to restrict access to all Domino data so that it can only be created/modified using an IBM Notes client.
I have tried looking through the ECL, but that only restricts what 'others' do.
Since he has his Notes client available, the external logic is using his normal Notes credentials.
I have tried setting a hidden field with the Notes client and looking for that in the QuerySave event of the form design.
Unfortunately, the external code pays no attention to the form events and the save is executed despite the missing field.
Similarly, the Database Script has no bearing on the execution of external logic.
I was going to inspect the client version upon database open and restrict activity based on a variance in the version (I was hoping!).
I have de-selected the 'Don't prompt for a password...' option in the user security preferences, but that has no effect at all (suspected as much!).
The ONLY thing I have been able to suggest is to hide the database design... That's really only designed to thwart a user's efforts to understand the underlying design.
It won't prevent them from creating hundreds of thousands of documents with a fictitious form and throwing the app into disarray.
I'm hoping that there is a solution out there that I'm missing.
The user has been instructed not to undertake such activity in the future.
We were lucky that there really wasn't any malicious intent - "Just trying to be more efficient" we're told.
The effects of the activity have been remedied, and the user has been warned.
What I want to know is... how can I prevent this from ever happening again?
The circumstances are rare I know, but I would've thought there'd be a means of restricting the platforms used to manage Notes/Domino data.
Is there a way to ensure no external applications are able to access, create or modify Notes database documents?
I am currently focussing on access to Notes via COM.
I thought that, if I unregistered 'nlsxbe.dll' from the registry, that would prevent such activity - It has not.
I also tried removing the .TLB files from the Notes executable folder - removal of 'notes32.tlb' and 'domobj.tlb' have no effect at all. Removal of 'ltsci3.tlb' screws everything up (as expected!).
I'm really having no luck at all - Any/all suggestions would be most appreciated!
I'm not aware of any way to detect that a connection has been made by standalone code instead of by the Notes client, but you do have two paths available to you:
A Domino server add-in that prevents documents from being saved in that particular database if certain criteria aren't met.
An agent that is triggered to run shortly after documents are saved or modified in that particular database. The agent code can delete (or modify, if you prefer) the documents that don't conform to the required criteria.
The server add-in route would normally require coding in C, but thanks to the Open NTF Trigger Happy project, the hard part is done for you, and the rest can be filled in with either LotusScript or Java agent code that is "triggered" by the pre-written C code. You will need to have some basic knowledge of how the Notes Extension Manager interface works, but once you get past that and write your agent code to enforce your data consistency/integrity requirements, the only real hurdle is your willingness to host open source code on your server.
There may be two other possibilities, but I can't say if either will solve or deal with the issue...
In the ECL you can disable 'COM' access for the user (also known as OLE or ActiveX) automation since VBA access is usually via COM. This has stopped Notes using external COM access for me, but I don't know if also prevents VBA using Notes. Additional steps may be needed to enforce the ECL and apply to the specific users.
There is an (old) notes.ini 'DisableExternalApps' (or something similar) that disables some external access. This can affect many things (DDE/Prompts/#dblookups) but again I don't know if this will disable VBA/COM and its not user specific, but server wide.
I would have thought that removing the nlsxbe.dll or restricting access to execute it might work, but the ECL may be the best bet.
Alternatively, rather than add hidden flags to your design (and the documents), and then delete the offending documents, your agent could apply the correct author/reader fields to the documents instead.
Very tricky. Did you find a better solution?
We have created some views that show activities assigned either to the current user OR any of the user's teams. The filtering was fairly simple:
Related Activity Parties
- Party equals current user
OR
- Party equals current user's teams
This works great if the user is a member of any team that's not the default. However, if the user is not a member of any team, the view throws an ugly error and doesn't show anything. The error log says "user is not a member of any teams".
I've been playing around with filters, and there seem to be alternative ways to get something similar, but nothing is quite exactly the same. If only there was more flexibility to use the OR and AND groupings.
So, has anyone run into similar issues? I'm thinking about editing the view XML directly, because then I can or/and filters freely and I'd be able to get exactly what I want. However, I'm not sure how well that all works and how would it look if you tried to edit the view in CRM after it was changed directly in XML.
I can confirm for you that this is an issue in CRM 2011 (still an issue as of Rollup 14.) Wish I had an easy solution. Lazy way around it is to create a do-nothing team, with no security role assigned, and just put every user in it. This is a work-around, not a solution, but it will make the issue go away. Not 'elegant' but it works.
The alternative, as you suggest in your post, is writing custom FetchXML for each query you need this on but that defeats much of the benefit of the Advanced Find Query tool and makes long term maintenance and administration more difficult.
I am currently working on a custom SharePoint web part (WSS 3.0, not MOSS) that will pull in information for all of the users in Active Directory to build an up to date employee directory. This web part shows things like phone number, address, and other similar fields. The issue that I am having is that, by default, the SharePoint web site on IIS is running as the user IUSR_. This user does not have access to Active Directory, so I am unable to retrieve any user information.
To get around this for testing I have hard coded the credentials for a test user which I added just for this purpose. This, obviously, is not ideal. If anyone removes this user or if they ever change the password then the web part will break and they will have no way to fix it (they have no in-house developers to take it over once I am finished here). To fix this problem, I would like to make the Username/Password custom properties on the web part so I can pass those to Active Directory to retrieve the information I need. The issue I am having with this is that the password is stored in plain text so anyone can read it. I would like it to display as ******** or something similar. Is there a way to make a custom property on a web part a password type?
If this isn't possible, can anyone recommend another way to accomplish what I am trying to do? At this time I cannot change the user that the SharePoint website runs as. Although, if I cannot find any other solutions I will try again to persuade them.
Thanks in advance!
We use a service account for that. That service account is solely used for that. Something like DOMAIN\SPS_AD_READ_CUSTOMER
In our documentation that we deliver when putting the application in production that account is put in the list of stuff that is needed to make the webpart run. If the webpart ever fails, the ITPro can go to the chapter and check if everything is still ok.
It's not ideal, but I don't really know another way on how to fix it.
I would go with custom Editor Part, then set up a control of TextBox with property TextBoxMode set to Password, then override methods from type EditorPart - SynchChanges() and ApplyChanges() to set and retrieve values.
tip: override method CreateEditorParts of a WebPart type to start with.
I have a case where if a SharePoint site owner decides to break permissions inheritance and directly manage site membership, I'd also like to correspondingly modify view permissions on items in a specific list in the top-level site.
How can I best catch those changes so I know when to apply the appropriate changes to the list items?
I'd like to have some C# code be notified when a site's permissions are changed so I can programmatically modify the appropriate list item permissions.
The best way to do this (unfortunately) is to periodically query all of the sites and check to see if inheritance is disabled. I had a similar problem and used powershell scripting to create a report on site security. If you haven't used Powershell before, don't be intimidated. The syntax is VERY similar to C#.
You can use SharePoint auditing to monitor permission changes. It will track changes down to item level. The downside is that you have to turn this feature on and it will hurt performance somewhat.
As for notification, I don't think auditing tells you about changes. I'm pretty sure you would need to poll the audit log.
There's heaps of information about auditing in this article on MSDN.
Another approach which I think might do a very good job of this is to use the SharePoint ChangeLog. Bascially, this is used by SharePoint during indexing, with the log telling the gatherer exactly what has changed, and what should be indexed during an incremental crawl.
When you have a permission change, then this should be picked up during an incremental crawl. The ChangeLog has specific parameters that can be passed to identify changes to permissions. Take a look here at the SPChangeQuery Class:
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spchangequery.aspx
Specifically you can look for ChangeTypes:
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spchangetype.aspx
Including:
AssignmentAdd
AssignmentDelete
MemberAdd
MemberDelete
...and more
We are using the default Task list from a Team Site and would like to only allow those that the Task is "Assigned To" to edit the tasks. How do you go about enforcing this?
When we tried the "Advanced Settings", we found that "Only their own" meant only those tasks created by the current user.
It looks like you need to create an event handler that updates the permission on the Task everytime the assigned user is changed.
Quite a few people have had this problem in the past.
Check out this site for an example of the problems people have had. That said it should work out-of-the-box if you copy content when setting up the Task List.
Looks like, an event handler is the way to go. I found this page in some of my searching and it explains a lot of the problems related to this issue:
Email Notifications and Alerts - Sharepoint Tasks List
Unfortunately, the client wants no custom code and wanted SP Designer workflows and browser based customizations only...