Wednesday, June 2, 2010

Forms Authentication

Form Based Authentication in SharePoint

(A Step Wise Implementation of FBA in SharePoint)
Here I’m adding this article to implement and extend the existing portal and have accessibility using Form Based Authentication. The article below has step wise implementation from scratch.
--
1. Create SQL Database: using Visual Studio 2005 command Prompt.

2. Use command : ASPNET_REGSQL



3. Please Select “ Configure SQL Server for Application Services”
4. Enter the Server Name Authentication and the Database Name

(Please Add the Database Name of our choice :ex-newFBADatabase)

5. Continue till > finish.
6. Check Newly Created Database containing necessary tables and store procedures


7. Extend your web application in any of the prescribed zone (Internet, intranet, extranet, Custom)

a. The original web application is at port 333 (in this case).
b. We have extended to port 332 as shown and selected the zone as extranet.


8. Now In visual Studio (VS) create a web site and add following entries in web.config file.
















maxInvalidPasswordAttempts="5" minRequiredPasswordLength="1" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10" passwordStrengthRegularExpression="" name="FBADemoMember"
type="System.Web.Security.SqlMembershipProvider,System.Web,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a" />










type="System.Web.Security.SqlRoleProvider,System.Web,Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a" />







9. Select website > ASP.NET configuration in VS



10. Select Security hyperlink



11. Create Roles as needed.






12. Create Roles (Inside Create or Manage Roles)



13. Create Users
14. Create Users(Inside Create Users)




(~) From Central Administration
15. Select Authentication Provider in Application Security in central admin



16. Select the Web Application and select the extended Zone for FBA.


17. Select Authentication Type :
a. FORMS,
b. Membership Provider Name : same membership defaultProvider as in web.Config
c. similarly for Role Manager Name: roleManager defaultProviderd.

Enable Anonymous Access optional (depends on requirement)




18.Now Update the Extended Web Application Web.Config Place beneath <>tag in both (original and extended web application) web.config file. Also place & beneath in conjunction with connection string as shown below.



19. Add the FBA User in the original portal/Web Application through People and Groups.


20. Add user in the Defined Role/Groups As you can observe here the user will be present as FBADemoMember:

21. Now Login in the extended Site.
22. Bingo- Welcome the FBA users.


Thanks…..

Sharepoint Timer Jobs

SharePoint Timer Job/Scheduler

Hi,

This Article target's on development and deployment of timer job in SharePoint.
Lets begin creating a blank project and calling references of SPJobDefinition for assigned timer that will execute the functionality as needed by the timer job to execute. Along with this we are also creating a feature which will specify the trigger schedule.

Here I’m specifying the code snippet for the same.
Create a Class library project include all the SharePoint related references needed.
using Microsoft.SharePoint;
using Microsoft.SharePoint.Administration;
DEFINE JOB
Inherit the SPJobDefinition class which is a member for Sharepoint Administration

