How to hide the workspace creation option in the Events, in sharepoint 2010.

Posted on

This scenario is pretty easy, I needed to be able to HIDE by WEBSITE only, the option to show the workspace creation checkbox for the events.
The thing is that because we have many sites, in some it should be still possible to create the workspaces for events.
What I did, its a feature scoped to Web, and then I used the following code, which allows me to hide/unhide when the feature is activated/deactivated.

  public override void FeatureActivated(SPFeatureReceiverProperties properties)
        {
            // False, sets the Hidden property to true.
            ChangeWorkspaceCreationVisibility(properties, true);
        }

        // Uncomment the method below to handle the event raised before a feature is deactivated.

        public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
        {
            // True, sets the Hidden property to false.
            ChangeWorkspaceCreationVisibility(properties, false);
        }

        // Uncomment the method below to handle the event raised after a feature has been installed.

        //public override void FeatureInstalled(SPFeatureReceiverProperties properties)
        //{
        //}

        // Uncomment the method below to handle the event raised before a feature is uninstalled.

        //public override void FeatureUninstalling(SPFeatureReceiverProperties properties)
        //{
        //}

        // Uncomment the method below to handle the event raised when a feature is upgrading.

        //public override void FeatureUpgrading(SPFeatureReceiverProperties properties, string upgradeActionName, System.Collections.Generic.IDictionary parameters)
        //{
        //}

        private void ChangeWorkspaceCreationVisibility(SPFeatureReceiverProperties properties, bool enable)
        {
            using (SPWeb web = properties.GetWeb())
            {

                for (int i = 0; i < web.Lists.Count; i++)
                {
                    if (web.Lists[i].BaseTemplate == SPListTemplateType.Events)
                    {
                        var field = web.Lists[i].Fields[SPBuiltInFieldId.WorkspaceLink];
                        field.Hidden = enable;
                        field.Update();
                    }
                }               
            }
        }

    }

    public static class Extensions
    {
        public static SPWeb GetWeb(this SPFeatureReceiverProperties properties)
        {
            SPWeb site;
            if (properties.Feature.Parent is SPWeb)
            {
                site = (SPWeb)properties.Feature.Parent;
            }
            else if (properties.Feature.Parent is SPSite)
            {
                site = ((SPSite)properties.Feature.Parent).RootWeb;
            }
            else
            {
                throw new Exception("Error 192424234223442: Unable to retrieve SPWeb - this feature is not Site or Web-scoped.");
            }
            return site;
        }
    }

Development environment for Sharepoint Solutions in corporate enviroment

Posted on

This is only my personal experience, according to a specific real scenario problem. Corporate environments might differ.

Today we had to define how we were going to develop in our company sharepoint 2010 solutions. Actually Sharepoint 2010 has been here for more than one year, but only with one developer, so the developer was working directly via remote access to the TEST environment.

Now, there is 2 developers and soon there will be more.
At the beginning they were thinking, well now there is 2 developers, so better have a full dev farm environment, and the starting idea was one Ad server, one sql server, and one sharepoint server.

But then we realized that we would have problems with this approach, and biggest problem is debugging, If one developer is debugging, the productivity of the other one will be reduced, because the other one will have to wait to debug its own code.

At the end, it was decided that every developer will have its own development farm.
one develop server with sharepoint 2010, vs 2010 and sp designer
one sql server
one ad server.

Both developers will be connected to a central source control, everytime one needs a component from the other, its just check-in then get latest version and deploy in other developer’s farm.

In that way, we can restore the current information from the production database to replicate the current deployment. And we can develop in our own farms without disturbing the other.

Development environment for Sharepoint Solutions in corporate enviroment

Posted on

This is only my personal experience, according to a specific real scenario problem. Corporate environments might differ.

Today we had to define how we were going to develop in our company sharepoint 2010 solutions. Actually Sharepoint 2010 has been here for more than one year, but only with one developer, so the developer was working directly via remote access to the TEST environment.

Now, there is 2 developers and soon there will be more.
At the beginning they were thinking, well now there is 2 developers, so better have a full dev farm environment, and the starting idea was one Ad server, one sql server, and one sharepoint server.

But then we realized that we would have problems with this approach, and biggest problem is debugging, If one developer is debugging, the productivity of the other one will be reduced, because the other one will have to wait to debug its own code.

At the end, it was decided that every developer will have its own development farm.
one develop server with sharepoint 2010, vs 2010 and sp designer
one sql server
one ad server.

Both developers will be connected to a central source control, everytime one needs a component from the other, its just check-in then get latest version and deploy in other developer’s farm.

In that way, we can restore the current information from the production database to replicate the current deployment. And we can develop in our own farms without disturbing the other.

Customize Access Request functionality

Posted on

In order to change how the access request functionality works in sharepoint 2010 you need to create an application page with your functionality, like sending out a different email than the default one. Or saving the access requests in a sharepoint list, etc, up to you what to do there.

Sharepoint 2010 has already an access request application page.  This command will tell you where its located.
Get-SPCustomLayoutsPage -Identity "AccessDenied | Confirmation | Error | Login | RequestAccess | Signout | WebDeleted

To change it, execute the following command.

Set-SPCustomLayoutsPage -Identity "RequestAccess" -RelativePath "/_layouts/custompages/reqacc.aspx" -WebApplication "{replace with web app url}"

Voila!!! Put your logic in the custom app page you created before.

Official doc:

Customize Access Request functionality

Posted on Updated on

In order to change how the access request functionality works in sharepoint 2010 you need to create an application page with your functionality, like sending out a different email than the default one. Or saving the access requests in a sharepoint list, etc, up to you what to do there.

Sharepoint 2010 has already an access request application page.  This command will tell you where its located.
Get-SPCustomLayoutsPage -Identity "AccessDenied | Confirmation | Error | Login | RequestAccess | Signout | WebDeleted

To change it, execute the following command.

Set-SPCustomLayoutsPage -Identity "RequestAccess" -RelativePath "/_layouts/custompages/reqacc.aspx" -WebApplication "{replace with web app url}"

Voila!!! Put your logic in the custom app page you created before.

Official doc: