Umbraco consists of several different sections that, together, make up the comprehensive tool that Umbraco is. The following section discusses what each one of these does and how to appropriately assign them to users.
Understanding the semantic and functional split between these sections is important to you as a developer and implementer of the CMS. You can think of it like the process of building a house where each phase of the project has dedicated roles and responsibilities. Much like it is up to the mason to build a strong and lasting foundation, your job is to do the same with templates, layouts, document types, and styles for the editor to leverage for saving and publishing content.
RESTRICTING ACCESS IS BOTH IMPORTANT AND NECESSARY
I have found in numerous projects that keeping non-technical editors and writers away from the more advanced sections within the Umbraco backoffice is important. Providing access to templates and document types to someone who “knows enough to be dangerous” inevitably leads to a disaster because it allows them to make real-time changes to the website's infrastructure and integrity. How to restrict access should be part of your training phase when deploying your implementation at the client site.
To paint a picture, imagine in the earlier house building analogy that you, as the homeowner, were allowed to mix the concrete for the foundation. Unless you're an expert at concrete, chances are your foundation might crumble with time!
You guessed it! The Content section is where all the content is managed within Umbraco and where most of your admin users will spend their time. In the Content section, content types that you have set up as a developer become available for the editor and/or writer to use for content creation.
You must give special attention to the content Properties tab, which you will always see as part of the right pane for all document types. Figure 2-5 shows that you can control a number of settings for the node in the Properties tab:
After a node has been created, you cannot change the document type because different document types will have, in most cases, vastly different properties. This means that if you filled in a value for the First Name field in one document type, it may not exist in the next, rendering the ability to change document types after node creation useless. Instead, if you need the ability to have different output for similar content, consider creating a document type that supports common properties and instead allow multiple templates for that document type. Chapter 4 discusses this approach in detail.
If you unpublish the node that you're currently on, the entire site becomes unpublished and rendered inaccessible to the end user. Be careful where you use this function.
The link to document field would have multiple entries if you had specified more than one entry in the hostnames setting for the Umbraco website. This setting can be managed by right-clicking the homepage node of your website and is discussed in detail in Chapter 7.
Most of the options in the context menu (shown in Figure 2-6) on the Content nodes are self-explanatory. However, some deserve your attention for further explanation:
Furthermore, you can configure a user to automatically start editing in canvas mode if that is his or her preference.
Before reading the general discussion of what the Users section provides you, you should know the difference between users and members—a common question, to say the least. It's quite simple actually; a user is an account that has access to the Umbraco backoffice and all that this entails, whereas a member is an account that has access to restricted content on the front end, like a client login or extranet (see the “Members” section later in the chapter).
Having said that, read on to find out what the Users section does.
The Users section manages the administrators, editors, writers, translators, and whatever other custom user types you may have defined. This section is where you add and edit users that have access to the Umbraco backoffice. As shown in Figure 2-10 and Table 2-1, a number of properties exist for each user in the system.
After a user account has been created you cannot delete it. You must use the Disable User option to prevent future logins.
As discussed earlier, user types allow you to assign user accounts with predefined sets of permissions on the content tree. If one of the predefined user types does not fit your needs, you can create your own custom types. As shown in Figure 2-11, you will notice that the label for this user is kind of whacky—it has braces around the name. The braces mean this value is pulled from the localization files so that if the language is set to something other than English, the name is translated.
In this exercise, you will set up a label for a new user type so that it can be read correctly in various languages.
If you navigate to the details of Content Editor, you will see that the value in the drop-down list is surrounded by braces “[ ].” To change that value, follow these steps:
In addition to the flexibility of the aforementioned user settings, Umbraco also comes equipped to handle more granular permissions on a per-user basis. This capability might come in handy when you have individual users who have special permissions but do not warrant a custom user type.
User permissions and access only apply to the content tree and nothing else.
As shown in Figure 2-13, you can set permissions at another dimension as well, namely by one or more content nodes. This feature is particularly useful if you have a user who must have access to multiple sections of your content tree.
The following steps show you how to set up a user to have multiple start nodes in the content tree, effectively bypassing the settings of the user's account.
You can also set permissions on a page-by-page basis in the Content section. Reference Chapter 8 for more details on how this approach works.
The Media section is fairly short and sweet because it simply deals with asset management such as images, files, and folder structure. Umbraco is not a document management system, and it doesn't claim to be. It provides just enough functionality to provide a content editor with a way to easily manage website assets and organize them.
If you are looking for advanced features, such as image cropping, resizing, text overlay, batch uploads, and more, be sure to check out the Umbraco community projects page on http://our.umbraco.org. See Chapter 10 for more details about packages.
Three different types of media are supported out of the box in Umbraco, as shown in Table 2-2 and Figure 2-16.
Folders are useful for providing access to specific areas of your Media section. The process of setting up a user's start node in the Media section is discussed in the Content Access item in Table 2-1.
As the name suggests, the Settings section provides access to all the Umbraco-specific settings. Most of the nodes in this section have their own chapters in this book (as noted in the following list):
You can add media type properties in the Settings section, but for now the Umbraco backoffice will not display those properties in the media details. As of this writing, that feature is still unimplemented.
The Developer section provides controls that enable you to extend Umbraco with custom functionality and extend it using the rich API. Many of the nodes in this section are covered in other chapters, but here's an overview of what they are:
Check out Chapter 12 for some examples on how to create your very own data types!
The Members section is where you manage accounts with access to the public website. As an administrator you can use this interface to add member accounts, groups, and types. With this interface, you can now set access restrictions on nodes within your content tree.
Some configuration changes are required in the Web.config to make member types functional. Because access restrictions are so specific to your particular implementation, creating a member type and defining it as the default in Web.config is necessary. This process is discussed as part of the examples in Chapter 12.
The Members section is broken down into three separate main nodes. As mentioned earlier, the member groups and member types will be specific to your implementation and are therefore left blank by default.
Creating a member group is the first thing you want to do. Members must belong to a member group to be able to log in. Follow these steps:
Member types define the properties of a member account. As such, it is the second item that you should define in a blank Umbraco installation.
Email address, name, and password are all captured as part of the standard member properties. In addition to these standard fields, you can add fields specific to your needs.
The Translation section provides users with a way to access the translation workflow that comes standard with your Umbraco installation. If you choose to use this workflow, make sure that you designate users in the Users section with the Translation user type so that content editors and writers can assign content to those users for translation.
Have a look at Appendix D for a full overview of how to implement the translation workflow.