class ClassName:SPJobDefinition
{
internal const string TASK_NAME = "MYTimer" ;
public ClassName() : base(){
}

public ClassName (string jobName, SPService service, SPServer server, SPJobLockType targetType): base(jobName, service, server, targetType){
}

public ClassName (string jobName, SPWebApplication webApplication)
: base((jobName, webApplication, null, SPJobLockType.Job) {
this.Title = "MYTimer" ;
}
//Override the Execute function
public override void Execute(Guid targetInstanceId) {
//Calling our function which needs to be executed
MYfunction();
//base.Execute(targetInstanceId);
}
public void MYfunction() {
try
{
SPSite osite = new SPSite( "SiteURL" );
//SPSite osite = SPContext.Current.Site;
SPWeb oweb = osite.OpenWeb();
oweb.AllowUnsafeUpdates = true;
if (oweb.Lists[ "Tasks" ] != null)
{
SPList olist = oweb.Lists[ "Tasks" ];
SPListItem newTask = olist.Items.Add();
newTask[ "Title" ] = DateTime.Now;
newTask.Update();
}
}
catch (Exception ee) { //Add you Exceptions catch }
}
}

Add a new class item for Feature Creation
//Feature creation
class MyclassInstaller:SPFeatureReceiver {
internal const string TASK_NAME = "MYTimer" ;

public override void FeatureInstalled(SPFeatureReceiverProperties properties) {
}
public override void FeatureUninstalling(SPFeatureReceiverProperties properties) {
}
public override void FeatureActivated(SPFeatureReceiverProperties properties) {
// register the the current web
SPSite site = properties.Feature.Parent as SPSite;

// make sure the job isn't already registered
foreach (SPJobDefinition job in site.WebApplication.JobDefinitions)
{
if (job.Name == TASK_NAME)
job.Delete();
}
TaskLoggerJob taskLoggerJob = new TaskLoggerJob(TASK_NAME, site.WebApplication);

// For Minute Trigger
SPMinuteSchedule schedule = new SPMinuteSchedule();
schedule.BeginSecond = 0;
schedule.EndSecond = 59;
//Intervals define the Minute Time Gap between triggers ex-2= min gap for timer trigger
schedule.Interval = 2;
taskLoggerJob.Schedule = schedule;
taskLoggerJob.Update();
}
public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
{
SPSite site = properties.Feature.Parent as SPSite;

// delete the job
foreach (SPJobDefinition job in site.WebApplication.JobDefinitions)
{
if (job.Name == TASK_NAME)
job.Delete();
}
}
}

DEPLOYMENT
The best way to deploy the time project is by creating a WSP either can use WSP builder or NANT for creating a WSP.
But Before we deploy this solution we need to add its FEATURE.XML in 12 hives feature folder with naming Feature conventions as here i have termed "MyTimer". You can manually add this file in this folder structure with following tags in it :
Feature xmlns="http://schemas.microsoft.com/sharepoint/"
Id="DA1B534E-08D9-41ef-B2C4-B656E9389D80"
Title="MYTimer" Description="Installs the task MY timer job feature to the current site collection."
Scope="Site"
Hidden="TRUE"
Version="1.0.0.0"
ReceiverAssembly="MYSite, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3aeda64f0b993534"
ReceiverClass="MYSite.MyclassInstaller"
>
Once a WSP is created you follow the same procedures as recommended i.e
1. Add Solution
2. Deploy Solutions
3. Install Feature
4. Activate Feature.

STSADM Commands for WSP Deployment
pushd %programfiles%\common files\microsoft shared\web server extensions\12\bin
@Echo ------Adding Sol------
stsadm -o addsolution -filename file://wsppath%20/MyTimer.wsp
stsadm -o execadmsvcjobs
@Echo ------deploy Sol----
stsadm -o deploysolution -name MyTimer.wsp -allowGacDeployment -local -force
stsadm -o execadmsvcjobs
iisreset
@echo -----Feature added-----
stsadm -o installfeature -filename MyTimer\feature.xml -force
stsadm -o activatefeature -filename MyTimer\feature.xml -url siteURL -force
stsadm -o execadmsvcjobs
iisreset



There goes you can check timer execution in Timer job status & Timer job definitions in central administration which details the execution time and its status for success.

Just a Quick information of all the inbuilt Timer in sharepoint Sorted by Neil Click here

Here are the snipplets for Weekly, Monthly & Annual.

Hourly(Triggers @ Every Hour 01.Min)
SPHourlySchedule JobSchedule = new
SPHourlySchedule();
JobSchedule.BeginMinute = 1;
JobSchedule.EndMinute = 2;


Weekly (Triggers @ Thursday 04:01:00PM)

SPWeeklySchedule JobSchedule = new SPWeeklySchedule();
JobSchedule.BeginDayOfWeek = DayOfWeek.Thursday;
JobSchedule.EndDayOfWeek = DayOfWeek.Thursday;
JobSchedule.BeginHour = 16;
JobSchedule.EndHour = 16;
JobSchedule.BeginMinute = 01;
JobSchedule.EndMinute = 05;
JobSchedule.BeginSecond = 00;
JobSchedule.EndSecond = 00;
taskLoggerJob.Schedule = JobSchedule;
Monthly (Triggers @ First Day(01) of the Month, at 10:15:00AM)
SPMonthlySchedule JobSchedule = new SPMonthlySchedule();
JobSchedule.BeginDay = 1;
JobSchedule.EndDay = 1;
JobSchedule.BeginHour = 10;
JobSchedule.EndHour = 10;
JobSchedule.BeginMinute = 15;
JobSchedule.EndMinute = 25;
JobSchedule.BeginSecond = 00;
JobSchedule.EndSecond = 00;

Annually (Triggers @ April 21, at 10:15 AM)
SPYearlySchedule JobSchedule = new SPYearlySchedule();
JobSchedule.BeginMonth = 4;
JobSchedule.EndMonth = 4;
JobSchedule.BeginDay = 21;
JobSchedule.EndDay = 21;
JobSchedule.BeginHour = 10;
JobSchedule.EndHour = 10;
JobSchedule.BeginMinute = 15;
JobSchedule.EndMinute = 25;
JobSchedule.BeginSecond = 00;
JobSchedule.EndSecond = 00;

Addin your comments for this article.

Tuesday, April 20, 2010

Defining Custom Columns in SharePoint – Field Types and Options

Defining Custom Columns in SharePoint – Field Types and Options

A common task for SharePoint developers is defining Site Columns (or Fields) as part of a Feature. When defining a field, you need to assign the field a type. I have created this reference table below to help you map between the the “Create Site Column” SharePoint page to the attributes you would set when defining the field as part of a feature.

Defining Columns using the UI

image



Create Site Column Page




image
Defining Columns in an Elements file as part of a feature
  1: <Field ID="{CCF0A1BF-4823-459c-9773-73890231E070}"

  2:        Name="ActiveProject"

  3:        DisplayName="Is Project Active"

  4:        Group="Litware"

  5:        Type="Boolean"/>

Type (as shown on the Create Column page) Field Type Notes MSDN Links
Single line of text Type=”Text” Microsoft.Sharepoint.SPFieldText
Multiple lines of text Type=”Note” In the Create Column page, can pick the type of text to allow. To enable the different sub-types, you need to set a couple of other attributes on the field element.

Plain Text
RichText=”FALSE” (default value)

Rich Text
RichText=”TRUE”
RichTextMode=”Compatible” (default value)

Enhanced Text
RichText=”TRUE”
RichTextMode=”FullHtml”

In addition, you can also set the number of lines to display using the NumLine attribute.

Further Information on MSDN:
Microsoft.Sharepoint.SPFieldMultiLineText
Choice (menu to choose from) Single Choice
Type=”Choice”

Multi-Choice
Type=”MultiChoice"
Pick the display format for the Choice and Multi-Choice types, respectively:

Drop-Down Menu or Combo Box
Format=”Dropdowns”

Radio Buttons or Check Boxes
Format=”RadioButtons”

Define the options a user can pick from using the Choices element. Below is a skeleton to explain this.



Option 1
Option 2



If you would like to give the user an option to add their own value, set the attribute FillInChoice=”TRUE”.
Microsoft.Sharepoint.SPFieldChoice
Microsoft.Sharepoint.SPFieldMultiChoice
Number Type=”Integer” This field type also lets you define:

Minimum Value (0 for example)
Min=”0”

Maximum Value (100 for example)
Max=”100”

Decimal Places (Default is Automatic, example 2 decimal places)
Decimals=”2”

Show as Percentage (Default is False)
Percentage=”FALSE”
Microsoft.SharePoint.SPFieldNumber



Currency Type=”Currency” This field type also lets you define:

Minimum Value (0 for example)
Min=”0”

Maximum Value (100 for example)
Max=”100”

Decimal Places (Default is Automatic, example 2 decimal places)
Decimals=”2”

Currency Format
This sets the display format of the currency.

LCID=”3081”

3081 sets the format English – Australian. For a complete list of Locales, see the MSDN link in the next column.
Microsoft.Sharepoint.SPFieldCurrency

Locale IDs
Date and Time Type=”DateTime” This field also lets you define:

Date and Time Format
Show the date only:
Format=”DateOnly”

Show the date and time:
Format=”DateTime”
Microsoft.Sharepoint.SPFieldDateTime
Yes/No Type=”Boolean” When setting the default value, you need to use the binary values:

No/False = 0
Yes/True = 1
Microsoft.Sharepoint.SPFieldBoolean
Person or Group Single User or Group
Type=”User”

Multiple Users or Groups
Type=”MultiUser”
This field also lets you define:

Allow multiple selections
Set the Type to MultUser and the attribute Mult=”TRUE”

Allow selection of
People Only
UserSelectionMode=”PeopleOnly”

People and Groups
UserSelectionMode=”PeopleAndGroups”

Choose from
If you want to limit the option list to a SharePoint Group, use the UserSelectionScope attribute. Set it to the ID of the SharePoint group (Integer value). For example, UserSelectionScope=”3”.

Show field
Set the name of the field from the User’s profile properties that you want to display. For example, show the user’s name property:
ShowField=”Name”

If you would also like to show presence (Office Communicator integration required):
Presence=”TRUE”
Microsoft.Sharepoint.SPFieldUser
Hyperlink or Picture Type=”URL” You can display the URL as a Hyperlink or Picture. Use the Format attribute to pick which one:

Hyperlink
Format=”Hyperlink”

Picture
Format=”Image”
Microsoft.Sharepoint.SPFieldUrl

Wednesday, April 14, 2010

Assigning Dynamic Permissions whil creating wokflow task to assigned user

When coming to Visual Studio workflows, something which surprises many SharePoint developers is that tasks assigned in the workflow can actually be actioned by any SharePoint user with basic permissions. In the worst scenario, 'basic permissions' means any user with contribute permissions to the SharePoint web which contains the workflow tasks list, and clearly this could be a whole lot of users who have nothing to do with your workflows. In the best case, you might have tied down permissions so that only users involved in workflows can use the list. Even so, this still means that any actor in the workflow can respond to any task, not just tasks which have actually been assigned to them. To my mind, this is bad - all it takes is a confused user to accidentally respond to someone else's task and your workflow is in a whole world of chaos.

So what can we do about this?

Well, there doesn't seem to be much written about this, but fortunately the best solution (AFAIK) is also the simplest one. Before we dive in, I notice other people needing to solve this problem have taken the approach that since a workflow task is just a list item, we can execute some code to set permissions on the list item using the API. A logical tactic, but happily there is special provision for doing this in the workflow framework - we still need to write a little code, but it's much simpler than that approach. The key is the 'SpecialPermissions' property of the CreateTask activity:



Pitfall - confusingly, clicking the ellipses button (...) for the property presents a generic VS collection editor (shown below), which as far as I can tell just flat cannot be used with this property - all the controls are disabled!




I'm assuming this is a bug in the Visual Studio 2005 Extensions for Workflow Foundation, so we'll ignore that! However, clicking the tiny blue 'bind property' button presents the more familiar 'bind the property to an instance variable' dialog - assuming you haven't already created a variable to store the permissions for this CreateTask, we should select 'Bind to a new member', and create either a field or property to store the permissions:



This creates a collection object, specifically a HybridDictionary, to which we can add items for each permission we need for this task. And we only need a handful of code lines to do it! Since we're likely to use it for many (i.e. all) tasks in our workflow, let's have a separate method we can call each time:

private void setTaskPermissions(HybridDictionary boundDictionary, string sTaskOwner)

{

boundDictionary.Clear();

boundDictionary.Add(sTaskOwner, SPRoleType.Contributor);

boundDictionary.Add("NT AUTHORITY\\authenticated users", SPRoleType.Reader);

}


So, we pass in the collection specific to each task, and also the string username for the task owner. We then add an entry for the task owner to the dictionary with the 'contributor' permission, and one for all other users with just read permissions. Note we also clear out the dictionary before adding in case this task has already been issued (i.e. something got rejected in the workflow and we came back to this task a second time) - this avoids any errors due to the key already existing in the dictionary.


The calling code then, looks like this:

setTaskPermissions(approveExpenseClaim_SpecialPermissions, taskProps.AssignedTo);

This would be added to the code for each CreateTask activity in your workflow. The first parameter is the variable we bound earlier to the SpecialPermissions property (of the particular task we are dealing with), and taskProps is the SPWorkflowTaskProperties object which holds data for the task.

And that's it - much less code than you'd need to modify permissions for the list item with general API usage. The effect of this is that the task owner is the only standard user (administrators with full control excepted) who can respond to the task, but all others can read it. Needless to say, you could customize the code to your specific permission requirements if they are different to mine.

The user experience

One final thing worth pointing out is that the user experience might not be quite as slick as you'd like. Since we've restricted permissions on the item, any user who clicks on the task but doesn't have permissions will see the standard access denied message:



Personally I think an improvement would be to show a more friendly message, but this would require substantially more effort and complexity. My view is that for a few lines of code, this approach is a great trade off between effort required and benefit of protecting the integrity of the workflow - I'm definitely not a fan of sleepless nights wondering just what would happen in the workflow if users unintentionally responded to tasks which didn't belong to them, so it works for me. As always, if you've implemented a different way of dealing with this problem or have other comments, it would be great to hear.

Sharepoint Workflow Claim & Release Task Scenario

Hi,

I hav created a sharepoint workflow that has task assigned to a sharepoint group, now i want the task to be editable by only

1 person in a group, so i m assigning right dynamically to edit the task on createTask, hence the only the group user will

allowed to edit on that taskitem,
There is something in sharepoint tasks called "Claiming & Releasing Task" which i thought should resolve my problem,
but after claiming the other users of the same group shouldnt able to edit the task, which is happening in my scenario !

i m getting into taskchanged event when someone from group claims the task, so there i could use the remove group permission

and assign it only to the claimer of the task, but same way for realese task the same method is called again here i hav to

assigned right back to group, but i m not able to catch on which activity calls the taskchanged method claimTask or

releaseTask

Can anybody Help me On this ....