Windows Server 2008/IIS 7:
1. Open a command prompt and type “netsh”.netsh
2. Type “http”.http
3. show iplisten
4. add iplisten ipadress=xxx.xxx.xxx.xxx
5. delete iplisten ipadress=xxx.xxx.xxx.xxx
6. iisreset
1. Open a command prompt and type “netsh”.netsh
2. Type “http”.http
3. show iplisten
4. add iplisten ipadress=xxx.xxx.xxx.xxx
5. delete iplisten ipadress=xxx.xxx.xxx.xxx
6. iisreset
One of the great things about Sitecore is the ability to extend and customize basic Sitecore. Recently I had a project where the client wanted the ability to specify workflow security per item. The standard Sitecore workflow allows to specify the security per workflow state.
To implement this functionality I had to create a class that extends Sitecore.Workflows.Simple.Workflow.
public class CustomWorkflow: Sitecore.Workflows.Simple.Workflow, IWorkflow
{
}
Next we need to give the ability to filter what items are displayed in the workbox and what workflow commands a user can execute. In order to filter what items are displayed in the workbox the workflow needs to override the GetItems (string) function. This function is called by the workbox to get the list of items to display.
public override DataUri[] GetItems(string stateId)
{
List<DataUri> list = base.GetItems(stateId).ToList();
DataUri[] finalList = list.Where(p => HasWorkflowAccess(p)).ToArray();
return finalList;
}
The above function calls the standard workflow GetItem function. Then the items are filtered out to only return the items that have access. The next step is to restrict access to an item in the workflow and to restrict what commands a user can execute. To do this we need override the GetCommands (Item) function. This function is called to get the list of commands the user can execute per item.
public override WorkflowCommand[] GetCommands(Item item)
{
Assert.ArgumentNotNull(item, “item”);
if (!HasWorkflowAccess(item))
return new WorkflowCommand[0];
WorkflowCommand[] commands = base.GetCommands(item);
return commands;
}
The above function checks to see if the user has access to the item. If the user does not have access no commands will be returned. If the user does have access to the item it will return the commands that are available using the standard Sitecore workflow.
With the following customization we have the ability to specify workflow security at the item level.
On Visual Studio Command Prompt
Run tf workspaces /owner:* /computer:{computer name}
Run tf workspace /delete {workspace name} {computer name}:{owner}
Test Cases
Standard output from a field
Form with validation
Repetitive display
ID generation
JSONP request
One of the things that I feel like are something that has not been really decided on is P tags in a CMS system. There are multiple ways to handle this issue but none of them are the perfect solution.
Wrap around a p tag around the fields. What happens when the p tags are already included? Hide empty p tags only works in everything except for for IE
The css should support the p tag and no tag. I would agree but sometimes it is going to take more effort to support than it is worth it.
Suck it up and always support p tags. Another approach is to force the client to make sure the p tags are generated and if not show them how to fix this. This only happens when the client does not enter any html.
You should make sure all your code is checked into the source control system when you start working.
Set user enviroment variable called MsiBreak then restart the system.
Uncheck “Display the connection bar when in full screen mode”.
To get out of the remote desktop use a second monitor or use CTRL+ALT+Break. This will window the RDC. To go back to full screen use CTRL+ALT+Break again.
http://superuser.com/questions/214233/is-there-any-way-i-can-make-the-connection-bar-more-difficult-to-display-using
Attach the drive as /dev/sda1