So you might have figured out you can limit the number of characters in a textbox in InfoPath, but what if you have to limit the number of words someone types? This came up in one project because they were posting the words onto a PowerPoint slide. To do this you must use 'data validation' (InfoPath 2007) or a 'validation' rule (InfoPath 2010) and you will need to select 'the expression...' for your first dropdown in the conditions and type this:
string-length(.) - string-length(translate(., " ","")) > 60 (or the number of words you want)
What this does is pretty straightforward - it counts the number of typed characters in your field (assuming you are placing this rule on the field in which people type - that's the string-length(.) part) and then it subtracts the same number of characters but with all the spaces removed (they were removed by the translate function) and this checks to see if the total is greater than 60...if it is, then your validation rule will tell the user something's wrong because they done typed more than 60 words o_O. This goes on the assumption that every space represents a word...which should be pretty close. Have fun!
Helping regular people accomplish great things without programming using SharePoint, Office, and PowerShell.
Saturday, September 24, 2011
SharePoint 2010 Designer Workflow Error
Error: The server could not complete your request. For more specific information, click the details button. When you click the details button, the box is blank.
Our setup: Workflows with a total number of conditions greater than 10-12 would break no matter how complex or how you broke down the steps/conditions when publishing a workflow through Forefront UAG.
Explanation:
There are several causes to this problem that we found as we researched our solution. In many cases, having your SharePoint admin recycle the application pool or adding an 'execution timeout' attribute to workflows on the web.config file helped (esp. for workflows with approval steps). In our case, the problem was that our system has to pass through Microsoft's security server known as Forefront UAG (Unified Access Gateway) when publishing workflows. Your computer talks to SharePoint with requests and receives responses but has to go through the UAG middle man that inspects everything by unboxing it, reviewing it, and packaging back and sending it on its way to the recipient - but it will only tolerate so much information to look through. There was a setting in UAG called 'maximum http body size' I believe that, when doubled, allowed us to publish a slightly larger workflow. So, the administrator went in and altered the settings in UAG to tell it to stop looking at some of these very specific requests for workflow publishing and voila - we can publish workflows now!
For those UAG administrators, I believe you have to modify the trunk, go to the portal tab, and edit the 'do not parse the bodies of these requests' and add your web front ends using the FQDN and add the url pattern for whatever web services are being queried by SharePoint Designer when working with workflows (webs and lists maybe?). It is also noted in the documentation for SharePoint 2010 SP1 that you should also add those servers and the URLs for the lists and webs web services to the 'do not parse the RESPONSE bodies...' option as well.
Our setup: Workflows with a total number of conditions greater than 10-12 would break no matter how complex or how you broke down the steps/conditions when publishing a workflow through Forefront UAG.
Explanation:
There are several causes to this problem that we found as we researched our solution. In many cases, having your SharePoint admin recycle the application pool or adding an 'execution timeout' attribute to workflows on the web.config file helped (esp. for workflows with approval steps). In our case, the problem was that our system has to pass through Microsoft's security server known as Forefront UAG (Unified Access Gateway) when publishing workflows. Your computer talks to SharePoint with requests and receives responses but has to go through the UAG middle man that inspects everything by unboxing it, reviewing it, and packaging back and sending it on its way to the recipient - but it will only tolerate so much information to look through. There was a setting in UAG called 'maximum http body size' I believe that, when doubled, allowed us to publish a slightly larger workflow. So, the administrator went in and altered the settings in UAG to tell it to stop looking at some of these very specific requests for workflow publishing and voila - we can publish workflows now!
For those UAG administrators, I believe you have to modify the trunk, go to the portal tab, and edit the 'do not parse the bodies of these requests' and add your web front ends using the FQDN and add the url pattern for whatever web services are being queried by SharePoint Designer when working with workflows (webs and lists maybe?). It is also noted in the documentation for SharePoint 2010 SP1 that you should also add those servers and the URLs for the lists and webs web services to the 'do not parse the RESPONSE bodies...' option as well.
Monday, May 2, 2011
SharePoint 2010 Themes - changing fonts
I have to say a huge thank you to Randy Drisgill (@drisgill for twitter) for answering this situation for me. Basically, we had our administrator setup a new, default SharePoint 2010 site collection for us to use for testing. We decided to work on themes. We went to the Site Look n Feel and changed the fonts and colors...the color changes worked but the fonts would not change! Reason: v4master (the default masterpage for SP 2010) doesn't allow for themes to change the fonts! You have to switch the masterpage for your SP 2010 to nightandday or a custom masterpage that is setup to make fonts dynamic based on the theme. Just thought everyone should know. This could be a good thing to prevent users from changing fonts if you setup v4Master to use whatever default font you wish - but not so much for us.
Wednesday, March 23, 2011
Fixing crazy SharePoint permissions
Situation: SharePoint grew organically and we ended up with permissions craziness.
Desired Solution: Come up with a model for our permissions and then implement it.
Goals:
Desired Solution: Come up with a model for our permissions and then implement it.
Goals:
- Centralize the management of people's access to various lists/sites within a site
- Allow administrative assistant(s) to manage access for their subdepartments' users' access
- Allow the SharePoint support staff full access and control over everything
- Use SharePoint groups based on the roles of every user in the department and subdepartments
- Create an Excel spreadsheet of all the new groups and their assigned permissions on the different sites we have
- Create SharePoint Support Team group which will have full control of everything and have an email address attached to it so that users could contact them when needed
- Create a "SharePoint Group Managers" group that will "own" the other groups
- Set the owner of the SharePoint Group Managers to be the SharePoint support team
- Differentiate the proposed SharePoint groups and roles by how sensitive the position is
- All lower level position groups are managed by the SP Group Managers group and the higher level positions are managed by the SharePoint Support Team
- Create custom permission levels for this department
- Audit - Read + ability to create their own views
- Restricted Contribute - contribute without the ability to delete or create personal views
- Contribute without Views - well, it's contribute without personal views
- Reset permissions inheritance on the entire site and all subsites
- Work for a few hours and set all the groups with their appropriate permissions on each list/site. Many of our lists ended up with broken inheritance but quite a few didn't. We often set all users of a department as having read or a modified contribute on the site and just tweaked certain lists
- Go to the top-level site and edit the group quick launch so that all of the groups managed by the SharePoint managers are alphabetized and first before the groups managed by the SharePoint Support Team
- Give instructions to admin assistants/other group managers on how to manage the memberships of their groups (and noone but the SharePoint Support Team has full control on ANYTHING)
Wednesday, March 9, 2011
Outlook View Dynamic Date Filter
This is an oldie but a goodie. Refer to this article to see where I got this. Situation: I need to see emails that are older than 60 days in Outlook 2007 or 2010 so that I can delete them; so, I go in Outlook and I create a "view" of my inbox. If you haven't ever done this before, in 2010 you click your inbox and then click the "View" tab and click "View Settings" on the left. You will be presented with a box to modify your current view. I just click the Filter... button, click on "Advanced", choose "Date/Time Field" -> "Received" for the field to check; then I click "on or before" for the middle dropdown; and type in any date for the Value and click "Add to List". Then, go to the SQL tab and click the "Edit these criteria directly" checkbox. At the end of what displays should be your actual date in single quotes...delete that and replace it with today(S) where S is the number of seconds you would like to offset from today and this can be a negative number to go backwards. So, I calculated that 60 days is 5184000 seconds before today so my SQL tab used to look like this:
"urn:schemas:httpmail:datereceived" <= '1/1/2011 12:00 AM'
and by using today(S) I converted it into this:
"urn:schemas:httpmail:datereceived" <= today(-5148000)
And that's it. This will filter to only show items that are 60 days old or older.
"urn:schemas:httpmail:datereceived" <= '1/1/2011 12:00 AM'
and by using today(S) I converted it into this:
"urn:schemas:httpmail:datereceived" <= today(-5148000)
And that's it. This will filter to only show items that are 60 days old or older.
Wednesday, February 16, 2011
InfoPath Form Security Checklist / Flowchart
The following graphic should help most of you prevent many security issues with your InfoPath forms. To be fair, one particular piece of functionality requires a codeplex addon called "SPDActivities" that you may have to convince your SharePoint manager to implement (if he/she hasn't already) or else you would be in SP 2010 and use the impersonation step. These are the pre-requisites to this chart:
- Create the following permission levels -
- Audit - Copy read and add the ability to "View Usage Data", "Manage Personal Views", and "Enumerate Permissions"...this permission is used for directors and auditors to see everything and do some reporting.
- Restricted Contribute - Copy contribute and remove the ability to "Delete Items" and "Delete Versions" and "Manage Personal Views"...this is used for users who have to edit an infopath form and, with versioning turned on for the library, they can't delete the original version of the form.
- Add Only - Copy Read and add the ability to "Add Items"...this is used for users who have to submit a form and need no subsequent access to it (or you want to secure it at that point)
- Anonymous Users = users who don't login
- Always remember that those with Contribute permissions can easily switch to Explorer view or the Merge/Repair pages to view every form in your library...so, try not to ever give anyone contribute.
- A couple of these things will appear redundant - it's to doubly make sure you do them :)
Wednesday, February 2, 2011
Invalid or missing properties when saving an Office document
Sometimes you try to save an office document in SharePoint and it decides that it is missing some properties in something called the 'Document Information Panel'. This panel appears at the top of the Office client (Word, Excel, PowerPoint, etc) with the columns you have created within a document library for users to fill out key information ABOUT a document (often called document metadata) so that you can find that document in the future by using those columns. Here's the thing: when you see this error about missing or invalid properties - it usually means you filled out something incorrectly or there's something you forgot to fill out...but not in my case. In my case, I did a bad, bad thing and created a column called DocType. NEVER EVER CREATE A COLUMN WITH THE NAME OF DOCTYPE!!!! It will immediately give you an error aftter you create it that it cannot get the ContentTypeID and will never allow you to edit the column again.
So, I decide that I'm going to fix it by just hiding the column. Well, that makes it so that I get the lovely 'invalid or missing properties' error but then there's no property that I can actually fix! I found a post here: http://www.novolocus.com/2010/05/10/to-save-to-the-server-correct-the-invalid-or-missing-required-properties/ that shows that you can inspect your document within Office to remove Custom XML data and that that should fix the problem...it lets me then save the document. YAY! BUT....then I can't check the document back in. So, I HAVE to leave DOCTYPE as an optional column and just tell users not to fill it in. Moral of story - do NOT create a DocType column or you will see the following error messages:
'Object reference not set to an instance of an object. at Microsoft.SharePoint.ApplicationPages.BasicFieldEditPage.get_ContentTypeId()'
'To save to the server, correct the invalid or missing required properties.'
So, I decide that I'm going to fix it by just hiding the column. Well, that makes it so that I get the lovely 'invalid or missing properties' error but then there's no property that I can actually fix! I found a post here: http://www.novolocus.com/2010/05/10/to-save-to-the-server-correct-the-invalid-or-missing-required-properties/ that shows that you can inspect your document within Office to remove Custom XML data and that that should fix the problem...it lets me then save the document. YAY! BUT....then I can't check the document back in. So, I HAVE to leave DOCTYPE as an optional column and just tell users not to fill it in. Moral of story - do NOT create a DocType column or you will see the following error messages:
'Object reference not set to an instance of an object. at Microsoft.SharePoint.ApplicationPages.BasicFieldEditPage.get_ContentTypeId()'
'To save to the server, correct the invalid or missing required properties.'
Subscribe to:
Posts (Atom)