Out of the box, anonymous access is a pretty cool idea but breaks several things. Just to help those who may think about anonymous access (defined as users that don't login at all on something), here is a list of things that are altered:
1. Workflows - worfklows that are set to automatically run when you create a new item will break if you turn on anonymous access. Not only will the workflow not run, but here's what will typically happen: a user will click "new", fill out your sharepoint form, and then they click OK. When they do, they get an error message saying that there is a Server Out of Memory and think that something went wrong, so they try to fill it out again. What the anonymous user DOESN'T know is that their information WAS submitted but the workflow didn't run. The error message that they saw was in regard to the workflow. If this happens, the primary way people are fixing it is to create a new list as a copy of the current list, copy all the data over from the old list to the new one, and delete the old list. You CANNOT just delete the workflow...certain pieces of the workflow are not deleted when you delete a workflow and THOSE are the things that are breaking the workflow. Some people have figured out another solution but this seems to be the main way to fix it.
2. Surveys - SharePoint surveys are already a very limited template but they get further limited with anonymous access in that you cannot use branching logic, page breaks, or limiting people to only filling out a survey 1 time. This doesn't mean it's not useful, it's just very limited in its applications.
3. Libraries - Anonymous users are not meant to access libraries, so just get that out of your head now. Technically, you can use a URL hack to allow them access but they won't be able to add and upload documents or anything.
4. InfoPath Forms - anonymous users can't access infopath forms unless you have forms-based authentication (which supplies a default username/password if none exists when you turn on anonymous access).
5. Edit or Read Your Own - these settings typically only allow someone to see or edit their own stuff...well, this is impossible with anonymous users because there's no way to tell one anonymous user from another and, thus, it will not show anything for anonymous users. This can sometimes be a benefit and other times a problem.
That's all for now; if you find anything else, please let me know and I'll throw it up here.
Helping regular people accomplish great things without programming using SharePoint, Office, and PowerShell.
Friday, July 30, 2010
Friday, July 16, 2010
Input Mask in InfoPath fields - entering phone numbers and emails
If you have a field in InfoPath where people are supposed to put in their email addresses or a website or phone number - you may have asked whether or not we can double-check that they put it in in a certain way (e.g. a phone number has to be entered in the format (123)555-7899. There is a way to make this happen - even in browser forms - using something called Regular Expressions. You won't see the phrase "regular expression" in InfoPath but you will see something like "matches pattern" or "does not match pattern" - which are regular expressions. Here's the basic way they work:
Using either Conditional Formatting or Data Validation in your InfoPath form, you should have [Field1] [Does not match pattern] [some pattern goes here] - and the action or tooltip should either disable/hide the control or have a message stating something like "Please type your information in the correct format". Patterns use the following building blocks:
0. If you want to have a symbol for any letter: \p{L}
1. If you want to have a symbol for any character (letter, number, or symbol): . (yes, that's a period)
2. If you want to have a symbol for any digit: \d
3. If you want to use a period, parenthesis, or dash symbol: \. or \( or \-
4. If you want one of the above to be used a certain number of times, you can use an *, a +, or a ? but they must go AFTER the thing you want to be only used a certain number of times. * = 0 or more of that thing (e.g. \d* means either no digit up to a huge number - as big as you want). + = at least 1 or more of that thing (e.g. \d+ means at least 1 digit but can get to be as big as you want). ? = 0 or 1 of that thing (e.g. \d? means either a single digit or nothing).
So, how does this help you with making people enter phone numbers or emails correctly? Here's what the patterns should look like:
(for phone numbers): \d?\(\d\d\d\)\d\d\d\-\d\d\d\d
Notice how there's that optional digit at the beginning for the USA country code? Obviously, international numbers will be a bit more complicated, but this will make people type in their phone numbers as 1(123)456-7899 or (123)456-7899 - depending on if they want a country code.
For email addresses:
.+@.+\.\p{L}\p{L}\p{L}?\p{L}?
RELATED POST: I have another post about this in regard to limiting the number of characters people are able to type in MULTI-line fields (if you have a regular textbox, there's an easy option to limit the number of characters on the Display tab...but NOT so if you choose to make that textbox multi-line): Limit number characters in multi-lines of text InfoPath fields
Using either Conditional Formatting or Data Validation in your InfoPath form, you should have [Field1] [Does not match pattern] [some pattern goes here] - and the action or tooltip should either disable/hide the control or have a message stating something like "Please type your information in the correct format". Patterns use the following building blocks:
0. If you want to have a symbol for any letter: \p{L}
1. If you want to have a symbol for any character (letter, number, or symbol): . (yes, that's a period)
2. If you want to have a symbol for any digit: \d
3. If you want to use a period, parenthesis, or dash symbol: \. or \( or \-
4. If you want one of the above to be used a certain number of times, you can use an *, a +, or a ? but they must go AFTER the thing you want to be only used a certain number of times. * = 0 or more of that thing (e.g. \d* means either no digit up to a huge number - as big as you want). + = at least 1 or more of that thing (e.g. \d+ means at least 1 digit but can get to be as big as you want). ? = 0 or 1 of that thing (e.g. \d? means either a single digit or nothing).
So, how does this help you with making people enter phone numbers or emails correctly? Here's what the patterns should look like:
(for phone numbers): \d?\(\d\d\d\)\d\d\d\-\d\d\d\d
Notice how there's that optional digit at the beginning for the USA country code? Obviously, international numbers will be a bit more complicated, but this will make people type in their phone numbers as 1(123)456-7899 or (123)456-7899 - depending on if they want a country code.
For email addresses:
.+@.+\.\p{L}\p{L}\p{L}?\p{L}?
- See the first period means at least 1 character or more but can be any size. This works great to make sure they at least type something but it could be anything like jdoe or bob or super_director.
- The @ symbol doesn't need anything special so you can just type it.
- The \p{L}+ means at least 1 character but as many as you need to type your domain like gmail or aol or hotmail or yourcompany
- The period needs that slash in front of it because periods do other things in regular expressions
- After the period, there are two \p{L} because almost every ending to an email will have at least 2 letters (e.g. .us, .com, .net, .info, .gov, .edu, .org, etc.)
- The last two \p{L}'s are followed by a question mark to mean that they are optional but that the most you can have is 4 letters.
RELATED POST: I have another post about this in regard to limiting the number of characters people are able to type in MULTI-line fields (if you have a regular textbox, there's an easy option to limit the number of characters on the Display tab...but NOT so if you choose to make that textbox multi-line): Limit number characters in multi-lines of text InfoPath fields
Thursday, July 8, 2010
SharePoint Permissions Architecture - Part 2
So, what structure should you use? Well, the structure needs to match the needs of your organization. [Edit: Where that can get tricky is whether or not you want to structure things in your SharePoint environment like you do in your organization...if you have a bad structure in your organization, SharePoint may give you a chance to "fix" it for those using SharePoint. The following assumes a decent structure and you will notice that we are NOT talking about navigation here.] Here's a general solution that I like:
1. Grab an organization chart for your entire organization [Edit: or a functional chart for your organization (org chart will probably break down by department; functional chart would break down more by the roles or maybe the purpose of sets of departments and may be easier for users to understand)]
2. Have the SharePoint admin create site collections for each major division within your company
3. Create SharePoint sites for each major department
4. Create SharePoint sites INSIDE those sites for each sub-department
5. Start at the top and create SharePoint groups for each and every level (create a group per site collection, another per upper sites, and another for each of the subsites)...so every site has its own group. These are your broad team groups and you should place any Active Directory groups for these inside the appropriate SharePoint group. This makes managing the entire team a little easier on the SharePoint end because if someone changes departments or leaves or is a new-hire then they are updated in Active Directory (which updates their sharepoint permissions automagically). [Edit: Note: if you use multiple site collections as I'm implying, you may want to use more Active Directory groups for those that need to reuse groups across site collections. If it's an occasional thing, just create the group on each site collection since groups are specific to the site collection.]
Group Owners: every group has an owner but you can use other groups to own or manage groups (manage being adding and removing people from groups). Depending on your needs, it is generally best to have one "Group Managers" group at each site and subsite level that is in charge of all groups within the site but does NOT have ANY permission to do ANYTHING else but manage the groups. This will require some custom permission levels but it's not too bad to setup and doesn't require code or anything. So, who "manages" the "Group Managers" group? That should be the closest SharePoint Manager group's job unless there is a specific department or systems administrator that is responsible for managing all permissions similar to an Active Directory permissions setup. In my job, there is a department responsible for supporting sharepoint and, thus, we are pushing for that team to manage all of these "group manager" groups AND any "SharePoint manager" groups but then have all the smaller/more specific groups be maintained by those in the "group manager" groups. Yes, I know this is prose for a tongue twister, leave a comment if you want clarification.
Group Membership viewable to everyone? Typically, it is best and easiest to make it so that everyone can view the membership of the group (everyone can see who's in what group). This makes for better accountability as well as easier communication when needing to find someone who resides in a group. This isn't always the case (especially in larger companies and places where special, exclusive groups where only those in the group can know who's in the group.
Directors: Directors are special. Typically, directors and those in higher positions are so busy that they don't have time to learn new technologies like SharePoint, so, typically Directors ought to have the ability to read/view everything within the site/subsite and that's ALL.
Telling Directors they get read only: Yea, go ahead, tell your director he gets read-only rights to the site...I'm waiting, give that a try and see how it goes. Here's the solution: you can create permission levels like Read Only (there's already a Read so no worries there) but you could copy READ and make your own called "Director-level" or "Audit" permissions...just make sure you check all permissions under "Personal Permissions" which allows them to create their own views and webparts as well as "enumerate permissions" to list all the permissions on something so they can contact those who "own" a list or site as necessary. This will satisfy their ability to access all information, generate their own dashboards and reports for the information, and they don't have to have the ability to royally screw up SharePoint by going click-happy.
Directors who know SharePoint: So, what happens when you get a director who happens to know SharePoint or learns it real fast and becomes a decent guru at it? Simple, add him to the Director group AS WELL AS the SharePoint Manager group for that level.
Teams who are cross-department or cross-functional: Simple again, just don't create a million groups for them, create the few that works internally for their department and give the appropriate groups permissions to your department info. That's the beauty of SharePoint groups...once they are created for their team, you can reuse them across the site collection (notice, to create groups that reach across all site collections, then the groups have to be createdat the root level of SharePoint, often called the Web Application or Web [Edit: in Active Directory instead of SharePoint since SharePoint groups don't reach across site collections).
If you find any other typical exceptions to these that are worth noting, please let me know and I'll add them to the list. Hopefully, this gets you started on a permissions plan.
1. Grab an organization chart for your entire organization [Edit: or a functional chart for your organization (org chart will probably break down by department; functional chart would break down more by the roles or maybe the purpose of sets of departments and may be easier for users to understand)]
2. Have the SharePoint admin create site collections for each major division within your company
3. Create SharePoint sites for each major department
4. Create SharePoint sites INSIDE those sites for each sub-department
5. Start at the top and create SharePoint groups for each and every level (create a group per site collection, another per upper sites, and another for each of the subsites)...so every site has its own group. These are your broad team groups and you should place any Active Directory groups for these inside the appropriate SharePoint group. This makes managing the entire team a little easier on the SharePoint end because if someone changes departments or leaves or is a new-hire then they are updated in Active Directory (which updates their sharepoint permissions automagically). [Edit: Note: if you use multiple site collections as I'm implying, you may want to use more Active Directory groups for those that need to reuse groups across site collections. If it's an occasional thing, just create the group on each site collection since groups are specific to the site collection.]
6. For each site collection and site, create groups for each position that resides at this level (President group, VP group, CIO group, CEO group, etc.). These groups will typically only have 1 person in them because we will base our groups off of roles people play (or their position) within the company. At the higher levels, individuals fill certain roles while, near the bottom, vast groups of people comprise the teams that all have practically the same role/position within the company.
7. For each site, create similar groups for each level within a department (Dept 1 Director, Dept 1 Manager, etc.)
8. For each subsite, create groups for the slightly more specific positions (Dept1SubDept1 Manager, Dept1SubDept1 Supervisor, Dept1SubDept1 Senior Team, Dept1SubDept1 Team, etc.).
9. You might be wondering: "Why create a group for one guy?" - Answer: because you give that group permissions to multiple things...and later on, when that one guy moves around in the company, you don't have to go fix EVERYTHING he had access to...you just have to update the group and swap people out.
A couple of key things to note about this:
SharePoint Managers group: there ought to be SharePoint managers groups for each level so that those who have to manage SharePoint (and are in a trusted position) can do so...often, you can have SharePoint managers for each major department (sometimes you're lucky enough to have them for subdepartments) but give them full control of everything. There may be instances where they cannot have access to something - that should be stored either outside SharePoint or the list/library setup with custom permissions and (after it's all working) remove the SharePoint Managers group from it. Obviously, these should only be your departments' SharePoint gurus. The owners of SharePoint Managers groups should be a higher-level SharePoint Managers group.Group Owners: every group has an owner but you can use other groups to own or manage groups (manage being adding and removing people from groups). Depending on your needs, it is generally best to have one "Group Managers" group at each site and subsite level that is in charge of all groups within the site but does NOT have ANY permission to do ANYTHING else but manage the groups. This will require some custom permission levels but it's not too bad to setup and doesn't require code or anything. So, who "manages" the "Group Managers" group? That should be the closest SharePoint Manager group's job unless there is a specific department or systems administrator that is responsible for managing all permissions similar to an Active Directory permissions setup. In my job, there is a department responsible for supporting sharepoint and, thus, we are pushing for that team to manage all of these "group manager" groups AND any "SharePoint manager" groups but then have all the smaller/more specific groups be maintained by those in the "group manager" groups. Yes, I know this is prose for a tongue twister, leave a comment if you want clarification.
Group Membership viewable to everyone? Typically, it is best and easiest to make it so that everyone can view the membership of the group (everyone can see who's in what group). This makes for better accountability as well as easier communication when needing to find someone who resides in a group. This isn't always the case (especially in larger companies and places where special, exclusive groups where only those in the group can know who's in the group.
Directors: Directors are special. Typically, directors and those in higher positions are so busy that they don't have time to learn new technologies like SharePoint, so, typically Directors ought to have the ability to read/view everything within the site/subsite and that's ALL.
Telling Directors they get read only: Yea, go ahead, tell your director he gets read-only rights to the site...I'm waiting, give that a try and see how it goes. Here's the solution: you can create permission levels like Read Only (there's already a Read so no worries there) but you could copy READ and make your own called "Director-level" or "Audit" permissions...just make sure you check all permissions under "Personal Permissions" which allows them to create their own views and webparts as well as "enumerate permissions" to list all the permissions on something so they can contact those who "own" a list or site as necessary. This will satisfy their ability to access all information, generate their own dashboards and reports for the information, and they don't have to have the ability to royally screw up SharePoint by going click-happy.
Directors who know SharePoint: So, what happens when you get a director who happens to know SharePoint or learns it real fast and becomes a decent guru at it? Simple, add him to the Director group AS WELL AS the SharePoint Manager group for that level.
Teams who are cross-department or cross-functional: Simple again, just don't create a million groups for them, create the few that works internally for their department and give the appropriate groups permissions to your department info. That's the beauty of SharePoint groups...once they are created for their team, you can reuse them across the site collection (notice, to create groups that reach across all site collections, then the groups have to be created
If you find any other typical exceptions to these that are worth noting, please let me know and I'll add them to the list. Hopefully, this gets you started on a permissions plan.
Tuesday, July 6, 2010
SharePoint Permissions Architecture - Part 1
SharePoint is a bit of a beast when it comes to managing access to sites, lists, and libraries. To plan out many of these involves discussions on every major layer of a company and their various needs. The building blocks of a Permissions architecture are the following:
1. Users -> Users are defined using Active Directory (a server that is like a giant contact list for your company...it holds who you are, what dept you are in, your password, phone number, etc.).
2. Active Directory Groups -> In Active Directory, groups can be made so that you can work with people as chunks instead of individuals. This is a great help when it comes to thousands of people being involved in your company...who wants to manage them all individually!?
3. SharePoint Groups -> Active Directory groups are more common as larger groups of people. At a school, for instance, there might be groups for Faculty, Staff, and Students (amongst others). There might even be groups broken out by department. Often there is a need for more specific groups when it comes to sharepoint or even a mixture of multiple groups. So, SharePoint will let us create our own groups of people (and you *can* include AD groups INSIDE or AS A PART OF a sharepoint group).
---
4. Types of Authentication - what does Authentication mean? It means how your company verifies your username and password so that only you can access what you are supposed to (keeps other people out of your business ^_^). There are several types between SharePoint 2007 and 2010 but these are usually set by your company's IT department and not something you generally have control over. A couple of examples include: Forms-Based Authentication (whenever you try to go into SharePoint or Webmail or some other Microsoft-based stuff, you get a webpage that asks for your username and password and then sends you to the webpage you were trying to go to) and Windows Authentication (pops up with a login box for you to type your username and password - and often a domain - and it logs you in and takes you to your page...though, you often have to log in again if you try to go to another system like Webmail, depending on how your company has set things up). 2010 introduces a new type of authentication called Claims-based authentication, look it up on google for a fun read, but is sort of a hybrid of multiple authentication types.
---
5. 3 layers of access in SharePoint - there are 3 primary places where permissions can be set: the Site (giving access to an entire webpage), the list (you can set specific permissions on all the lists or some of the lists in a particular site), and the item (items INSIDE a list can have their own permissions set so that certain people can't see certain items...great for manager-only items in a public location but SHOULD BE AVOIDED if at all possible).
6. SharePoint Permissions Inheritance - SharePoint's permissions are connected and automatically set (and updated) by the level above whatever you are looking at (see the levels in the previous point). If you make a change at that uppermost level, all things underneath it reflect that same change and you are only allowed to edit the Site level. This works great in an ideal world - and you might be able to get some leverage out of this on occasion, but there are too many reasons to customize permissions for a certain list or library.
So, that's it for now, the next post will explain how to arrange your building blocks into a decent permissions standard for the organization. Mind you, there is no one-size-fits-all solution for permissions architecture but this one will get you started thinking along those big-picture lines of permissions.
1. Users -> Users are defined using Active Directory (a server that is like a giant contact list for your company...it holds who you are, what dept you are in, your password, phone number, etc.).
2. Active Directory Groups -> In Active Directory, groups can be made so that you can work with people as chunks instead of individuals. This is a great help when it comes to thousands of people being involved in your company...who wants to manage them all individually!?
3. SharePoint Groups -> Active Directory groups are more common as larger groups of people. At a school, for instance, there might be groups for Faculty, Staff, and Students (amongst others). There might even be groups broken out by department. Often there is a need for more specific groups when it comes to sharepoint or even a mixture of multiple groups. So, SharePoint will let us create our own groups of people (and you *can* include AD groups INSIDE or AS A PART OF a sharepoint group).
---
4. Types of Authentication - what does Authentication mean? It means how your company verifies your username and password so that only you can access what you are supposed to (keeps other people out of your business ^_^). There are several types between SharePoint 2007 and 2010 but these are usually set by your company's IT department and not something you generally have control over. A couple of examples include: Forms-Based Authentication (whenever you try to go into SharePoint or Webmail or some other Microsoft-based stuff, you get a webpage that asks for your username and password and then sends you to the webpage you were trying to go to) and Windows Authentication (pops up with a login box for you to type your username and password - and often a domain - and it logs you in and takes you to your page...though, you often have to log in again if you try to go to another system like Webmail, depending on how your company has set things up). 2010 introduces a new type of authentication called Claims-based authentication, look it up on google for a fun read, but is sort of a hybrid of multiple authentication types.
---
5. 3 layers of access in SharePoint - there are 3 primary places where permissions can be set: the Site (giving access to an entire webpage), the list (you can set specific permissions on all the lists or some of the lists in a particular site), and the item (items INSIDE a list can have their own permissions set so that certain people can't see certain items...great for manager-only items in a public location but SHOULD BE AVOIDED if at all possible).
6. SharePoint Permissions Inheritance - SharePoint's permissions are connected and automatically set (and updated) by the level above whatever you are looking at (see the levels in the previous point). If you make a change at that uppermost level, all things underneath it reflect that same change and you are only allowed to edit the Site level. This works great in an ideal world - and you might be able to get some leverage out of this on occasion, but there are too many reasons to customize permissions for a certain list or library.
So, that's it for now, the next post will explain how to arrange your building blocks into a decent permissions standard for the organization. Mind you, there is no one-size-fits-all solution for permissions architecture but this one will get you started thinking along those big-picture lines of permissions.
Monday, July 5, 2010
Tip for displaying the HOUR only in Excel
Situation: you have pulled some date/time data from another source (in my case SharePoint) but don't know how to group/aggregate the data so that you can determine which hour of the day had the most entries. Grouping itself tends to be a little messy in Excel and requires a decent amount of work to separate all the pieces out by you. Here's a nifty little formula that uses just nested IF statements to determine what hour of the day (in military time) the event occurred so you can then run functions like the average number of entries or the total of them - and H2 happens to be the cell where my date/time value was located:
=IF(AND(VALUE(H2)>=0.33,VALUE(H2)<0.375),"08",IF(AND(VALUE(H2)>=0.375,VALUE(H2)<0.4167),"09",IF(AND(VALUE(H2)>=0.4167,VALUE(H2)<0.4583),"10",IF(AND(VALUE(H2)>=0.4583,VALUE(H2)<0.5),"11",IF(AND(VALUE(H2)>=0.5,VALUE(H2)<0.5417),"12",IF(AND(VALUE(H2)>=0.5417,VALUE(H2)<0.5833),"13",IF(AND(VALUE(H2)>=0.5833,VALUE(H2)<0.625),"14",IF(AND(VALUE(H2)>=0.625,VALUE(H2)<0.6667),"15",IF(AND(VALUE(H2)>=0.6667,VALUE(H2)<0.7083),"16")))))))))
This is based on these calculations (they ARE rounded so you may have to tweak them ever so slightly):
8am = .33
9am = .375
10am = .4167
11am = .4583
12pm = .5
1pm = .5417
2pm = .5833
3pm = .625
4pm = .6667
5pm = .7083
=IF(AND(VALUE(H2)>=0.33,VALUE(H2)<0.375),"08",IF(AND(VALUE(H2)>=0.375,VALUE(H2)<0.4167),"09",IF(AND(VALUE(H2)>=0.4167,VALUE(H2)<0.4583),"10",IF(AND(VALUE(H2)>=0.4583,VALUE(H2)<0.5),"11",IF(AND(VALUE(H2)>=0.5,VALUE(H2)<0.5417),"12",IF(AND(VALUE(H2)>=0.5417,VALUE(H2)<0.5833),"13",IF(AND(VALUE(H2)>=0.5833,VALUE(H2)<0.625),"14",IF(AND(VALUE(H2)>=0.625,VALUE(H2)<0.6667),"15",IF(AND(VALUE(H2)>=0.6667,VALUE(H2)<0.7083),"16")))))))))
This is based on these calculations (they ARE rounded so you may have to tweak them ever so slightly):
8am = .33
9am = .375
10am = .4167
11am = .4583
12pm = .5
1pm = .5417
2pm = .5833
3pm = .625
4pm = .6667
5pm = .7083
Subscribe to:
Posts (Atom)