Nuxeo Studio Documentation

Studio Documentation
12/09/2014
Table of Contents
1. Nuxeo Studio Documentation Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Getting Started in Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 Studio Overview and Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1.1 What can be achieved with Nuxeo Studio? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1.2 What do you need to know about Nuxeo applications? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1.2.1 About documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1.2.2 About layouts and content views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1.2.3 About workflows and business logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1.2.4 Plugins and extensions with the Nuxeo Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1.3 How To Get Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Working in Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2 Branding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2.1 Branding Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2.1.1 Migrating My Branding to 5.5 New Branding System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2.2 Create multiple themes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.3 Content Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.3.1 Schemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.3.2 Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.3.3 Life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.3.4 Structure Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.4 Listings & Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.4.1 Content Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.4.1.1 Content View: Query & Form Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.4.1.2 Content View: Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.4.1.3 Content View: Enablement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.4.2 Form Layouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.4.3 Search / Advanced Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.4.4 Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.4.5 Virtual Navigations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.5 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.5.1 Workflow screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.5.1.1 Workflow creation form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.5.1.2 Definition tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.5.1.3 Variables tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.5.1.4 Availability tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.5.1.5 Graph tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.5.2 Node popup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.5.2.1 Node General tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.5.2.2 Node form tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.5.2.3 Node Transitions Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.5.2.4 Node Variables Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.5.2.5 Node Escalation Rules Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.6 Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.6.1 User Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.6.1.1 User actions categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.6.2 Automation Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.6.3 Event Handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.6.4 Filtering Options Reference Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.7 Roles & Permissions Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.7.1 Add a new Permission in the UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.7.2 Add predefined users and groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.8 Vocabularies Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.8.1 Vocabulary Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.9 Advanced Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Administering your project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1 Automated renaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.2 Use Registries for Referencing Externally Defined Objects (Types, Operations, ...) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.3 Test your Studio config with a new version of DM or CMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.4 Update the Version of Your Target Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.4.1 Specific Upgrade Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.5 Version Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.6 Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.7 Automated validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.8 How to Enable Package Specific Features in Studio for DAM or DM? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Tutorials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.1 Deploying Your Project in Dev Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
4
4
5
5
6
7
7
11
12
12
12
13
13
18
19
19
19
20
24
25
26
26
29
32
33
33
38
39
43
44
44
44
44
45
45
46
46
46
48
49
49
50
50
50
52
63
66
68
69
69
70
72
72
73
73
74
75
76
76
76
80
82
83
86
87
87
1.4.2 Installing the Studio JAR Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.3 Referencing an Externally Defined Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.4 Referencing an Externally Defined Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.5 How-tos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.5.1 Create a mail template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.5.1.1 Available variables in email templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.5.2 Override email notification templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.6 Maven Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5 Application Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.1 Default configuration templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.2 Templates reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.2.1 Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.2.2 Contract management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.2.3 Custom Doc ID Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.2.3.1 Adding a "Type" Property to File Document Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.2.3.2 Declaring Vocabularies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.2.3.3 Configure the ID generation using functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.2.4 Human resources - Vacation request workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.3 Using Application Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.1 Is it possible to export a Studio project in Eclipse ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.2 Nuxeo Studio and Connect architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7 Collaboration Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.8 Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.8.1 What Is Keeping Us Busy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.8.2 Release Note History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.8.2.1 20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.8.2.2 19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.8.2.3 18 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.8.2.4 2.17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.8.2.5 2.15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.8.2.6 2.14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.9 Section 508 Compliance (VPAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
89
90
91
98
99
100
101
103
103
103
104
105
111
111
112
113
113
117
119
119
119
120
123
123
124
124
124
125
126
127
128
130
Studio Documentation Center
Nuxeo Studio Documentation Center

Try Studio now for free!
Download this
documentation in PDF
Getting started
This page will give you an overview of what can be done with Nuxeo Studio and how you can create your own Nuxeo Studio
projects step by step.
Quick Start Dev Guide
Studio Overview and Concepts
Working with Studio

In this chapter we will explain each screen exposed by Nuxeo Studio. If you are blocked in your configuration process on a
specific screen!
Documents
Content Views
Workflow
Automation
Administering your project

This section provides you an overview of how you can manage your own application (versioning, naming, etc.)
How to Enable Package Specific Features in Studio for DAM or DM
Use Registries for Referencing Externally Defined Objects
Update the Version of Your Target Platform
Tutorials
The goal of this section is to provide ready to use examples. They can be followed step by step to learn how to use Studio on
practical use cases.
Deploying Your Project in Dev Mode
How-tos
An overview of Nuxeo Studio features in this screencast:

License
This documentation is copyrighted by Nuxeo and published under the Creative Common BY-SA license. More details on the Nuxeo
documentation license page.
Answers
Nuxeo Studio 30-day Trial
Nuxeo Connect Portal
Getting Started in Studio

Studio Overview and Concepts This section provides you with an overview of what can be done with Nuxeo Studio, using
screencasts and concept explanations.
Copyright 2010-2014 Nuxeo.

This documentation is published under Creative Common BY-SA license. More details on the Nuxeo Documentation License page.
Studio Overview and Concepts

Nuxeo Studio is an online application allowing you to customize Nuxeo products, from minor details to significant changes. With its graphical
user interface, you can develop real new applications from the Nuxeo Platform without writing code.
Nuxeo Studio is offered as a service. This means the application is hosted and maintained by Nuxeo and accessible by logging in via a web
browser. This also means you have no software to install before using it, speeding up the deployment time.
Nuxeo Studio facilitates not only the customization but also the deployment of the applications you develop. Thanks to the Connect
infrastructure, Nuxeo Studio can simply deploy your work on your Nuxeo Instance with very little administrative work, no code to write and no
low level system administration tasks to perform.
Finally, Nuxeo Studio makes it easier to upgrade your Nuxeo-based applications, as Nuxeo Studio guarantees forward compatibility with the
next release of Nuxeo Studio.
This section provides you with an overview of what can be done with Nuxeo Studio, using screencasts and concept explanations.
In this guide:
What can be
achieved with Nuxeo
Studio?
What do you need to
know about Nuxeo
applications?
How To Get Started
Step 1
Check out what can be
achieved with Nuxeo
Studio
What can be achieved with Nuxeo Studio?

Nuxeo Studio enables you to adapt the Nuxeo Platform, based on any of the Nuxeo distributions (Nuxeo DM, Nuxeo CAP or Nuxeo DAM ...)
and make them your own: Customizations can encompass superficial changes like graphical modifications to the creation of new business
workflows.
As a content management customization tool, Nuxeo Studio features new content type creation: Using forms and drag and drop, you can
define your own document types and their sets of metadata, forms and presentation. Search forms can be customized to leverage these new
properties.
Nuxeo applications provide default actions and workflows. But if you need some business rules or transitions, you can add new buttons, icons
or links that will trigger your own actions. Nuxeo Studio includes a catalog of small operations that you can assemble by drag and drop to
design your own workflows and business rules as well as create new complex features.
Studio can also provide cosmetic changes. Using palettes or standard CSS attributes, you can change the color and style of all graphical
elements of the application, such as tabs, borders, background, icons, and, of course, the logo. This is how you give your Nuxeo application
your organizations graphical identity.
<< Studio Overview and Concepts

What do you need to know about Nuxeo applications? >>
What do you need to know about Nuxeo applications?

Nuxeo Studio is designed to let you focus on your business needs and let the system take care of the implementation details. Yet Nuxeo
Studio is all about configuring your ECM environment (from document management to collaboration to transactional content management).
Hence it is very important for you to understand the main concepts of the platform on which on Nuxeo applications are based, Nuxeo EP.
As this section is key for your productivity with the Nuxeo EP infrastructure and related products, please let us know (in the comments) any
feedback you have.


This section presents the subjects below:
About documents
About layouts and content views
About workflows and business logic
Plugins and extensions with the Nuxeo Platform
<< What can be achieved with Nuxeo Studio?

About documents >>
About documents
Documents
Nuxeo offers ECM applications that enable your organization to manage its documents in a dematerialized way. In Nuxeo applications, a doc
ument can contain an office file (Microsoft Office file, OpenOffice file...), a picture, a video, a PDF, etc. It can also have multiple binary files,
also holding metadata and other properties. Folders, workspaces, cases, sections are also considered as documents in the application.
Technically speaking, a document in Nuxeo is a "content object" that provides a consistent set of information called "properties" and enables
you to store/archive/fill in information in the "document repository". Once you have this, you'll quickly understand that having an environment
such as Nuxeo Studio to configure your document types is a great asset!
Properties
What we refer to as metadata are properties that are stored by a document. There are different types of properties: strings for text
properties, dates, booleans for yes/no properties, integer for numbered properties, blobs... They can also be a list of these types, such as a
list of dates, a list of strings... The blob property is used to store a binary content, such as a file.
Documents are not restricted to a single property of one type. On the contrary, they can store various string properties, or several blobs (ex: a
flash animation and its powerpoint storyboard).
Properties are grouped in schemas, which are sets of property definitions. For instance, Nuxeo uses the "Dublin Core" schema for most of its
documents. When you say "this document holds a Dublin Core schema", you actually say that the document has a title property, a description
property, a creation date, a modification date, an author, a subject, etc.
The schema is a nice concept to enable property definition re-use.
Facets
Beside properties, documents also automatically get some features thanks to facets.They are capabilities, or a potential behavior of your
document. Some examples of facets:
"commentable" makes the "comment" tab displayed so that users can comment on the document
"publishable" will display the publishing tab
"downloadable" displays the download link everywhere it should be displayed, etc
Not all the documents have the same facets. For instance, workspace, section and folder documents have the folderish facet, that is to say
that they can contain other documents (or that you can create documents in them if you prefer it the other way around). Notes, files, pictures
dont have this facet. The folderish facet allows the document to be displayed in the browsing tree, so that you can display its content in the
middle of the screen in the Nuxeo user interface.
Nuxeo Studio enables you to manage properties and create your own "folderish documents" in a centralized place, so you are not limited to
the built-in folderish types. This is a great time saving tool compared to doing manual configuration, whether you are working on a single
project or on many different ones. Of course, the more projects you work on, the more Studio will be saving your time, as you can easily
share your work from one project to another in Nuxeo Studio.
Lifecycle
In Nuxeo, Documents have a lifecycle, that is used to design the different steps of the life of a document. Not all document types have the
same lifecycle. A document will go from one state to another depending on how the usability of the document changes: has it been approved?
is it still legal for use? is it a definitive or a draft version? Going from one state to the other is called a "transition". The lifecycle defines a
set of states and the possible transitions between those states: every combinations are not necessary possible, depending on your business
constraints.
For instance, in Nuxeo DM, the lifecycle of a document is: project -> approved -> obsolete (and deleted). You go from "project" to "approved"
with the "approve" transition, and from approved to obsolete with the "obsolete" transition.
To control the state of the document, you can use, from Studio, automation chains and more specifically the Follow lifecycle transition operati
on.

Document type inheritance

When you create new document types in Nuxeo Studio, you need to select on which Nuxeo default document type it will be based. This
enables your new document type to inherit some properties automatically, so that you dont have to redefine them. For instance, if you want
to create an invoice document type, you will probably want it to be based on the File document type so that your invoices can inherit the get
an attachment option, can be commented on, etc, without you having to define this baseline criteria.
<< What do you need to know about Nuxeo applications?

About layouts and content views >>
About layouts and content views

Layouts
Every time you create or edit a document, the forms displayed are designed using what we call layouts. A layout is the definition of what fields
should be displayed on the page and how they should be organized. There are the default layouts available:
the creation layout: the form used to fill in information when you create a new document;
the edit layout: the form used to fill in information when you update the document;
the View layout: the information displayed on the Summary tab of the document in Nuxeo;
the Header layout: the information displayed on top of tabs of the document view in Nuxeo;
the Summary layout is the view of the document that displays the properties of the document and additional information such as the
latest comments on the document or its relations. It uses the View layout to display the metadata of the document. Note that this
layout configuration will soon be replaced by the Tabs feature for projects running on Nuxeo 5.6 or higher.
You can define as many layouts as you need in addition to those mentioned aboveNuxeo Studio provides you with a friendly user interface to
define all of these.
Content views
Just like you can customize the forms and presentation of documents, you can also adapt the lists of documents to display information
relevant to the users of your application. Lists of documents are done using content views. Basically, content views are what is used in the
Content tab of your folderish documents (workspaces, folders, etc) and everywhere that lists of documents are displayed.
A content view is composed of two parts:
A filter that restricts the content displayed to the current space or a specific document type, depending on your need. Without this
filter, the whole content of your document repository would be displayed in your Content tab. We provide a default filter that
excludes documents that are hidden in navigation and that are deleted from the list of documents.
The results presentation, i.e. the configuration of the table in which the documents are listed, on which you can define all the columns
available
Content views are used to control the way you present information either in new tabs within documents view or after new search forms and
can easily be defined with Nuxeo Studio.
<< About documents

About workflows and business logic >>

Automation
Nuxeo Studio enables you to create your own business logic and workflows. Most of the time, business rules, workflows, new buttons etc, are
configured using automation chains. An automation chain is an ordered set of operations through which a document or a list of documents
goes. Those "operations" are unitary operators that implement a particular documentary function, such as "move a document", "update a
property", "change the lifecycle state", "transform to PDF", "send as email"... You can read the complete Automation theoretical introduction f
or a good start
User actions
In Nuxeo applications, many links are provided to navigate between various features. For instance, when you are on a document, you have
various "tabs", and you also have icons on the top-right part of the screen (such as print, export, send via email...). You also have buttons on
which you can click after having selected various files in a folder. Another group of links is the one just below the worklist. All these links are
called "User Actions" in Nuxeo terminology.


You can declare a new action in Studio and bind it to a content automation chain so that it is executed each time you click on the button. You
can add some filtering information when you declare your action, in order to make it display only for specific types of documents, and specific
user profiles.
Actions are grouped by categories. The screenshots below highlight some default categories locations available in Nuxeo DM. If you have cre
ated new content views, you can also display your new actions in these new content presentations.
Contextual tools
Document List toolbar
Folder toolbar
Worklist

Clipboard
Header links
Document creation form

Document edition form
Document Summary Actions

10
User menu actions
All the user actions categories are described on the page User actions categories.
Event Handlers
Sometimes, you want your business logic to be executed without requiring users to click on a button or link: you want an action to be
triggered automatically when an event occurs. Thats what event listeners (also called event handlers) are for. A listener is a piece of Java
code that runs some code when a given event occurs.
Some built-in events are: Document created, Document imported, Document modified, Document security updated, Document locked,
Document unlocked, Children order changed...
A sample listener is the "Dublin Core" Event Listener. It is enabled in our out-of-the-box products such as DM and DAM to systematically
update the contributors and last updated fields (dates) every time a "Document modified" event is fired, so that we always know who
participated in the modification of a document and when the last modification occurred.
Nuxeo Studio enables you to easily declare new event listeners. You need to bind them on one side to events of your choice, and on the
other side to content automation chains that you have edited in your project so that the selected content automation chain is executed each
time one of the selected events happens.
<< About layouts and content views

Plugins and extensions with the Nuxeo Platform >>
Plugins and extensions with the Nuxeo Platform

11

Nuxeo EP is a very customizable and extensible platform and as a consequence, so are its products (Nuxeo Document Management, Digital
Asset Management and Case Management Framework). By extensible, we mean that you don't need to fork the code of the application to
start modifying it and adapt it to your specific business needs. You only need to do extensions and deploy a plugin. But whats that?
All the customizations you do in Studio are called extensions. When you create a new document type, a new life cycle or a new button,
Nuxeo Studio automatically creates all the XML files needed by the server to implement your changes. But no need for you to worry about
that, its all transparent and all you have to do is use the graphical UI. Should you want to take a look at the extensions produced by Studio,
click on Project Settings in the Settings & Versioning left menu, and in the Manifest tab, click on OSGI-INF/extensions.xml to download
the extensions on your desktop.
To apply your customizations in your Nuxeo instance, you need to update it by deploying a plugin in the application.
A plugin in Nuxeo EP is a .jar file that contains all the customization instructions in XML and optionally some Java code and resources files.
Nuxeo Studio actually aims at producing one .jar file for your project that contains all the customizations, although you will not be aware of
this jar file during a normal cycle of use of Nuxeo Studio.
You can install the Studio produced plugin directly from your Nuxeo application, from the Update Center, by following those instructions (oneclick set up). Or you can generate and deploy your plugin manually.
Whether you used the Update button or the manual installation of the plugin, you can remove it either from the Local packages section of
the Update Center or by removing it from the folder in which you pasted it. Just restart your Nuxeo server and the application returns to
exactly what it was before you applied your customizations.
<< About workflows and business logic

How To Get Started >>
How To Get Started

See the Quick Start Dev Guide
Working in Studio
In this chapter we will explain each screen exposed by Nuxeo Studio. If you are blocked in your configuration process on a specific screen, here
you go!
Resources
Resources is a section in Studio where you can upload various files that will be included in the plugin that Studio produces and that will be used
by your application at runtime. Resources files are usually referenced from another Studio feature.

12

To upload a new resource, select the Browse button, choose your file then click on Upload.
Images: can be used in the Branding feature;
Widget templates: can be used when configuring forms and layouts;
Layout templates: can be used when configuring forms and layouts;
I18n Files: those files contains the translations of all the labels used in your custom plugin;
Schemas: can be used for uploading externally defined XSD schemas, for document properties.
Branding
The Branding section lets you manage the look of your Nuxeo instance. By creating a branding, you will change the header and footer, links and
backgrounds colors, the default font family and borders.
The first screen list all the brandings available. It's the first step to create your own branding.
The New button lets you create a new branding. You can override the one defined in Nuxeo or create multiple brandings and activate
them in different zone of your Nuxeo instance.
The Rename button lets you rename the theme selected in the list.
The Copy button duplicates the selected theme.
The Delete button lets you remove the selected theme.
Several brandings can be created but you can only have one branding set as default in your project.
You just created your first branding? Hooray, let's see how configure it.
Branding Configuration
There are 3 steps shown by 3 tabs to brand your application:
The Common tab will let you manage the global rendering of your application,
The Login Page tab will let you manage the login page rendering,
The CSS Editor will let you define your CSS rules that will be applied on each page of Nuxeo.
Common Tab
The Common page is where you will specify the main elements that define a branding: the logo, the colors and the font used by the default
view in Nuxeo.
Changing the Logo displayed on Header

Before
Studio Configuration
After

13
In this section
Common Tab
Changing
the Logo
displayed
on Header
Changing
the Header
and Footer
Additional
Branding
Elements
Login Page Tab
Common
Changes
Additional
Options
CSS Editor Tab
Declaring a
New CSS
Class and
Its Rules
Overriding
an Existing
Rule
Specifying the
Default Branding,
Disabling a Theme
Branding
Specifying a
Default
Branding
Disabling a
Theme
Branding
Changing the Header and Footer

Before
After
Additional Branding Elements

14

The additional branding elements section contains all the customizable elements relative to the page contents: links colors, font family used,
color of backgrounds and borders.
Result
Login Page Tab

This tab will let you manage the customization of the login page view.
Common Changes
Basic Studio Configuration
Steps
1. Select a background image. Be careful not to use an image

too heavy to a quick display for the users.
2. Define a position with horizontal or vertical alignment (in pixel
or position) if you know that your image will be large enough
for the huge screen resolutions.
3. Or make the background cover all the screen ( with CSS3 /
recent browsers).
4. Pick a color that will be displayed if the background image is
too small and not covering all the screen.
That's it!
Most of our customers apply the following strategies for their login page background image:
A picture covering all the screen. This is the strategy chosen by Nuxeo.
Or a logo with transparency as the background image, aligned on the top left (Horizontal alignment = top, Vertical alignment = left) +
a background color.
With a web designer's help, you can have many other possibilities.
Additional Options

15

Login page layout
Role
To let you customize the login screen
completely, the header, news and footer
can be removed.
If you have a simple color used as the
background image in the login page, you
can add a light pattern or a color to the
login box.
CSS Editor Tab
This option must be used carefully: don't

The CSS Editor is dedicated to web designers who know CSS and its syntax. It's the place to declare
your new
CSSor
rules
or override
existing
use heavy
patterns
things
that will make
rules that will be used into the Nuxeo main tabs: Home, Document Management and Admin Center.
the readability difficult or hamper the
interpretation. The login box style must stay
simple
and light
keep the login
Have a look at the Nuxeo UI Style Guide to see all the existing CSS rules used by defaultvery
in your
platform,
andtounderstand
more ab
action as a user-friendly step.
out readability, usability, layout design, and user experience.
Declaring a New CSS Class and Its Rules

You can add style classes in your widgets in forms, content views, and tab layout to manage the rendering of your elements.
Let's add a background color on a widget's container:
1. Widget Editor
Define a class in the widget editor.
2. CSS Editor
3. Result
Declare your blue background in the CSS

Editor.
Enjoy your blue container.
Overriding an Existing Rule

You want to change an existing style to fit your needs? In addition to the Nuxeo UI Style Guide that explains the default set of CSS existing
rules, you will need to use a browser's web inspector to understand what to override.
Let's display the main title of pages in pink:
1. Inspect the existing style
2. Declare your new rule
3. See the result

16

The pink arrows show the main title at the
top of the page, the code and its CSS
declaration are at the bottom, in the web
inspector. Seeing this, you will need to
override the .galaxyDefaultCSS**** h
1 rule that contains the color declaration.
You can use the parent CSS classes,
underlined here in green, to have a stronger
CSS selector than the default one.
Your rule contains three selectors: .conte

nt, .mainFragment and h1. That way,
you're sure that your new style will be
stronger than the original style declared
with only two selectors: galaxyDefaultC
SS*** and h1.
Your title is pink now. You can see that your

new rule is displayed at the top of the
default one, and the original black color
value is striked, so not used anymore.
Specifying the Default Branding, Disabling a Theme Branding

Specifying a Default Branding
Create a new branding implies that it will be the default branding used in your application. The checkbox displayed under the Common tab will
be checked by default. If you created several brandings, be sure that only one of them is checked. Your branding will be used in your
application everywhere except if a local theme configuration is set.
Disabling a Theme Branding
If you don't want to use your branding during a test you can disable your default branding without deleting it.
Just tick the Disable theme branding option above the tabs. The tabs and their content will be displayed under a gray overlay.
Related topics in this documentation

Nuxeo Studio quick start guide - A practical approach
Branding
Migrating My Branding to 5.5 New Branding System
Specific Upgrade Instructions

17
Customize theme the hard way

Theme How-To Index (Nuxeo Platform Developer Documentation)
Theme (Nuxeo Platform Developer Documentation)
How to Override a Default Style (Nuxeo Platform Developer Documentation)
How to Brand Your Application (Nuxeo Platform Developer Documentation)
How to Customize the Error Pages (Nuxeo Platform Developer Documentation)
How to Customize the Login Page (Nuxeo Platform Developer Documentation)
How to Show Theme Fragment Conditionaly (Nuxeo Platform Developer Documentation)
How to Add a New Style to Default Pages (Nuxeo Platform Developer Documentation)
How to Declare the CSS and Javascript Resources Used in Your Templates (Nuxeo Platform Developer Documentation)

Migration in Studio is automatic, but you can keep your old branding for the 5.5 target platform if it still suits: only a warning will be visible to
encourage you to use the new system, and you can still come back to the old branding if you'd like to perform the migration later.
If you already defined a branding and are now using a 5.5 target platform or more recent, migration instructions will be visible on the page:
The login page and logo configuration have not changed, but customizations of palettes (backgrounds, borders, colors and fonts) have been
modified to make it easier to use, and to make them match the new default branding.
Note that the migration process will keep some of the palettes customizations you did, but some will not be kept as they are not available for
customization anymore. Improvements to make it possible for you to define your own CSS customization are on the way.
If you were customizing the theme layout in a third-party module (to change one of the theme views for instance), you should be aware that
after migration, this structure is not generated anymore: the theme to override will be the default one (galaxy) instead of the customized one
(this theme used to be named after the studio project id if it was the default one).
Also, if you were overriding it only for the page structure, but still want to use the branding defined through Studio, you can remove all styles
from this definition as explained in the Migrating my Customized Theme documentation: maintenance will be easier after these changes.
Related topics
Nuxeo Studio quick start guide - A practical approach
Branding

18
Create multiple themes

TODO
Content Model
Schemas
Documents
Life cycle
Structure Templates
Schemas
Concept
A schema in Nuxeo Studio is dedicated to define a list of metadata. There is no UI definition in this section, it is just a storage definition.
If you are not comfortable with this typical ECM notion, please read more about documents, properties and schemas in the theoretical
introduction.
Note that schemas can be defined directly from the Document type feature. One would configure a schema here when sharing of the
definition among multiple document types is known from the beginning.
Creating a Schema
To create a schema, click on New.
Feature ID: The id of the schema. Will be used as the technical id of the schema. It should not contain spaces or special characters.
Schema Prefix: Prefix of the schema. Prefix is used when referencing a document property (ex: dc:title for the Title property in the
Dublin Core schema), for instance in an NXQL query.
Schema names and prefixes
You should carefully choose your schema names and prefixes. There will be many references to them in your project (layouts,
automation, NXQL queries). Nuxeo Studio doesn't yet handle completely schema refactoring. Furthermore, once you deployed, if
you change a schema name or prefix, you will have to operate a data migration.
We suggest you to use name like my_schema_name (lowercase, word separated by an underscore) for the feature id and
something shorter for the prefix like msn (without reference to the dead IM :)). See the Naming Conventions page for more tips on
ids and names recommendation in Nuxeo Studio.
Advanced configuration (available for 5.7 Nuxeo Studio project):

Mode:
Default: the schema is editable in Nuxeo Studio from scratch, with Studio capabilities;
Initialize: the schema is editable in Nuxeo Studio with Studio capabilities, and is pre-initialized from an external resource
(see the Resources section),

19

Import: the schema is not editable in Nuxeo Studio, it is initialized from an external resource (see the Resources section)
and is deployed with your Nuxeo plugin,
Reference: the schema is not editable in Nuxeo Studio, it is initialized from an external resource (see the Resources section
) and is not deployed with Nuxeo plugin. This is useful if the schema is deployed from another Nuxeo plugin but you need to
refer it in your project.
Allow nested complex types: By default, you can only choose one level of Complex type, but if you select this parameter you will
have the possibility to have a Complex type at each level of your schema. Make sure that this is useful for your application before
choosing it.
Editing a Schema
Add field:
Name: the name of the property useful to reference it (see the note below).
Type : the type of the property. Complex type will let you define a complex field like an address storing street, zip code, etc...
for instance.
Multi-Valued: if you want the property to be a list (a list of Blobs, a list of booleans, a list of Dates, ...)
Default Value: sets a default value on the property at document creation time.
Delete field: delete the selected line. (Although it is a checkbox, you can delete rows only one by one.)
You should carefully choose the field/property names, as changing them after going live requires a data migration. Furthermore,
Nuxeo Studio doesn't handle property refactoring completely yet.
Related pages
How to Add Complex Fields on Your Document Type
Content Repository
Documents
Concept
Read more about documents, properties and schemas in the theoretical introduction.
Creating a Document Type

To create a document type, click on button "New".

20
In this section
Concept
Creating a
Document Type
Definition Tab
Schema Tab
Creation, Edition,
View and Header
Layout Tabs
Tabs - Default Tabs
Filtering
Tabs - Content
Views
Feature ID: The id of the document type. Will be used as the technical id at generation. Convention is to use a capital for the first
letter.
Extend: The document type that the type being created will extend. Local types are the ones created in your Studio project. Default
types are the ones part of the Nuxeo distribution you use (Nuxeo DM 5.6, ...)
Adding a custom type
if you don't find the default type you are looking for, you can add it using the custom type registry.
Label: You can put here a label or an i18n key.
Description: The description of the document type. This description is here for information purposes.
Definition Tab

21
Extends: See the Creating a document type section of this page.

Label: See the Creating a document type section of this page.
Category: The category defines in which column the document type appears on the "new Document" pop up in Nuxeo DM. If you
don't want to use the default categories, you can add a new one using the custom document category registry.
Icon: The icon that will be displayed in the default list view. Note that you can upload new icons on the resources section.
Large Icon: The icon that will be displayed in the "Available document types" pop-up and the Icon view (view available up to Nuxeo
Platform 5.8). Note that you can upload new icons on the resources section.
Default view: The default JSF view. This is a technical attribute that you probably don't want to change (will be moved in an
advanced section in the future).
Lifecycle: the lifecycle the document will follow. The theoretical introduction gives more conceptual details about lifecycle. You can
use a lifecycle that you defined in Studio.
Container types: The document types selected here are the ones from which it will be possible to create the document type being
designed.
Accepted children types: The document types selected here will be creatable just under the document type being designed. This
attribute only appears for document types that have the "folderish" facet.
Document Facets: Read the theoretical introduction for better understanding of what facets are. If you don't find the facet you are
looking for, you can add it using the custom facet registry.
Inherited schemas: The schemas that are hold by the document type because the document type inherits another one. If you
change the "Extend" attribute, this list might be affected. You cannot modify directly the inherited schemas.
Add extra schemas: Use this selector to add schemas that are defined from the schema feature.
Deployment mode: This is particularly useful when you declare a document type that already exists in the default product from
Studio, for instance "Folder", or "File". When the contribution generated by Studio is deployed on Nuxeo DM (for instance when you
click on "Update" from Admin Center), either you want to delete the previous definition, and use only what was defined from Studio (o
verride), or you just want to "complete" the definition from what you configured in Studio ( merge). A concrete example is: by default,
an icon is defined for the Folder document type. If you redefine the folder document type from Studio and don't configure the Icon
and Big Icon attributes, then if you select "override" for Deployment mode, your folders won't have any icon, while if you select
"merge", they will keep the icon that was originally defined.

22
Schema Tab
This is where you can define a schema for your document type. This tab is provided for simplicity and a wizard-like approach. But it is
equivalent to defining the schema from the schema feature and assign it from the definition tab. Read the schema section for more
information on how to define your schema (same screen and buttons).
Creation, Edition, View and Header Layout Tabs

On those tabs, you can respectively configure the creation, edition, view and header layouts of the document type you are designing. They
work like the form layouts feature, thus you can follow the same instructions. There are a few differences/additional features:
The Header layout, which is not on the form layout feature is the part that is displayed on top of the tabs when viewing a document.
By default, it displays the title and the description.
You don't have to reference the layout anywhere, they will be bound automatically to the document type you are configuring.
External Layouts: it is possible to "compose" the creation/edition/view/header layouts as being the aggregation of multiple layouts
that are created from the form layouts feature.
Tabs - Default Tabs Filtering
Documents in DM are displayed with a series of tabs to display all the actions that can be done on documents. By default, a new document
type will hold all the tabs. From this view in Studio, you can disable some of them, for the document type you are configuring. This is a binary
activation/inactivation. If you want to refine the tabs display rules, you can contribute XML extensions to the action service, so as to override
existing contributions (for advanced users).
Tabs - Content Views

23
Content view tabs are tabs that display a list of documents in a table, that is the result of an NXQL query (a content view). You can read more
about content views in the theoretical introduction to Studio. You configure the content view with the content view feature and just reference it
here.
Main content: you can choose which content view is used for the document you are configuring. This appears only for document
types that are folderish.
Trash content : you can choose which content view is used for the document that are displayed in the trash. This appears only for
document types that are folderish.
Additional tabs configuration:
Label: The name displayed for this new tab. Can be a translated key.
Content views: You can reference several content views that will be displayed one after the other.
Order: The place of the tab on the document . You can put numbers like 0, 5, 10, 40, 150, ...
Tab enablement: (TODO: a specific page for this screen that appears in many places on Studio).
Using the Tabs feature
Adding a tab that displays a content view using this feature is easy and straightforward, but you can also use the Tabs feature that
provides more refinements like the ability to add buttons, other information, wrappers, etc...
Related Howtos
How to Automatically Convert a Document to PDF
Life cycle
Concept
A life cycle is a set of states and transitions that apply to a document. One of the states is marked as being the "initial state" and is the state of the
document when it is created. States that the document can hold depend on the transitions that are set between the states. Default life cycle in
Nuxeo contains following states: project, approved, obsolete. One could see life cycle just as yet another metadata with a controlled list of values,
but actually the framework provides API around life cycle management, such as ability to "reset" the life cycle of a document, and ability to " follow"
a transition..
Editing a life cycle

24
You need to drop one and only one initial state.

You can drop as many states as you want.
From one state you can pull an arrow to another state and give a name to the transition by clicking on the edit icon that appear if you let
the mouse over.
Filling transitions name is not mandatory, the system will automatically name them with the rule : "to_"+state name.
It is possible to have several arrows with the same transition name.
Structure Templates
Concept
When thinking of the structure of your repository, you might identify block of structures that will always be the same. For instance, by default with
Nuxeo DM, when you create a Domain, you get subfolders Workspaces, Sections and Templates. You might also want such behavior when doing
case management, so as to organize the structure of your case, ... Structure templates are actually a way of defining an automated structure that
is bound to a folderish content type.
In simple words: "Each time I create a document of such type, I will also instanciate children documents of this type and this type... with this ACL
(security) configuration". With Studio, you can contribute several of such rules.
Special case: Creating any child of the Repository Root

When Nuxeo is first deployed, the Nuxeo software creates a database containing a default domain which is a child of root of the Nuxeo repository.
Since the root direct descendants are only created when the Nuxeo repository is first created any documents (Domains, Workspaces, etc) which
are direct descendants of the root and which are added AFTER the repository is created need to be created within the repository as children of
the root.
A solution is to create your Nuxeo instance and connect it to your Studio project and update the project with the new documents which are the
children of the repository root. After the installation and Studio update, stop Nuxeo, delete(drop) your database and then restart Nuxeo. Because
the Studio .jar file containing the Case Document Domain has been included in your Nuxeo image, the new database created will contain the
Case Document Domain as a child of the Repository root.
Suppose you cannot Drop your Database?

If you cannot drop your database because you have data that needs to be saved an alternate approach would be to build a Nuxeo Automation
User Action (Button). This button will create the Case Document Domain as a child of the repository root without needing to drop then recreate the
Nuxeo database.
Creating a new Structure Template

25
Feature ID: Technical ID of the feature

Target document type: The document type for which the structure template that will be defined will be applied.
Listings & Views

Content Views
Form Layouts
Search / Advanced Search The Nuxeo Platform 6.0 Search menu item enables you to set up a new Default Search form to
replace the one available in the Nuxeo Platform Search tab. The Advanced search menu item available for previous
versions of the platform enables to define a new Advanced search form.
Tabs
Virtual Navigations
Content Views
Content view is the Nuxeo technology used to define a list of documents to display. The Nuxeo Platform uses this technology in these following
cases:
Content tab Listing
Search
A Content View is defined by three notions:

A query: defines a request on the document repository to express the list of documents to display,

26

A form: lets the user express additional information about the request in your final application (ex: advanced search form, faceted form,
post-filtering in content tab),
A display result: A description of how the listing result is displayed.
Here is how these notions are visible in the Nuxeo Platform interface:
Content tab Listing
Search
Content View Configuration Overview

Each part of the content view definition in Studio is dedicated to configure each notion explained above:
Query definition:
Form definition:

27
Result Display definition:
Once you defined your content view, you can use it for these following cases:
as the Content tab of your document type
in another tab of your document type

28

as a search form in the Search tab (from Nuxeo Platform 6.0)
as a faceted search (before Nuxeo Platform 6.0)
as an advanced search (before Nuxeo Platform 6.0)
The following pages explain how to configure each part of a content view.
You can also have a look at the technical documentation about Content Views.
Content View: Query & Form Tab

This page explains the Query & Form tab in the content view definition.
This tab lets you define:
The usability of the content view in local configuration
the filtering UI proposed to the end user
Some advanced configuration about filtering
Default Filtering Definition

This section explains the following elements of the Query & Form tab:
Here are the fields you can play with:

Use Elasticsearch index: Lets you use the Elasticsearch aggregates
Query filter: Lets you manage where clauses (filtering expression) applied by default
Query parameters: Lets you set dynamic expressions in your default where clauses
Default sort: Lets you set the default sort applied to the result list
Use Elasticsearch index
Starting from Nuxeo Platform 6.0, Elasticsearch is embedded in the platform. Check this box to be able to use the Elasticsearch aggregates
widgets in the form definition.
Query Filter Field
Defining the query lets you define the list of documents you want to show in your content view if no information is set by the Nuxeo user.
The Nuxeo query system is based on our NXQL technology, which is very similar to SQL query expression. For those who know SQL, using
NXQL will be very easy. For those who are not familiar with SQL, you can read the NXQL dedicated documentation and look at some NXQL
examples .
You don't have to specify the SELECT * FROM Document part of the request that is automatically managed by the content view. If the Quer
y filter field is empty, then there is no restriction. So it displays all documents, including:
Deleted documents,
Versioned documents,
Technical Documents normally hidden from end users,
etc.
By default, Nuxeo Studio fills this field to filter out:
documents marked as hidden in navigation (ecm:mixinType != 'HiddenInNavigation')
documents that are not archived versions (ecm:isCheckedInVersion = 0)
and documents that are deleted (ecm:currentLifeCycleState != 'deleted')

29

You can change or remove these filter clauses if you wish.
By default, this field is limited to static filtering (specific document type, specific date, specific life cycle state, etc.). If you want the content
view filter to be based on the context of execution, you can set some "where" clauses to apply by default to the result list. See the next
section.
Query Parameters Field
The Query Filter field enables you to express the "where" clauses of your content view filter. The query parameters field lets you define a
"where" clause based on the execution context. For instance:
The current date (for instance documents issued before today)
The user that displays the content view (documents created by the current user or to which the current user has contributed)
The currently displayed document (its document children, descendants or documents linked to the current document)
To express a dynamic expression:
1. Write your where clause in the Query Filter field but with a question mark as the right value (for instance ecm:parentId = ?),
2. Define the dynamic value in the query parameters field.
Here are some examples.
Query filter
Query parameter
Keeping the documents created by the

current user
dc:creator = ?
#{currentUser.name}
Keeping the children documents of the

currently displayed document
ecm:parentId = ?
#{currentDocument.id}
Keeping the descendant of the currently

displayed document
ecm:path STARTSWITH ?
#{currentDocument.path}
dc:issued < ?
#{currentDate.toString()}
Note that this request is less efficient than

the previous one.
Keeping documents issued before today
When your query filter has several ? parameters, you must add the query parameters in the same order as the criteria in the query filter.
More information on NXQL and examples are available on the dedicated page in the developer documentation.
Note to people familiar with Nuxeo products customization: The syntax that is to be used in those parameters is the same EL syntax as the
one used in XHTML files. You have access to the SEAM context. Other sample expressions:
#{currentDate.toString()}: that can be used with date properties, like dc:created > DATE ?
#{currentDocument.dc.rights}
#{empty currentDocument.getProperty("dublincore","subjects") ? '%' : currentDocument.getProperty(
("dublincore","subjects" )} for multivalued property
Default Sort Field
The Default Sort field lets you express the default sorting applied to the results list. The end user can choose the sorting in the UI based on
column actions. If you want more information about that look the Result tab documentation.

30
You can sort through:

A field of the listed documents,
A property of the listed documents (life cycle state, lock date, lock owner, etc.).
To sort through a field:
1.
2.
3.
4.
Click on the Add button.

In the first drop down list, select the schema in which the field is defined.
In the second drop down list, select the field.
Check the box Sort ascending box if you want ascending sorting (alphabetical, chronological, etc.).
To sort through a property:

1.
2.
3.
4.
Click on the Add button.

In the first drop down list, select system.
In the second drop down list, select the property.
Check the box Sort ascending box if you want ascending sorting (alphabetical, chronological, etc.).
If you want to sort through multiple criteria, just repeat the steps above for each criterion.
Flags
This section explains the flags section and what the different flags enable.
Search content view: Since Nuxeo Platform 6.0. Enables to have your content view available in Search tab drop down list. Selecting
this flag makes the Search layout required so as to have a search form displayed in the Search tab. It also adds a tab Enablement on
the content view in Studio to define when the content view should be available in the Search tab.
Document content: Enables to use your content view on a custom tab, or to have it available in the local configuration of a
workspace.
DAM: Enables to display the content view in the DAM tab.
Since Nuxeo Platform 6.0, the flag is available when you select the target package Nuxeo DAM Compat.
Faceted search: Since Nuxeo Platform 5.7. Enables to display the content view in the Faceted search tab and have it available in
the local search configuration of a workspace.
Since Nuxeo Platform 6.0, this flag is available when you select the target package Faceted search.
Advanced search: Enables to have the content view available in the local search configuration of a workspace.
Since Nuxeo Platform 6.0, this flag is not available anymore. You should use the Search content view flag instead.
Check out the page Specific Upgrade Instructions migrate your content views to Nuxeo Platform 6.0.
Search Layout
This section is focused on the search layout definition:

31
This is where you define the form, by drag and dropping widgets from the right panel into the form.
In this section
Default Filtering
Definition
Use
Elasticsearc
h index
Query Filter
Field
Query
Parameters
Field
Default Sort
Field
Flags
Search Layout
Content View: Results

Once you've defined the query and form of your content view, you can define how to display the list of documents that match the query.
Search results, and so content listings, are presented in a table. You can configure the columns, i.e. the information on the documents that
should be displayed in your content view. This is done in the Results tab of the content view.
General Configuration
The first section of the Results tab enables you to define some general configuration on the content view results.
Number of results per page: The default numbers of documents displayed by page
Enable the user to edit displayed column: Enables the user to edit the search results displayed
Enable spreadsheet action: Enables the user to use the Nuxeo Spreadsheet features from the content view results.
Enable common actions (copy, paste, delete...): Makes the generic bulk actions available when user selects one or several
documents
Enable additional actions: Makes it possible to use custom actions on documents displayed in the content view. Click on Create a
new action to create the action to use.
Results Columns

32
To define the results layout:

1. Select a widget in the right panel.
2. Drag it on the results grid and drop it on a Drop widget it here cell.
3. If necessary change the widget type and properties and click on Save.
4. If necessary click on the icon
of the blue header cell to edit the Column title properties:
Label: The column title
Label for column selection: The label of the column in the Edit available data pop-up
Translated: Check the box if the labels are internationalized
Style class: Indicate the custom CSS class if any
Sort property: Select how content should be sorted when user clicks on the column title
Other options in the Result columns section are:
Reference an existing table layout: Check the box to use a layout defined in the Table layout section. This hides the results grid.
Display layout mode selection: Makes the views available on the content so users can change the way the document list is
displayed.
Additional result column: Select the columns that should be displayed in the Edit available data pop-up.
Advanced Configuration
You can set some advanced configuration on the content results. Click on the icon
a look at the technical documentation about Content Views.
of each field to know how to use it. You can also have
In this section
General
Configuration
Results Columns
Advanced
Configuration
Content View: Enablement

If you selected the Search content view flag on the Query & form tab of the content view, you get an additional Enablement tab. This tab allows
you to define under which circumstances the content view should be displayed in the Search tab drop down list. It shows the options below:
Action order: Select the place of your content view in the Search drop down list. 0 makes the content view the default one.
Current user is a member of: Indicate if the user needs to be member of a specific group to be displayed the search form.
Current user is administrator: Indicate if the search should be restricted to administrators.
Custom EL expression: See the page Understand Expression and Scripting Languages Used in Nuxeo.
You can report to the page Filtering Options Reference Page for more information about each of these options.
Form Layouts
Concept
The form layouts feature enables to design forms and data display screens that you can map to document properties. Read more about layou
ts. Forms configured on this feature can be referenced in various places:
On other layouts (the one you define directly on the document type)
From a layout widget

33

From a togleable form widget
Directly in your own XHTML templates, if you are a Nuxeo Platform developer
In this section:
Concept
Form Layout
Creation
Creation Layout Tab
The Layout
The
Widgets
Palette
Configuring
Widget
Properties
Configuring
Widgets of a
Complex
Property
Edition and View
Tabs
Form Layout Creation
Feature ID: Technical id of the feature.
Creation Layout Tab

The Creation Layout is displayed just when the document is created in Nuxeo, after having clicked on the New button and selected the
document type.

34
The right part of the screen is called the "widgets palette". The middle is the "layout" (the data grid or form). You can pick up widgets on the
right, drop them on the layout, and then edit the properties of the widget (they are documented inline).
The Layout
Add Row: The action to add a new row on the listing. The data and form components will be displayed following the grid. You can
also add a row in a specific place by right-clicking
Add Column: The action to add a column. You can also add a column in a specific place with the right-click.
Set Table Size: Specify rows and columns number.
Using this feature will overwrite what has already been configured.
Import Layout: Enables to literally "copy/paste" the configuration you did for other layouts (Edit, or View or Header). You want to use
this to gain time.
To Nuxeo Platform developers
Contrary to what can be done at lower level with the layout framework, you need to redefine the layout for each mode
(Nuxeo Studio actually doesn't leverage the layout mode). This was done for purpose of simplicity. In the future we might
propose a solution that enables to also leverage layout modes.
Style class: You can specify a class that will be applied to all the area surrounding the form. You can either use an existing class
that you will find on the style guide or contribute your own class on the Theme feature.
Widget Display: You can control whether you want the form label just on top of the input or on the left, or to remove the display of
the labels.
Layout Template: It is an advanced option, for Nuxeo Platform developers. The widgets are displayed using an XHTML template
(JSF Facelets template). You can upload your own templates if you want to do some deeper changes on the way the data/the fields
are displayed. We propose you to download the default one used so as not to start from zero.
If you use a custom layout template, you will then have to maintain this template when upgrading the Nuxeo Platform
version and make sure it is still compatible.
The Widgets Palette

Widgets by Property: You can browse the schemas (default ones and the ones you configured in the Studio project) and then
choose a specific property. That way, the widget will be automatically mapped to the property you chose, and Studio will suggest only
the widget types (calendar, lists, etc.) that can work with the property you selected.
Widgets by Type (under More Widgets): You can browse all the existing widget types. You will then have to map the widget to a
property, by browsing the schemas and properties. This is a good way for handling the display of only a sub-property of a complex
property.
For Nuxeo EP developers
There is currently no widget type registry for uploading custom widget types. But you can use the generic widget to specify
a widget type that you contributed in another plug-in.

35

Built-in Widgets: Built-in widgets are widgets where you don't have to configure neither the document property mapping, nor the
widget-type.
Advanced Widgets:
Container: The container widget enables to add a visual wrapper around a set of widgets. If you drop a container widget,
you will have several options for controlling whether the wrapper should be foldable, folded or not, should have a title, ...
Then you will be able, inside the container, to edit a grid with the widgets you want to display.
Layout: The layout widget can be used to reference a complete layout definition. All the widgets that were defined in the
referenced layout will be displayed where you drop the widget.
Template: The template widget is the most permissive widget: you choose the property (or properties) to which you want to
bind it, you choose the XHTML (JSF Facelet) you want to use, and you can value the properties that your template expect.
Custom templates can be uploaded in the resources feature. For more information, you can refer to the documentation about
custom widget templates.
Configuring Widget Properties
When you dropped a widget, you will be able to configure the properties of your widget, the field mapping, the widget type, as well as some
custom properties if you want. Just let your mouse on the question mark icon to see what the property is about.

36

There are a few important and generic things to know about this screen:
Advanced mode configuration: Enables to display conditionally a field, and to decide whether the data is just displayed or can be
edited. Conditions might be user properties, document properties or anything contextual. For more information about the display
mode, see the page How to Control the Display Mode of a Widget.
Edit properties vs view properties: If you entered an advanced mode configuration expression, you will have both view and edit
tabs for configuring widget properties. Indeed, it is usually not the same options that are to be configured.
Widget property override using custom properties: You can use an EL to configure the built-in properties like "Required", etc ...
You just need to contribute the id of the property and the EL expression you want to use with brackets #{}.
Configuring Widgets of a Complex Property

If the property is complex, you will have to configure several widgets (as there are several sub properties). That's why there is one more icon
on the widget representation in the grid:
Clicking on the icon
, you will be displayed the following screen:
By default, Studio will organize all the sub properties with a simple input text widget or a date, or anything, depending on the sub-property
type. But you can re-arrange the widgets, or delete them and pickup again the sub-property on the widgets palette on the right, and also
insert some build-in widgets, like a header that produces a separation, or a template widget, etc.
Currently, complex properties configuration using schema feature limits the complexity at one level. You can go over this limitation
by importing your own XSD. The layout editor will know how to handle the multiple levels.
Edition and View Tabs

Once you configured the form for the creation view, you can do it for the the Edition and View (read-only) modes, following the same
instructions than on the Creation Layout tab.

37
Related Howtos
How to Add a New Widget to the Default Summary Layout
How to Use a Generic Widget in Layouts
How to Use a Generic Widget in Layouts
How to Add a New Widget to the Default Summary Layout
How to Create a N-Level Select Widget
How to Customize the Versioning and Comment Widget on Document Edit Form
How to Add a New Action Category on a Document Tab
How to Customize the Versioning and Comment Widget on Document Edit Form
How to Create a N-Level Select Widget
How to Control the Display Mode of a Widget
How to Control the Display Mode of a Widget
How to Add Field Validation
How to Set a Default Date on a Field at Document Creation
How to Add Field Validation
Showing first 15 of 16 results
Search / Advanced Search

Default search configuration is defined the Search menu item in Nuxeo Platform 6.0. For previous version, it is set in the Advanced
Search menu entry.
The Nuxeo Platform 6.0 Search menu item enables you to set up a new Default Search form to replace the one available in the Nuxeo
Platform Search tab. The Advanced search menu item available for previous versions of the platform enables to define a new Advanced
search form.
It is basically a content view that is preset to be a search content view. So it shows the same tabs and configuration features as a content
view with the differences below.
Logically the Flags section of the content view definition is not displayed here.
Since it is meant to replace the default search, it doesn't show the Enablement tab available for other search content views. (From
Nuxeo Platform 6.0)
Please report to the Content Views documentation.

38
Related Documentation
Content Views
How to Configure a New Search Tab
Tabs
(TODO: the format of this page should be updated to follow the same approach as with other feature)
Concept
When you create new document types, you often need to have specific tabs on these document types that display information relevant to
your users. A Tabs menu item enables you to create customized tabs on which you can define the elements you want to be displayed:
widgets, layouts, content views, actions bars. You can also define the conditions that should be met to display the tab (on which document
types the tab will be available, for which users, etc).
The Tabs feature is available from Nuxeo Platform 5.6.
Creating a new tab

To create a new customized tab:
1. In the the Listings & Views item of the Studio tree, click on Tabs and click the New button.
2. On the creation form, type the name of the tab.
A default grid with two columns is available by default, that you can either fill in or edit.
You can now define what will be displayed on your tab and when the tab should be displayed.
Definition tab

39

The definition tab is used to set up what should be displayed on your tab.
Label: Name that will be displayed to the users.
Category: defaults to "document category". More categories can be added using XML extensions.
Order: order in which the tabs will be displayed from left to right. The higher the number, the more you move the tab to the right side
of the screen. Default tabs number start at 10, so you should add a 2 digits number at least in this field if you expect your custom tab
to be placed after the default ones.
Add grid row: This button helps in defining the grid structure you would like to obtain. Click on Add Grid Row and, in the pop up
window, click on the row type that you want to add.
You can reorganize the rows by clicking on the row icon
and select the wished option in the window that pops up.
Drag and drop widgets from the left box into a cell (see the main widgets below).
The widget editor window pops up.
Click on Save to save your modifications, both in the widget editor and in the main window.
Enablement tab
The enablement tab defines when the tab should be available.
1. In the form, select the conditions that must be met for the tab to be displayed. For instance:
In the Current user has one of the permissions multi-select box, select the permissions the user must have to be
displayed the tab;
In the Current document has one of the types multi-select box, choose the documents types on which the tab will be
displayed;
In the Current document has facet drop-down list, select the facet that the document must have for the tab to be displayed;
In the Current document has life cycle text box, type the lifecycle state the document must be in for the tab to be
displayed;
In the Document path starts with text box, type the path the document must be in for the tab to be displayed;
In the Current document is drop-down list, select the kind of document must be for the tab to be displayed;
In the Current user is member of text box, select the user group the user must be part of for the tab to be displayed;
Check the Current user isadministrator checkbox if you wish to restrict this tab to administrators group members only;
In the Custom EL expression text box, type an EL expression that should be evaluated for the tab to be displayed.
Keep in mind that requirements are cumulative; the tab will be displayed only if all previous conditions defined are met. You may
leave fields blank if you do not wish to apply some of the restrictions available.
2. Click on Save to save your modifications.
Tab specific widget types

Content view widget type
The Content view widget type is available from the menu on the right on the Definition tab. It enables you to display a content view defined in

40

the Listings & Views > Content Views menu item inside the slot in which you drop the widget. You can use any content view previously
defined.
When should I use a content view widget ?
This widget type is usually combined with a tab in order to create specific content tabs, showing for example a substring of documents
depending on their life cycle state. As you can add as many content view widgets as you like, you may achieve various display results that
would not have been possible using a single NXQL query.
Toggleable form widget type

The Toggleable form widget type enables you to display two layouts alternatively, using a predefined user action to switch from one layout to
the other.
When should I use a toggleable form widget ?
Typically, this widget can be displayed to enable users to edit a document without having to go on the Edit tab of the document, but using an
Edit button. In that case, the used layouts would be the View and Edit layouts of a document.
Layout(s): Use the "choose" button to select which form layout you would like to display as first layout.
Toggled layout(s): Use the "choose" button to select which form layout you would like to display after clicking on the toggle action
button.
Form action(s) widget types

Since version 5.7.1, the Form action(s) widget types enable you to display buttons that interact with a layout form (like save/cancel buttons).
Actions can be selected using a category on the "Form actions" widget type and using the action name on the "Form action" widget type.
Toolbar action(s) widget types

Since version 5.7.1, the Toolbar action(s) widget types enable you to display buttons that do not interact with a layout form. The main
difference with form actions is a finer control over forms and labels. Actions can be selected using a category on the "Form actions" widget
type and using the action name on the "Form action" widget type.
Tabs widget types

Since version 5.7.3, the tabs widget types enable you to display tabs within your tabs (aka sub tabs). Here is a sample configuration. The
parent tab "MyTab" holds a "Tabs" widget type:
The "Tabs" widget type is configured as is (it uses the "MyTab sub tab" category):

41
Sub tabs can be defined as standard tabs, but using the "MyTab sub tab" category:

42
In this section
Concept
Creating a new tab
Definition tab
Enablement tab
Tab specific widget
types
Content
view widget
type
Toggleable
form widget
type
Form
action(s)
widget types
Toolbar
action(s)
widget types
Tabs widget
types
Related How-To's:
Add a new Permission in the UI
Content Views
Create a mail template
Override email notification templates
Search / Advanced Search
Tabs
Virtual Navigations
The Virtual Navigations menu entry enables you to define new browsing trees based on document properties. You can install the Nuxeo Virtual
Navigation add-on to see how default virtual navigations based on the vocabularies Subject and Coverage work. This page explains the different
options available on the Nuxeo Studio configuration screens.
A virtual navigation is a content view whose filter is not displayed as a form but as a tree that shows the values of a vocabulary.
Definition Tab

43

Label: The label that will be displayed as a tooltip on the virtual navigation tab.
Breadcrumb Label: The label displayed in the breadcrumb from virtual navigation results.
Property: Select the schema and the property on which should be used to filter documents.
Additional query filter: Indicate the basis of the query that will be applied automatically applied.
Excerpt not found
The page: Content Views was found, however the excerpt named: studio-default-query-filter was not found. Please check/update the
excerpt name.
See the page Content View: Query & Form Tab for more details.
Default sort:
Vocabularies: Select the vocabularies that should be used to display the property values in the tree.
Icon: Select the icon to display in the virtual navigation tab.
Enabled: Uncheck if you want to disable this navigation tree.
Results Tab
The configuration of the content view results is the same as a regular content view. Please report to the page Content View: Results.
Workflow
The Nuxeo Enterprise Platform workflow engine, a.k.a. Content Routing, aims at providing a framework and tools for automatizing some
content-based organizational processes in a maintainable way. It can be used as soon as you have a multi-steps process that involves various
human actors and automated steps. It will accelerate the roll-out of your realization and make it easily understandable for future evolutions. Such
multi-steps process can be complex documents authoring and validation (purchase order validation, product sheet, ), form flow (such as
vacation request, training requests, expenses, travel authorization), and, of course, usual office document validation process.
You should first read the Workflow pages of the Customization and Development section of the technical documentation for knowing more about
workflows. On the Studio documentation area, you will find details about the Studio screens and a tutorial to start using the workflow engine.
Workflow screens
Node popup
See also the step by step example.
Workflow screens
You will find here as many pages as you have screens on the Workflow feature. See also Node popup.
Workflow creation form
Definition tab
Variables tab
Availability tab
Graph tab
Workflow creation form
Feature ID: The id of the declared workflow template. Useful for starting a workflow with automation.
Label: The label that is displayed in Nuxeo in the drop down list that launches a workflow. Supports i18n.
Description: The description should be displayed beside the drop down list that launches a workflow, then the corresponding workflow is
selected.
Definition tab

44
Label: The label that is displayed in Nuxeo in the drop down list that launches a workflow. Supports i18n.
Icon: Currently not used.
Large Icon: Currently not used.
Description: The description should be displayed beside the drop down list that launches a workflow, when the corresponding workflow
is selected.
Variables tab
Variables at workflow level can be used to store information that can be accessed at any time during the workflow. Those variables will store data
that come from user forms or that are computed by automation chains, using from their the WorkflowVariables[] object.
Name and Prefix: You don't have to modify this.
Add variable: Adds a new row on the variables table.
Delete variable: Deletes selected variable. You can select only one variable at a time.
Table columns:
Name: Used to reference the variables later.
Type: The type of the value that is going to be stored. This type has an impact on the available widgets in the forms.
Multi-Valued: Check the box if we need to store multiple values of the same type on this field.
Default: The default value of the variable.
Availability tab
This screen controls when the workflow is displayed in the drop down list that allows to start a workflow on a document. The availability is

45

evaluated against multiple conditions. See the Filtering Options Reference Page for details about them.
Graph tab
The Graph tab is where you define how steps of your workflow are ordered, by dropping nodes and pulling transitions between them. If you let the
mouse over a node, you will be displayed an Edit button, that allows to edit the properties of the node, in a multi-tab pop-up. There are two kinds
of nodes: one that creates task, one that is automatic (the workflow engine goes over it and immediately follows one the output transitions).
On the left side menu of the graph tab, you will find the items below:
Resize graph editor: It happens that your graph cannot fit in the default allocated design area. Clicking on this button will make it larger.
A "Reduce size" button will be added in a future version of Nuxeo Studio.
Clear graph: Beware, this button will delete all your graph after a warning.
Node library: Lists different pre-configured nodes. You can drag'n drop them in the design area.
Node popup
Node General tab
Node form tab
Node Transitions Tab
Node Variables Tab
Node Escalation Rules Tab
Node General tab

46
Title: The title of the task, displayed in tasks lists in the user interface as well as directly on top of the task form, where user processes
the task. Supports i18n.
NodeId: The node id is useful when you want to configure queues of tasks. This is currently limited to advanced users.
Exclusive Node: If checked, transitions can be ordered and only the first transition for which conditions are true will be followed. If not
checked and if several transitions are true, then they will all be followed corresponding to a fork in the workflow. (available from 5.7.2)
Directive: The directive is displayed on top of the submission form when the user processes the tasks. Supports i18n.
Due date expression: This is where you express what should the due date be on the task that is created by this node. It is usually set
relatively to the current date (the time when the task is created), but it can also be expressed leveraging the date at which the workflow
was started.
Assignees: You can add static assignees here, either users or groups, one per input field (click on "Add" to add more than one). You
need to prefix users by "user:" like user:jack and groups by "group:" like group:validators.
Compute additional assignees: You can set a scripted expression (MVEL syntax) here so as to determine where to lookup the
assignees of the task. You have access to some useful variables in the context, like the NodeVariables and WorkflowVariables (se
e Variables Available in the Automation Context for more information). A frequent pattern is to set a node variable from the input chain of
the node and reference it here.

47

Create one task per assignee: If checked, there will be as many tasks created as there are assignees. This property is displayed only
for the multi-task node.
Allow task reassignment: If set to true, the Reassign user action will be displayed on the task resolution screen and assignee will be
able to reassign the task to someone else.
Grand permission to task assignee: Specifies the permission that will be assigned to each of the assignees on the bound document(s).
Mail notification: Specifies the mail template that is going to be used to generate the mail to be sent to the task assignee. If for some
reasons you want to send the email to some other users, you can do it from the input chain or output chain of the node, using the Send
E-Mail operation.
Task Document type: This is only for advanced users. It is useful to change the type of the task that is created, so as to be able to do
some tasks queues that display additional metadata coming directly from the document.
Input operation chain: The automation chain you specify here will be executed when the workflow engine enters the node. If the node is
of type Task, that means it's executed right before the task is created. The list of documents bound to the workflow instance will be the
input of the chain. If there is one document, it will still be a list, with one element only.
Output operation chain: The automation chain you specify here will be executed just before the workflow engine leaves the node. If the
node is of type Task, that means it's executed after the task created at this step is ended. The list of documents bound to the workflow
instance will be the input of the chain. If there is one document, it will still be a list, with one element only.
Allows incoming connections: Used only by the graph editor. Check this if you want to be able to draw loops back to this node.
Getting the first document of the document list in the automation chains ran from a workflow node
As we mentioned above, the workflow engine injects a document list in the automation chain, even when there is only one document.
You may have sometime a "Cannot find any valid path in operation chain" exception, because the operation you put in the chain
expects one document in input and the previous operation gives a list.
You can avoid this situation, when you know you have only one document, by fetching this document first. To do so, you can use:
Execution Context > Restore input document from a script

script: This[0]
Then, for the rest of the chain, you will have only one document in input transiting from one operation to the
other.
Node form tab
Here you can configure a form that will be displayed to the user for task processing. You can specify which fields have to filled (captured data will
be stored in workflow variables and node variables), and which buttons should be displayed.
Layout edition works as usual: you pickup the fields on the right. Here you have the choice between system properties, workflow variables and

48

node variables.
Buttons can be added easily. You need to specify:
Id: This value is important as it will be stored in NodeVariables"button" and can be used for instance to express conditions for
knowing which transition the workflow engine should use.
Label: The label of the button, supports i18n.
Filter: A filter to hide or display the button on some conditions. Works only starting from 5.7.1. In future release of Studio, there will be the
usual screen to express a filter.
Generate the condition for transition: This column, checked by default when you add a line, is a helper so that a transition
corresponding to the button is automatically declared, with the correct condition, like: NodeVariables"button"=='Reject'. See the
Transitions page for more information.
Node Transitions Tab
When designing the graph, you cannot pull freely arrows from the output of a node to the next one. You first need to declare the transition in this
tab. Once you did it, you will see an endpoint on the graph with the name of the transition, from which you will be able to pull the arrow.
When adding a transition, you need to specify:
Name: The name is only displayed in the graph, and used by the engine. You won't have to explicitly use this value later.
Condition: This is the condition the workflow engine evaluates so as to know where to go after an node is executed. You have access to
all the workflow context variables. If you don't set any condition, it will always be "true". The workflow engine supports having several
conditions evaluated to true, in that case, you will have a "fork" on your workflow path.
Chain: The chain will be executed when the workflow engine goes into this transition. In the context of this chain, you will have access to
the Node Variables of the node on which it is declared. For instance, you would like to log in the audit that it was rejected, validated, or
requested for update, you could add chains that use the Log Event In Audit operation and set a different value on each chain. The list of
documents bound to the workflow instance will be the input of each chain. If there is only one document, it will still be a list, with one
element.
Node Variables Tab
Node variables are useful for instance for capturing data from the user through the node form, and then do something with that data in the output
automation chain. You can edit those variables the same way you would edit a schema.
Name and Prefix: You don't have to modify this.
Add variable: Adds a new row on the variables table.
Delete variable: Deletes selected variable. You can select only one variable at a time.
Table columns:
Name: Used to reference the variables later.
Type: The type of the value that is going to be stored. This type has an impact on the available widgets in the forms.

49

Multi-Valued: Check the box if we need to store multiple values of the same type on this field.
Default: The default value of the variable.
Node Escalation Rules Tab
Escalation rules allow to execute an automation chain, depending on a condition. A scheduler checks every five minutes the condition and
executes the chain if the condition is evaluated to true. Please read the escalation service page for more information and examples of rules.
Escalation rules and node types
Please note that although this tab appears on every node, escalation rules only apply to nodes awaiting for a user action to be executed
(corresponding to the suspended life cycle state).
Multiple escalation rules can be added using the Add escalation rule button.
Id: The unique id of the escalation rule.
Condition: An MVEL expression to state when the escalation rule should be run.
Chain: The automation chain to be executed. You may create a new chain or edit an existing one using the Create and Edit buttons.
Multiple execution: The automation chain is only executed once by default. If you check this box, the automation chain will be run every
time Nuxeo evaluates the condition to true.
Automation
Before starting your own content automation chains, we advise you to take a look at the concepts and tutorial parts to understand what Nuxeo
Content Automation chains are and find sample use cases like:
A validation chain
A metadata inheritance chain
A purge type of chain
A task assignment chain
Subpages of this section are:
User Actions
Automation Chains
Event Handlers
Filtering Options Reference Page
User Actions
Concept
User actions are meant to execute a predefined action or list of actions (namely an operation chain) when clicking on a link or button. You can
read more about them in the theorical presentation and in the developers section.
Creating a User Action

50
In this section
Concept
Creating a User
Action
Editing a User Action
Action
Definition
Action
Enablement
Action
Execution
Feature ID : the unique id of the user action.

Label : the name that will be displayed on screen.
Category : defines where the action will be placed on screen. Note that certain categories only appear in specific screens; for
instance the "Document creation form" category will only be visible on document creation.
Editing a User Action

Action Definition
Order : set a higher value to move the action further to the right. Default actions order starts at 10.
Immediate : checking this box will cause the action to be executed without prior validation. It is usually preferable to leave it
unchecked.

51
Action Enablement
See the Filtering Options Reference Page.
Action Execution
Select an existing operation : the selected automation chain will be executed when the user clicks on the action defined in
the User Action definition section. The "Edit" button can be used in order to edit an existing automation chain, and the "Create" button
to create a new automation chain that will be associated to this user action.
Related pages in Studio documentation

User actions categories
User Actions
Related pages
How to Let Users Set Rights on Non Folderish Documents (Nuxeo Platform Developer Documentation)
How to Add a Button in the Web UI (Nuxeo Platform Developer Documentation)
Actions Overview (Nuxeo Platform Developer Documentation)
Action How-To Index (Nuxeo Platform Developer Documentation)
Actions (Links, Buttons, Icons, Tabs and More) (Nuxeo Platform Developer Documentation)
How to Make the New Button Appear on a Custom Folderish Document (Nuxeo Platform Developer Documentation)
Standard Action Types (Nuxeo Platform Developer Documentation)
Custom Action Types (Nuxeo Platform Developer Documentation)
Actions Display (Nuxeo Platform Developer Documentation)
How to Hide a Tab, a Link or a Button for a Group or a User (Nuxeo Platform Developer Documentation)
How to Create an Automation Chain (Nuxeo Platform Developer Documentation)
How to Add a New Action Category on a Document Tab (Nuxeo Platform Developer Documentation)
User actions categories

52

This page describes the list of all user actions categories available, with screenshots of where they are located on the screen.
CAP categories
These categories are available on all Nuxeo Platform modules.
Breadcrumbs
Technical name: BREADCRUMBS_ACTIONS

Available since Nuxeo Platform 5.9.2.
Clipboard
Technical name: CLIPBOARD_LIST
Contextual Tools
Technical name: DOCUMENT_UPPER_ACTION
Unless you specify an icon, the following icon will be used:

53
Document Creation Form
Technical name: CREATE_DOCUMENT_FORM

Document Edition Form
Technical name: EDIT_DOCUMENT_FORM


54

Document Header Actions
Technical name: DOCUMENT_HEADER_ACTIONS_LIST

Available since Nuxeo Platform 5.4.2. This action category requires to use an icon, otherwise it won't be displayed on the UI.
Document List Toolbar
Technical name: CURRENT_SELECTION_LIST
Document Summary Actions
Technical name: DOCUMENT_SUMMARY_CUSTOM_ACTIONS


55
Folder Toolbar
Technical name: SUBVIEW_UPPER_LIST
Header Links
Technical name: USER_SERVICES
Header Main Tabs

56

Technical name: MAIN_TABS
Available since Nuxeo Platform 5.8.
Header Search Actions
Technical name: SEARCH ACTIONS

Footer Links
Technical name: FOOTER


57

User Menu Actions
Technical name: USER_MENU_ACTIONS

Worklist
Technical name: DEFAULT_LIST
CAP advanced categories

The following categories have been made available in Studio for an advanced usage, they're not fully implemented in Studio even if they're
available starting from version 5.6.
These categories can be useful when defining custom actions, that will reference the widgets to display. This is useful when building
incremental layouts, like the default summary layout starting from 5.6: the action order and filter information are useful to
contribute/display/hide some widgets to the summary default layout.
These categories are not really useful when defining user actions, and the associated features can be broken when migrating from 5.6 to 5.8,
as the form around the summary layout has been removed for 5.8 to allow fine-grained form management on this page.
Summary Top Panel
Technical name: SUMMARY_PANEL_TOP

This user action category is not yet fully implemented in Studio (available since Nuxeo Platform 5.6).

58
Summary Left Panel
Technical name: SUMMARY_PANEL_LEFT

Summary Right Panel
Technical name: SUMMARY_PANEL_RIGHT


59
Summary Bottom Panel
Technical name: SUMMARY_PANEL_BOTTOM

DAM categories
DAM Asset view actions
Technical name: DAM_ASSET_VIEW_ACTIONS

Unless you specify an icon, the following icon will be used:

60
DAM Search results actions
Technical name: DAM_SEARCH_RESULTS_ACTIONS

DAM Current selection lists
Technical name: DAM_CURRENT_SELECTION_LIST


61

62
In this section
CAP categories
Breadcrumb
s
Clipboard
Contextual
Tools
Document
Creation
Form
Document
Edition
Form
Document
Header
Actions
Document
List Toolbar
Document
Summary
Actions
Folder
Toolbar
Header
Links
Header
Main Tabs
Header
Search
Actions
Footer Links
User Menu
Actions
Worklist
CAP advanced
categories
Summary
Top Panel
Summary
Left Panel
Summary
Right Panel
Summary
Bottom
Panel
DAM categories
DAM Asset
view actions
DAM
Search
results
actions
DAM
Current
selection
lists
Automation Chains
Concept
Concepts about Automation are introduced in the developer documentation. You should read them before starting using this feature.
The Studio Automation Chain editor allows you to build the chains of operations and fill the necessary operation parameters.

63
In this section
Concept
Chain Editor
Principle
Detailed
Screen
Review
Chain Parameters
Switch Editor
Chain Editor
Principle
To edit a chain, you just need to select a category on the first column, then an operation on the second one, then drop the operation on the
right, fill its parameters, and save. You can use the parameter helper on each parameter of the operations to find specific Automation EL
expressions.
Detailed Screen Review

Fetch > Context Document(s): This operation is always there when you create a chain. It is to remind the user that there is always
a document in input of an automation chain, injected by the Automation service, whether it is the current UI document, or the
document bound to the listener, or to the workflow. You can remove this operation from your chain, it won't change anything.
On each operation:
: Find here a first documentation of the operation: what are the expected input and output, and a small description of the
operation's role. From there you can access the online help (see next).
See Online Help: This link opens an online documentation page specific to the operation. You will most of the time find additional
examples of how to use a specific operation.
Edit: Switches the operation to edit mode for editing the values of your operation.
: Opens a popup with helpers for Automation EL syntax. See the page Use of MVEL in Automation Chains.
Read: Switches the operation to view mode.
Chain Parameters

64
On this screen you can add new parameters. This can be useful when you want to write re-usable chains.
Add parameter: Adds a placeholder for a new parameter, for which you need to specify the name (used for referencing it after that
in the chain, using ChainParameters['parameterName']).
Type: For now always set to string, this may change in the future.
Switch Editor
The Studio Automation Chain integrates a new editor called YAML editor which enables you to edit your chain in plain text. You can click on
the button Switch editor to activate this feature. You can switch back to the visual editor whenever you want.
For more information on the Studio Automation Chains, see all the operations available.

How-tos
How to Export Data Using Document Template and Automation
Tutorials
Implement the validation logic
Configure the ID generation using functions
Implement the News "publishing" process
Create a button that triggers the task assignment
Create a task assignment alert

65
Related pages in developer documentation

Automation Chain
Nuxeo Automation Commands
Drag and Drop Service for Content Capture (HTML5-Based)
How to Fetch a Document by Its ID or Path
Debugging Automation Chains
Variables Available in the Automation Context
How to Write Reusable Automation Chains
How to Quickly Generate a PDF Using Document Template
Bubbling Errors from the Core Layer in the Web UI
Client API Test suite (TCK)
Content Automation Concepts
Blob Upload for Batch Processing
How to Inherit a Metadata from a Parent Document
How to Fetch Documents with a Query on Date Parameters
How to Make a Simple Task Assignment to One or Many Users
Showing first 15 of 20 results
Event Handlers
Concept
To let you understand what event handlers are we can do a parallel with:
Triggers in a database,
Events on event-based programming patterns like in VBA, JavaScript, ...
You'll read more about event handlers in the theoretical presentation and on the developer
documentation.
Creating an Event Handler
In this section
Concept
Creating an Event Handler
Editing an Event Handler
Event Handler Definition
Event Handler Enablement
Event Handler Execution
Feature ID: The id of the document type. Will be used as the technical Id at generation.
Editing an Event Handler

66
Event Handler Definition

Events: Select a list of events for which the automation chain referenced later will be processed. If you don't find the event you are
looking for, you can add a new one using the registries.
Is Asynchroneous: The automation chain bound to the event will be processed asynchroneously, outside the transaction. More
details on the developer documentation.This is an advanced option, most of the time you won't check this option.
Event Handler Enablement

See the Filtering Options Reference Page.
Event Handler Execution

Selecting an existing operation: the selected automation chain will be executed for the events selected in the Event Handler
definition section

67

Related how-tos
No content found for label(s) howto-event-handlers.
Related tutorials
No content found for label(s) tuto-event-handlers.
Related pages in other documentation

How to Set a Default Date on a Field at Document Creation (Nuxeo Platform Developer Documentation)
How to Modify a Workflow Variable outside of Workflow Context (Nuxeo Platform Developer Documentation)
Events and Listeners (Nuxeo Platform Developer Documentation)
Common Events (Nuxeo Platform Developer Documentation)
Agenda Overview (Nuxeo Platform User Documentation)
Scheduling Periodic Events (Nuxeo Platform Developer Documentation)
How to Inherit a Metadata from a Parent Document (Nuxeo Platform Developer Documentation)
Filtering Options Reference Page

In various places of Nuxeo Studio (User Actions, Workflow, Event Handlers, ...) you'll find the same kind of screen where you can configure the
set of conditions for which something is displayed/ran/not filtered...
Depending on where the filtering option appears, the current document, or the document, may refer to:
the current document in the user interface (for User Actions),
the document for which the event listener happens (Event Handlers),
the document(s) bound to the workflow,

the document(s) that are in input of the operation (Filter list operation).
Below is a sample of such a screen. In this section, we review the list of all possible filtering options that you may
find in Studio.
Current user has one of the permissions: The logged in user has one of the selected permissions on the document.
Current document has one of the types: The document must implement one of the selected types for the filter to be evaluated to true.
Current document has facet: The document must implement the selected facet to be evaluated to true. Note that it would make sense
that this field is changed to a multi-select one.
Current document has life cycle: The document must be in one of the given lifecycle states. You can separate the lifecycle states with
a comma. This is particularly useful when you want to filter some buttons or workflows that have a consequence on the document
lifecycle state: they can work only if the document is in a specific state.

68

Document path starts with: The document path is under the given path. For instance in Nuxeo default structure, if you create a
workspace in the default domain, its path will start with "/default-domain/workspaces/". You can use it for doing some
configuration that would be specific to a part of your repository only.
How to get the path of a document
You can easily get the path of a document in Nuxeo DM by watching its URL.
For instance, if URL of the document is
"https://myserverhost/nuxeo/nxpath/default/default-domain/workspaces/billing-activity-reports/2011/April", then path of the
"April" folder is : "/default-domain/workspaces/billing-activity-reports/2011/April".
Current document is:
Any: The default option; has no effect on the global filter definition.
Regular document: Document is a "live document". That's the case of all the document created using the default interface
capabilities under the workspace, but the versions.
Impl: !doc.isImmutable() && !doc.isProxy()
Document link: Document is a "live proxy". Nuxeo Core allows to create two types of proxies. A "live proxy", aka "document link",
targets a "live document" (Regular document). A "version proxy" targets a version of a document.
Impl: !doc.isImmutable() && doc.isProxy()
Published document: Document is a version proxy, resulting of using the publishing feature.
impl: doc.isImmutable() && doc.isProxy()
Document proxy: Document is either a "Document link" or a "Published document".
Impl: doc.isProxy()
Document version: Document is a version (it is not a "live document").
Impl: doc.isVersion()
Immutable document: Document that cannot be changed. That's the case for a version, or a proxy that targets a version).
Impl: doc.isImmutable()
Mutable document: Document that can be changed. That's the case for a regular document or a live proxy.
Impl: !doc.isImmutable()
Current user is member of: Logged in user is member of one of the listed groups, separated with commas.
Current user is administrator: Current user is member of the "administrators" group.
Selection is not empty: Some documents are selected in the user interface, in the Content tab of the current folder for instance.
Custom EL expression: See the page Understand Expression and Scripting Languages Used in Nuxeo.
Note: You can see in javadoc that isImmutable() returns true if the document is a version or a proxy to a version, false otherwise
Roles & Permissions Section

Add a new Permission in the UI
This howto gives you the steps to add a new permission in the permissions list of Nuxeo applications. For instance, in the Access Rights tab in
Nuxeo DM.
You can then leverage this permission in the definition of new user actions to filter who should see the new button, link or icon or in automation
chains.
To create a new permission in Nuxeo:
1.
2.
3.
4.
Unfold the Roles and Permissions menu entry and click on Permissions.
Click on the New button.
On the window that pops up give your new permission an ID and click on the Next button.
Select where the permission should be displayed in the drop down menu and click on Add.
5. When you have chosen all the places where the permission should be displayed, click Save to save your modifications.
Don't forget to translate the permission label using an I18N translation file.

69

After you updated your Nuxeo application with Studio customizations, you must restart your server so the new permission is displayed.
Related Tutorials
Add predefined users and groups

Some features in Nuxeo products you will configure with Studio are restricted to very specific groups or users. To make sure that users are not
blocked by a missing group that the functional administrators would have forgotten to create, Studio enables you to configure users and groups
that will automatically be created by the system.
The "members" and "administrators" groups are typically groups created by the system and used for default permissions, for instance. This
feature is also very useful when you want to prepare a demo and be sure that you just need to deploy your plugin to have everything ready.
The steps to add a new user or a new group are basically the same.

70
To add a user or group:

1. In the left menu, click Roles and Permissions and Users & Groups.
If users and groups have already been created, the Users tab is displayed with already existing users listed. Jump
to step 3 to add new users.
If users and groups haven't been defined yet, a Create button is displayed. Continue to step 2 to create default
users and groups.
2. If no user and group have been defined, click on the Create button.
The "Administrator" user and the groups "members" and "administrators" are automatically created by the system. You can
now add new default users and groups.
3. In the Users or Groups tab, click the Add button.
4. In the window that pops up, type the new user's or group's name.
5. Edit the user's or group properties (see below for more details).
6. Click Save.
When you deploy your customizations, you will need to empty your database to enable the creation of these
users and groups. Until you do so, you will only have the users and groups of a default Nuxeo application.
If you choose a Creation Policy of "Always", then at each reload or restart the Studio-defined users and groups
will completely replace anything you may have changed from Nuxeo. Any updates, additions or removals done
from Nuxeo will be lost.
Users properties
Field
Description
Name
Login of the user. It can only hold alphanumeric characters.
Password
Type the password of the predefined user.
First name
Optionally type the first name of the user.
Last name
Optionally type the last name of the user.
Email
Optionally type an email address for the user, that will be used for
email alerts.

71

Company
Optionally fill in the user's company name.
Groups
Use the > and < arrows to add or remove the user from one of the
predefined groups.
Groups properties
Field
Description
Name
The name and ID of the group. It can only hold alphanumeric

characters.
Description
An optional describing what the group is used for.
Users
Use the > and < arrows to add or remove predefined users from the
group by default.
Vocabularies Section
Vocabulary Screen All the elements of the main Vocabulary feature screen are reviewed on this page.
Vocabulary Screen
All the elements of the main Vocabulary feature screen are reviewed on this page.
The page Adding a New Vocabulary does not exist.

In each of these three types of vocabulary you will find identical parameters like:
Creation Policy: The Creation Policy defines whether the values are created when the configuration is deployed on a Nuxeo
Platform instance. On Missing Columns means that it will be deployed only if it has never been deployed before on the instance. If it
is already here, it will let the existing values as is. Always means it will override the existing values with the ones that are on Studio.
It should be used with a lot of attention, as there is no way to revert, if data has been deleted at deployment. Never would be used so
as to disable the data loading logic temporarily, but would still declare the directory.
Delete and Delete all: Used to delete the values.
Import CSV: Opens a pop-up with inline documentation. You can either import data in Studio from a CSV file or references a file that
is never "parsed" from Studio (only by your Nuxeo Platform at deployment time). Choose the second option if you have many lines,
for a better user experience with your Studio project. The first line of the CSV file is the header that defines the vocabulary fields: id,
label, obsolete, ordering, and parent for hierarchical vocabularies. See examples simple-vocabulary.csv and hierarchical-vocabulary.
csv.
The Simple Vocabulary
This type enables you to create a simple one-level vocabulary. Make sure to fill in the fields Id and Label correctly, with no special characters
in the Id's name.
These fields are the same as those on the vocabularies management interface.
The Child Vocabulary

72
This type allows you to link vocabularies between them in order to have parent and child vocabularies.
You can't create a Child Vocabulary if you don't have a Parent Vocabulary already created to select. Once you Child Vocabulary is created,
you can add vocabulary entries and select a Parent for each of them
by clicking on Select button and choose a Parent in the drop down list.
The Hierarchical Vocabulary
This types has more parameters than the others, :

Add Root: Adds a root value. Adding a value means giving an id, a label and an obsolete field, the same values you would find in the
Nuxeo Platform vocabulary screen edition interface.
Add child: When already on a node, adds a child element. Note that you have to click on the "Set tree depth" button if you want to
add more children than the currently set limit.
Move up and Move down: Used to move the values (that are ordered).
Set tree depth: Allows to set more than two degrees of values on a hierarchical vocabulary. Select2 widgets are directly compatible
with any levels. If you want to have more than two levels with chain selects, you can read the Create a n-level select widget how-to.
Related pages in current documentation

Vocabulary Screen
Related pages in other documentation

Managing Vocabularies (Nuxeo Platform User Documentation)
Data Lists and Directories (Nuxeo Platform Developer Documentation)
How to Add a New Vocabulary (Nuxeo Platform Developer Documentation)
How to Translate a Vocabulary (Nuxeo Platform Developer Documentation)
How to Disable by Coverage and by Subjects Virtual Navigations (Nuxeo Platform Developer Documentation)
Advanced Settings
73
Administering your project

Automated renaming
Use Registries for Referencing Externally Defined Objects (Types, Operations, ...)
Test your Studio config with a new version of DM or CMF
Version Control
Naming Conventions
Automated validation
How to Enable Package Specific Features in Studio for DAM or DM?
Automated renaming
As you work on your Studio project, you may need to rename elements, that may be referenced by other features. A typical example would be if
you rename an automation chain. This chain can be used by user action, such as a button, or another chain.
In order to prevent inconsistencies and broken features, Nuxeo Studio automatically checks your project to find all the references to the element
and change the reference with the new name. A confirmation window indicates the result of the renaming on the whole project.
For instance, in the case of a renamed automation chain, Nuxeo Studio will automatically update the chain name in the "Select an existing
operation" drop down list of the User action that uses the chain.
However there are some cases where the renaming is not done by the system, for instance when the renamed chain is used in a function. In that
case, you are displayed a message indicating where the chain name was found but not updated. Copy the log displayed in order to be able to
check the places where the chain name was not automatically updated.

74
Use Registries for Referencing Externally Defined Objects (Types, Operations,

...)
If you click on Settings and Versioning > Registries in Studio, you will find a list of "registries" that you can complete with JSON
instructions.
The goal of this section of Studio is to be able to complete Nuxeo Studio drop down lists and elements of the interface with additional elements
that come from another Studio project or an Eclipse-based customization. For example, if you declare a document type in the registries (following
the inline example syntax), you will be able to declare new document types from that type, you will be able to use it in Structure Templates, etc...
You can also use registries to declare new operations so that they appear in the Operations browser.

75

Registries never impact what happens on the runtime when you deploy your plugins. They are only useful for configuring your Studio
project screens (what you see in drop down lists and menus) and your Studio project validation rules.
For that reason, you can for instance only complete the "id" of a schema without the property detail, and you'll be able to assign this
schema to a document type, but in that case you won't have the properties listed when editing some layouts on documents that hold
this schema. You'll need to give the complete JSON definition for this.
Test your Studio config with a new version of DM or CMF

Let's suppose you are currently using Nuxeo 5.4.1 with a configuration achieved in Studio, and the 5.4.2 RC has been announced on Nuxeo
website. RC means "Release candidate". It means it is very close to what will be release soon, but that feedback from community is accepted to
improve the quality of the release. If you want to try it, just follow those steps:
Make a backup of your config to be able to switch back easily later on : go to "versions" link and click on the "tag" button, on the right.
Give the name "config ok with 5.4.1" (for instance).
Switch your configuration to 5.4.2 by going to "Projects settings > Target Platform" and choose Nuxeo 5.4.2
Now startup your 5.4.2 DM instance, in the startup wizzard, at step 5 (when it asks you to create a connect account), click on the link that
says that you already have an account and fill in your connect id and password, then choose your project (you might have only one).
Restart the server (if it doesn't restart automatically)
Go to the admin center > update center and update your studio configuration
You are done !
If it was just a test, don't forget to "restore" your tag in Studio as it was before the tests by going to "Versionning" then selecting the tag "config ok
with 5.4.1" then clicking on the "revert" button.

You need to make sure that your Studio project has a correctly configured Target Platform: the target platform is the version of Nuxeo product for
which the configuration will be generated. It should match the version of the Nuxeo product you are using.
Updating the target platform of your project will have two main impacts:
You will probably have more features available than if you are on an older target, as Nuxeo Studio will be able to leverage all the new
configurability the new version of the Nuxeo product brought.
You will be 100% sure that what is generated by Studio is compliant with the version of the product you are running, as Studio is
responsible for this.
To change the target platform, for instance to Nuxeo DM 5.4.2, just follow the steps mentionned on the following screenshot.

When upgrading your target platform in Studio, Studio will take care of generating the corresponding code for your target platform. Usually, no
manual configuration changes are needed. This page lists a few exceptions.
Upgrading to 6.0
Some packaging changes have occurred for Nuxeo Platform 6.0. For instance some default features are now available as add-ons, some

76

features have been moved to the default packaging. Although Studio will migrate most resources, here are some steps to follow to make sure
you get the expected behavior.
Migrating Virtual Navigation Customization

Virtual navigation used to come with the DM package. It is now an independent add-on. To keep your custom virtual navigations you need to:
1. Check the Virtual navigation target package in Studio
2. Install the Virtual navigation add-on on your Nuxeo Platform.
MIgrating Faceted Search Customization

Faceted search used to come with the DM package. For Nuxeo Platform 6.0 it is an independent add-on and has been deprecated. From an
end user point of view, the search experience provided by faceted search is now available by default in the Search tab.
[Screen shot]
Migrating Your Faceted Searches to the New Search Tab
When you choose the target platform 6.0, the faceted search target package is selected by default: uncheck it. Your faceted searches will be
available in the Search tab as additional search filters.
In Studio your content views automatically gets a FACETED_SEARCH* flag. Uncheck it and check the Search flag.
Keeping Your Faceted Searches
If you want to keep your faceted search left tab in the Workspace main tab:
In Studio check the Faceted search target package in the Project settings.
The Faceted search flag is available and checked on your content views.
In your Nuxeo Platform instance, install the Faceted search add-on.
Migrating a DM Project Extending the Picture Document Type

Pictures were previously coming with the Document Management module, but are now available as part of the DAM add-on. When you
migrate your project to 6.0, you need to:
1. Select the DAM target package in the Studio project settings.
2. On your Nuxeo Platform instance, you need to install the DAM add-on.
Migrating a DAM Project

For Nuxeo Platform 6.0, the DAM package has been simplified: it now holds the documents types Picture, Audio and Video. All the specific
UI has been moved into the DAM compat add-on (see the page Nuxeo DAM Compat for details).
Migrating Your DAM Project
Migrating DAM Content Views to the Search Tab
When you select the target platform 6.0, you need to:
1. Select the DAM target package in Studio.
2. Install the DAM add-on on your Nuxeo Platform.
This will bring you the DAM document types in Studio. Your DAM content views will be available in the Search tab of the Nuxeo Platform; in
Studio they automatically have a DAM* flag. Uncheck it and check the Search content view flag.
Keeping DAM Content Views in a DAM Dedicated Tab
If you want to keep your content views available in a DAM dedicated main tab:
1. In Studio, select the target packages DAM and DAM compat.
The DAM flag is available and checked on content views.
2. Install the DAM and DAM compat add-ons on your Nuxeo Platform instance.
Upgrading to 5.8 or Higher

User Actions on Content View Actions of Ordered Folders
Since NXP-11845, the default content view presenting ordering actions only presents actions with category ORDERABLE_CURRENT_SELECTI
ON_LIST (labeled "Orderable Document List Toolbar" in Studio). It previously presented also actions available to non-orderable content

77

views, CURRENT_SELECTION_LIST (labeled "Document List Toolbar" in Studio).
When upgrading to 5.8 or higher, Studio User Actions using this category will need to be duplicated to use the "Orderable Document List
Toolbar" category so that actions are still available on the default content view orderable_document_content.
Upgrading to 5.5 or Higher

Branding Migration
Please check Migrating My Branding to 5.5 New Branding System.
In this section

78

Upgrading to 6.0
Migrating
Virtual
Navigation
Customizati
on
MIgrating
Faceted
Search
Customizati
on
Mig
rati
ng
You
r
Fac
ete
d
Sea
rch
es
to
the
Ne
w
Sea
rch
Tab
Kee
pin
g
You
r
Fac
ete
d
Sea
rch
es
Migrating a
DM Project
Extending
the Picture
Document
Type
Migrating a
DAM
Project
Mig
rati
ng
You
r
DA
M
Proj
ect
Migrating DAM Content Views to the Search Tab
Keeping DAM Content Views in a DAM Dedicated Tab
Upgrading to 5.8 or
Higher
User
Actions on
Content
View
Actions of
Ordered
Folders

79

Upgrading to 5.5 or
Higher
Branding
Migration
Version Control
Nuxeo Studio provides project versioning capabilities by using GIT as the versioning control system. Each Studio project is providing a Project
Versioning view where you can track your changes history, tag or revert commits. Thus versioning is provided at the project level - each project
has its own GIT repository so that it is isolated from other projects.
The versioning repository is initialized when you create the project and will contain an initial commit with all the initial files required by a Studio
project.
Here are the main functionalities provided by project versioning:

Manage changes history: you can view the last 100 commits you've made and you can tag or revert any commit you want.
Manage Tags (or project versions): you can manage project versions - create new tags, remove or rename existing tags.
Commit style: manual commit changes or use commit on build features.
Committing Changes
Working on a Studio project suppose creating, editing and removing objects or uploading and deleting resource files. Each time you do such an
operation, some files are modified in the directory corresponding to your project. If you want to be able to make a snapshot of your work so you
can revert to it later or release it, you need to commit your changes from time to time in the versioning repository. Your changes are not committe
d every time time you modify some resource in your project. You have to commit it explicitly or to use the automatic commit on build feature.
There are three commit styles available:
Automatic commit on build: this is the default commit style. If you have it enabled, then every time you do a project build any pending
change will first be committed into the versioning repository and then (if successful) the build is done and the jar downloaded. If you
prefer managing your commits by hand, then you change the commit style in the Project Settings page.
Manual commit: this mode allows you to commit the pending changes anytime you want by clicking on the commit icon
. There are
two commit buttons in Studio: one in the project tree toolbar located on top of the left menu and the other one in Project Versioning view
in Tags page.
Commit on save: this mode will commit changes done every time you click on the save button in a screen. If you choose this mode, you
will be able to indicate your commit message using a field located next to the save button.
Note that if a commit is done but no pending change exists, nothing will be done (i.e. empty commits are not created).
Also, each time you commit, you will be asked for a commit message. The message should be short and descriptive for your commit. For example
new Book document type added is a good commit message. When using the automatic commit on build an automatic message is proposed for
you (that you can overwrite with your own message if needed).
Changes History
In the Project Versioning > Changes view you can inspect your last 100 commits. The commit history list is ordered by date (the most recent on
top) and gives you minimal information about the commit - like commit date, author and commit message.
When you click on a commit, additional information about the commit are displayed below the list of commits. Here you can see the files that were
changed by the commit. You can also see the difference between two Studio objects (in diff format) if you click on the file that changed. Note that
the diff feature is available only for Studio objects and not for resource files.

80
The changed file are prepended by a bold character that marks the type of change made on the file. You can have the following change types:
M - modified - the object / file was modified
A - added - the object / file was added
R - removed - the object / file was removed
T - type changed - the file type changed
Managing Tags
Project Tags are read only snapshots (or versions) of the project. In the Project Versioning > Tags view you can:
1.
2.
3.
4.
5.
create new tags from a commit or from the current working version.
delete existing tags
rename (release) a tag.
commit pending changes
download tag JAR
Creating new tags

There are two ways to create a new tag:
1. From the Tags view by clicking on Tag button.
In that case the tag will be created from the working directory and will do an automatic commit if needed. (the tag will contain all recent
changes you've made and not yet committed)
2. From the Changes History view by clicking on a commit and then on the Tag button in the commit information panel.
In that case the tag will be created from the commit you selected. That means the tag will include all the modifications made until that
revision (the commit revision included). You can use this to make snapshots of known (or stable) states to be able to use them later.
When creating a tag you will be asked to enter a tag name and a tag description. As for the commit the tag description should be short and
meaningful. The tag name must be a short alphanumeric string with no spaces (you can use underscore, dot or dash characters). You are
encouraged to use version strings since tag names will be used as the maven artifact version for your project (see Maven Integration).
Example of good tag names: 1.0, 1.0.2, 1.0-beta, 20100624, 1.0-snapshot etc.
When a tag is created the project is build and the resulting JAR will be stored inside the TAG. This way you can download the JAR corresponding
to the tag by clicking the Download button. (the jar is never rebuild - it is build only once at tag creation)
Releasing tags
When you create a tag, test the tag JAR and find that this version is good enough to be put in production you can rename the TAG to have a
suitable name for a release. This operation is available by clicking on the Release button.
Let say for example that you created a tag named "1.0-rc1" and you decide that this version can be released as "1.0" version. In that case you
simply rename 1.0-rc1 as 1.0 using the Release button.
Reverting changes
Reverting changes means to replace your current working directory with the revision you want to revert from. A revision can be a tag or a commit.
So reverting can be done from both Tags and Changes views by clicking on the Revert button.
Be aware that a revert operation is not reversible. Any changes you've done between the reverted revision and your current working
version will be lost! It is recommended to first tag your working version before doing a revert. This way you can still restore later your
latest working version from the tag (by doing another revert).
Quick Summary

81

User saves: config is persisted server-side.
User commits with an optional comment: this works only if something has been changed (otherwise it says : nothing to
commit). Every commits are visibles in the commit history. It is possible to revert the state of the repository to a previous
commit. If the user does so, all the commits executed after the one to he is reverting will be lost, including work that was not
committed
User tags, with a tag name. The tag is displayed and can be reverted to the "trunk". Contrary to reverting to a previous commit,
reverting to a tag doesn't delete any history. It simply replaces the "trunk" configuration by the one that was tagged and
commits. (Tagging is visible in the commit history).
User releases snapshot, with a revision/minor/major flag and an optional (useless and that we should remove) suffix. It does a
version of the current trunk (and commits it). Contrary to tags, version are available from the Update Center, to be installed.
User releases a tag. Does the same as the version, but instead of putting the "trunk" in the release, it puts the tag. It would be
the same as reverting the tag then releasing the snapshot.
The Tags view enables to see all the tags and releases that were done, the changes view enables to see the commits history. Clicking
on one line enables to see all the files/features that were modified on a commit, clicking again enables to see the text diff.
Naming Conventions
This page proposes naming conventions for Studio customization items in order to facilitate usage,
maintenance and support. Although not mandatory, we strongly encourage to follow these
conventions, especially if you are a beginner in Studio. For each rule, a example is provided.
General rules
In general, there are items that will be easily seen by end users (document types for instance) and
under the hood features (automation chains for instance). For very exposed items, words should be
separated by underscore and begin with a capital letter (Contract_Library) and for others we will
prefer compacity: capital letter for every words but no underscore between them (SendToValidation fo
r instance).
As Studio projects can be mixed together or involve many functionalities (ex: contract management,
holiday requests...), it is important that items coming from one project or another can be identified
easily. The solution is to prefix every item. For example every item that is about
contract_management will start with CM- and HR- will apply for holiday request: CM-SendToValidatio
n. Prefixing does not apply to document types, and life cycles (Content Model section in Studio). This
is particularly mandatory when you do a plugin that will become an Application Template that can be
imported into other projects.
On this page
General rules
Content Model
Search and Listings
Automation
Automation Chain
Workflow
User Actions
Event Handlers
Miscellaneous
Content Model
Document types - Document types are probably the main items and should be created first. Naming should start with a capital letter, and
if it needs several words, these one should be separated with an underscore: Contract_Library.
Schemas - Explicit name (the same as the document type if linked to one) with underscore separating words but all lower case: contract_l
ibrary. You should use a prefix that is either the name or a shorter prefix like dc for dublin_core.
Life Cycle - Upper case for each first letter, underscore to separate them. Most of the time a life cycle is only for one document type, in
that case, the life cycle should name after the doc type with Lifecycle at the end: Contract_Lifecycle.
Life Cycle State - all lower case, words separated by underscore. Transitional states and stable states should be distinguished, for
instance a document that requires to be corrected and then validated will have the states: correction > validation > validated
Search and Listings

Named like under the hood items: explicit name, no word separation but capital first letter and the project prefix. For example, a content view that
shows all contracts in validation state would be: CM-ContractsInValidation.
Automation
Automation Chain
Automation chain names should contain a verb to describe what they do.

82

Some automation chains have a UI context, which enables to use UI operations like Add Info Message. These chains should be prefixed with UI.
A example of a chain that send a contract to validation from a user action could be: CM-UI-SendToValidation.
Other chains that do not have UI context and are mainly called by event handler or other chains should be prefixed with Sub. Example: CM-Sub-U
pdateAcl.
Items in automation are clearly under the hood items so it would be explicitly named: no word separation but capital first letter and the project
prefix. We also added a few rules to standardized the description.
Workflow
When automation chains are steps of a workflow, a good idea is to prefix them with a number so that they are displayed in the same order they
will be triggered. Example with a workflow on the life cycle [Draft <--> Validation --> Validated ]:
CM-01-UI-SendToValidation
CM-02-UI-SendToValidated
CM-03-UI-SendBackToDraft
Note that CM-02-UI-SendToValidated and CM-02-UI-SendBackToDraft have the same number as they can be triggered from the same state
(Validation).
User Actions
User actions should be named after the automation chain they trigger, adding UA- (User Action) after the project prefix (possibly adding the user
action category at the end as there can be several user action launching the automation chains).
Example of a user action to send a contract to validation: CM-UA-SendToValidation
Event Handlers
Same rule as user actions but with EH instead of UA: CM-EH-UpdateAclOnContractCreation
Miscellaneous
Every other item should follow the rules given at the top of this page.
Vocabularies should have a name shorter than 13 characters, otherwise, it may be too long for some databases
Most of the time, groups of users come from the AD or LDAP, but when created in Studio, it should reflect the role, in full lower case, with a "s" at
the end: members, redactors, purchasers...
Automated validation
Nuxeo Studio will perform some consistency check as soon as you configure some features, to be sure that, for instance, if it references another
one, that other one has already been created or referenced in the registries. This page aims at referencing all the checks that are performed. You
can add a comment at the end of this page for suggesting some additional checks.
Feature
Tab
Branding
Errors when...
Warnings when...
Comments
logo image does not exist

login background image
does not exist
Content
Model/Documents
Definition
parent type does not exist
Definition
one of selected extra

schemas does not exist
Definition
selected life cycle does

not exist
Definition
one of selected container

types does not exist
Definition
one of selected sub types

does not exist
Definition
selected icon does not

exist

83
Search And
Listings/ContentViews
Search And
Listings/Virtual
Navigations
Search And
Listings/Advanced
Search
Automation/Event
Handlers
Definition
selected large icon does

not exist
Creation layout
creation layout has errors
creation layout has

warnings
see below for a more

details on layout
validation
View layout
view layout has errors
view layout has warnings

details on layout
validation
Edit layout
edit layout has errors
edit layout has warnings

details on layout
validation
Header layout
header layout has errors
header layout has

warnings

details on layout
validation
Summmary layout
summary layout has

errors
summary layout has

warnings

details on layout
validation
Query And Form
search layout has errors
search layout has

warnings

details on layout
validation
Results
result columns layout has

errors

warnings

details on layout
validation
Results
additional result columns

layout has errors

layout has warnings

details on layout
validation
Virtual navigation
selected icon does not

exist
Virtual navigation
one of the referenced

directories does not exist
Virtual navigation
property to query on does

not exist
Results

errors

warnings

details on layout
validation
Form
search layout has errors
search layout has

warnings

details on layout
validation
Results

errors

warnings

details on layout
validation
Results

layout has errors

layout has warnings

details on layout
validation
no selected operation
selected operation does

not exist
one of selected document
types for event handler
enablement does not
exist
Automation/User Actions
no selected operation

84

selected operation does
not exist
one of selected
permissions for action
enablement does not
exist
one of selected document
types for action
enablement does not
exist
selected action category
does not exist
selected action icon does
not exist
Automation/Automation
Chains
one or more operations

referenced by the chain is
undefined
A Context.RunOperation
operation reference an
undefined operation
chain
the validation is done only

on static field values
(expressions are ignored)
A
Context.RunDocumentOp
eration operation
reference an undefined
operation chain

A Workflow.CreateTask
undefined operation
chain

A
Document.GetPrincipalE
mails operation reference
an undefined permission

A
Document.GetUsersAnd
Groups operation
reference an undefined
permission

A Document.SetLifeCycle
undefined life cycle
transition

A Document.Create
undefined document type

A Document.GetParent
undefined document type

A
Seam.CreateDocumentF
orm operation reference
an undefined document
type

A Document.Update
operation reference
undefined schema fields


85

Any parameter named
'xpath' which is not an
expression is validated to
reference an existing
schema field
Any expression
containing Document['x
path'] is validated to
point to an existing
schema field
Roles and
Permissions/Users &
Groups
The creation policy is set

to 'always'
Roles and
Permissions/Permissions
one of the selected

document types does not
exist
Advanced Settings/Web
Services Filtering
one of the referenced

operation chains does not
exist
Layouts validation is detailed here:

Item
Errors when...
Widget
widget type is not filled
Warnings when...
Comments
widget type does not exist

schema bound to the widget is
missing or does not exist
schema prefix bound to the
widget is missing or does not
exist
field bound to the widget is
missing or does not exist
field bound to the widget has a
type that does not match the
current field type
field bound to the widget is
multivalued (or not) and that
does not match the current field
definition
widget type does not match the
accepted types for bound field
How to Enable Package Specific Features in Studio for DAM or DM?

Nuxeo Studio enables specific features for the packages you want to deploy on top of a Nuxeo Platform server. Studio will show those features
only if they are selected in the project settings so that you do not try to customize a feature that is not available on your server because you did
not deployed the right module.
How to Choose a Package in My Project Settings?

To choose a package in Studio, you should go to Settings and Versioning > Project settings > Target Packages.

86
This is where you should select the modules that you have deployed or plan to deploy on your Nuxeo Platform server. The modules can be
chosen during the installation wizard as stated in the following page: Setup - Nuxeo Installation.
What Packages Are Available for My Target Platform?

DM is available from Nuxeo Platform 5.6 and above.
DAM is available from Nuxeo Platform 5.7.1 and above.
Selecting DM or not for a Nuxeo Platform 5.6 will not change anything as the "Target Packages" tag was introduced after the 5.6
release and feature were already here even if only available for DM module.
Tutorials
Welcome on the tutorials sections of Nuxeo Studio.
The goal of this section is to provide ready to use examples. They can be followed step by step to learn how to use Studio on practical use cases.
The section also aims at providing solutions to commonly encountered situations.
In complete project subsection, how-tos have been regrouped around different example subjects such as a "technical documentation project".
Each step of the project answers to one specific question and should be understandable independently but it's recommended to follow each
project step-by-step to get the full logic.
The configuration changes you will make in Nuxeo Studio require Development Mode to be enabled. Development Mode can be enabled on your
Nuxeo server by going to Admin Center > Update Center > Nuxeo Studio and clicking the Development mode Enable button.
Some how-tos do not fit into one example project and can be found under the how-tos subsection.

You can update your Nuxeo Platform instance with your Studio configuration by going to the Admin Center > Update Center, on the Studio tab.
1. Make sure your Nuxeo Platform instance is registered.
2. Go to the Admin Center > Update Center > Studio tab.
3. Activate the Dev mode by clicking on the dedicated button.
It says you need to restart but this is actually not mandatory.
4. Click on the Update button.
5. Your Studio project configuration is automatically downloaded and (re)deployed on your Nuxeo Platform.
6. You can do it as many time as you do modifications in Studio. We actually recommend you to be very iterative, and not to let to many
changes go before updating your Nuxeo Platform with the newest Studio project configuration.

87

The Dev mode, as its name stands, is for development only. You should always deploy a released version of your project on a
production instance.
Related howtos:
Installing the Studio JAR Manually

In some situations, your Nuxeo Platform doesn't have access to internet. For deplying your Studio customisation, you need to install the jar in the
correct place on the Nuxeo Platform folder layout and restart your server. See details below.
Manual deployment instructions

1. Click on the Download link, just under the project's name on the left. (This will download the latest "trunk" configuration.
For a specific release, you should go to Settings & Versioning > Versioning, Select the version you want and click on
Download)
2. On the "Build and download project" window that pops up, type a commit message and click OK.
3. Accept to download the jar.
4. Copy it to the plugins folder of your Nuxeo Platform instance: $NUXEO_HOME/nxserver/plugins
5. Restart your server.
Related howtos

88
Referencing an Externally Defined Type

Some of the features of Studio rely on displaying a list of existing document types. For instance, that is the case when:
you configure a user action filter,
you use the content-template feature (you choose the type of node you add),
you configure the containment rules in the types definition.
That list of available document types is made from some pre-declared built-in types (Workspace, Folder, File, ...) and the ones created in Studio.
It happens that you don't find in that list the type you are looking for, mainly because:
We forgot to add some built-in types (at the time this page is created it is the case of Forum, Website, MailFolder, ...);
You have deployed on your application some packages that contributes new document types, externally from Studio.
Fortunately we added a way to extend the list of available types, using the "Registries".
What you need to do to declare a missing document type is insert a JSON declaration (written by yourself) in the Registries, that will provide the
following information on the document type:
parent,
schemas,
facets,
subtypes,
actions.
Note that the information given in the JSON declaration are used only by Studio, to complete its user interface: it has no influence at all
on the package/plugin generated by Studio or, as a consequence, on the behavior of your application. As a direct corollary, it is not
mandatory to give the exhaustive information on actions, schemas, facets, subtypes, ... Only those required by what you need in the
Studio interface.
Below are step-by-step instructions.
To declare a missing document type in Studio:
Here, we want to add the "Forum" in the built-in types of the content-template feature, and in the container list.
1.
2.
3.
4.
5.
Click on Settings & Versioning, at the bottom of the left column by default.
Click on Registries to unfold the Registries menu.
Click on Document Types to add a missing document type.
Copy-paste the example provided in Studio.
Change the ID "MyFile" by "Forum" and edit the information so you get this:

89
5.
{
doctypes: {
Forum: {
parent: "Document",
schemas: ["dummy_schema"],
facets: []
subtypes: [],
actions: []
}
}
}
6. Click on the Save button.

The immediate effect will be to add "Forum" in all the lists, which might be enough for our use case.
If you want to use the type registry to inherit from an external type, you will have to give the exact schemas and the exact facets as they
are inherited.
If you want to edit some layouts (forms) on properties declared in existing externally defined schemas, you will have to contribute
schemas in registries.
Related topics
Referencing an Externally Defined Operation

Nuxeo framework enables to implement custom operations, meaning operations different from the ones you can find in the Studio Operation
browser. When implementing your own operation, you can entirely decide what the operation does, what are its parameters, its input...
We provide explanations on how to implement a custom operation. Pre-requisites are basic knowledge of Java and Nuxeo API.
Basically, to enable a custom in your Studio project, you need to:
1. implement an operation.
2. Import its definition in Studio to be able to use it in the Content Automation Chain editor.
An operation definition can be serialized in JSON and uploaded in this format in Studio. As a consequence, the new operation will appear
aside built-in operations, in the operation browser in a location that depends on the Operation category you defined.

90
To import the operation definition:

1. Make sure you have an custom operation implemented and deployed on the Nuxeo instance where you also deployed your Studio plugin.
2. Go to Advanced settings > Registries > Automation Operations
3. Pay attention to the given sample definition, copy-paste it and adapt to your custom operation (regarding operation ID, parameters type
and value, accepted input and output, ...).
You can add multiple operation definitions.
You can get the full JSON definition of your operation on the operation documentation, on your deployment. Go to the following
URL: http://localhost:8080/nuxeo/site/automation/doc . The served page builds dynamically the operations
documentation. You will find your operation(s) there. Once on the documentation of the operation, in the "LINKS" section, click
on the JSON definition link. Note that this link is not available on Nuxeo DM 5.3.2 and previous versions.
4. Once the JSON is ok, save and you are done!
You should see the operation in its category.
Putting your logic inside operations is always better than directly in SEAM components or custom listeners because:
It forces you to think a bit generic and re-usable,
You produce easily configurable and maintainable code.
Related howtos
How-tos
The Nuxeo Platform can be customized greatly, either by modifying existing interface and features or by adding new ones. This page focuses on
giving an entry on how to customize any existing area of the Document Management module of the Platform.
The logo and graphical appearance
File creation screen
Metadata view of a document on the summary screen
Document edit screen
Summary tab
Filtering tabs displayed on a document type
Advanced search screen

91

Default columns of a folder, a workspace or a custom container
A new drop down list, like coverage or subjects
Configure new virtual navigation axis (on the left)
Look (logo, colors, fonts, etc)
See the How to Brand Your Application page for a complete how-to.
Document creation screen
See the Define a Document Type page for a complete how-to.

Also, if you want to override the type definition of some built-in document types, pay attention to the How to Override Existing Document Types ho
w-to.

92
Metadata view of a document on the Summary screen

w-to.
Document edit screen

93

w-to.
Summary tab
See the How to Define a Document Type page for a complete how-to.
The "view layout" widget displays the metadata in view mode configured in the view layout tab.
Filtering tabs displayed on a document type

94

Choosing what tabs should be displayed or not is done on a per document type basis.
The different tab customization how-tos explain how to disable or add tabs. If you want to do this on some built-in document types, you have to
redeclare them in Nuxeo Studio, paying attention to the How to Override Existing Document Types how-to.
Advanced search form
You'll be able to configure the form, the query, the fields that can be additionally chosen and the default result table. The search screen is actually

95

a content view, so you will be interested in reading the How to Define a New Content View page (although you have to configure it on the "Search
and Listings>Advanced search").
Default columns of a folder, a workspace or a custom container
You'll be able to configure the query that is done to display the content, the title of the columns, the default sort criteria, the data that is displayed,
the way it is displayed... This can be done for each container type, for the corresponding trash, and you can also add such a "content table" as a
new tab on any document type, with filtering options. More information on the how to. See also the "news" tutorial that shows how to create a new
container (news) with a completely custom content view.
A new drop down list, like coverage or subjects

96
The drop down lists are "vocabulary widgets" that display a vocabulary list for the purpose of selection. Lists can be on one or several levels, and
can accept a single value or several values. The Coverage list for instance is a 2 level list that accepts only one selected value.
You need to create a vocabulary, then, on your document type definition, in the layout tabs (edit, create, view), you can use a "vocabulary widget".
If you want to add a new drop-down list for a built-in types, you should override the definition of that built-in type.
Also, if you just want to change the values of existing "coverage" and "subjects" lists, you don't need to use Studio, you can do this directly with
the Administrator user in the user interface of the DM, DAM or CMF.
Configure new virtual navigation axis (on the left)

97
You can add new axis. See the following how to. You will probably have also to create a new vocabulary. A vocabulary is a list of
optionally hierarchical values that can be used in virtual navigation, but also on select boxes... See also how to create new vocabularies t
hat can be used with Virtual Navigation.
You can also disable existing By Coverage and By Subjects axis

A mail template defines the content of an email that is sent to users under predefined circumstances. A mail template is usually composed of text
and variables. Typically, mail templates are used to define the content of email alerts in Nuxeo DM.
This page explains how to create a new mail template. You can see a use case of mail template in the One step validation flow based on lifecycle
only.
To create a new mail template:
1. Go to Templates -> Mail Templates.
2. Click on the New button to create a new mail template.
3. Give the mail template a ID and click Next.

98
4. In the text area, type the content of the mail. The content is usually composed of text and variables.
5. When you're done, click Save.

Your mail template is saved and can be used in automation chains.
Related howtos
Available variables in email templates

For a broader look about variables available in different contexts, have a look at the Underst
and Expression and Scripting Languages Used in Nuxeo page.
In your email templates, you have access to different variables depending if you are in an automation
chain or in a workflow notification context. This page references them.
In this section
Automation chain's "Notification > Send Email" operation context
Workflow task notification context
Automation chain's "Notification > Send Email" operation context

Variables that can be used to set up an email in an automation chain.
${Document} - the context document. This is the document on which some action was done and the send mail operation was triggered.
See Use of MVEL in Automation chains (document wrapper) for details.
${docUrl} - the document URL.
${viewId} - the view of the document which will be displayed by the document URL.

99

${subject} - the mail subject.
${to} - the mail recipients.
${from} - the mail sender.
${CurrentDate} - the current date. See Use of MVEL in Automation chains (date wrapper) for details.
${CurrentUser} - the current user.
${CurrentUser} is not correctly working for now in FTL templates.
${Fn}- a collection of useful functions. See Use of MVEL in Automation chains (fn object) for details.
${Env} - a hashmap containing Nuxeo environment variables. Example: Env["org.nuxeo.ecm.product.name"].
Workflow task notification context

Variables that can be used when a notification is set up from a workflow node's configuration.
${recipients} - email recipients. Provided as a usernames list. Example: ${recipients[0]}.
${userUrl} - URL to access the profile of the user running the task. Note that this might not be the current user. See the workflow
engine FAQ for details.
${docMainFileUrl} - URL of the document's main file (assuming the document contains one).
${docState} - document's current life cycle state.
${documentLifeCycle} - document's current life cycle state.
${docTitle} - document title.
${docUrl} - permanent link to the document.
${docId} - document id.
${taskInstance} - task instance id.
${workflowStartTime} - workflow's start time, sent as a java.util.GregorianCalendar object.
${workflowInitiator} - workflow's initiator username.
${WorkflowVariables} - hashmap containing the workflow variables. Example: ${WorkflowVariables['myVariableName']}.
${NodeVariables} - hashmap containing the node variables. Example: ${NodeVariables['myVariableName']}.
${workflowDocuments} - hashmap containing the workflow documents. Example: ${WorkflowDocuments[0].dublincore.titl
e}.
${nodeId} - node's id.
${button} - button id that was clicked for processing the task, if the current node is a task node.
${nodeState} - node's state.
${state} - workflow's state.
${nodeStartTime} - time when the node was started, useful for example when computing a due date (Due date expression: nodeSta
rtTime.days(8)). Sent as a java.util.GregorianCalendar object.
${nodeEndTime} - time when the node was ended. Sent as a java.util.GregorianCalendar object.
${nodeLastActor} - Last actor on the node. Useful for instance to know who closed a task when the task was assigned to a group.

Default templates for mail notifications can be overridden. Just follow those steps:
1. Create a new Templates > Mail feature in Studio. Choose ID among the ones that are used in the default product, like
"subscriptionsUpdated" for instance (see the list of all alert templates).
2. Fill in the content of the email that you want to be sent.

100
If you want to copy from the default content of the template, you can have a look at it from here.
3. Save.
Default notifications are created in the Application template that is automatically imported when you create a Studio project (since end
of December 2011). If you didn't import this template, you can import it from the Application Template Library in Studio, it is called
"Nuxeo DM Default Configuration".
Related pages
Recommended Configurations
How to setup a test SMTP server
Maven Integration
The project versions (i.e. tags - see Version Control) generated by Studio are automatically exposed as Maven artifacts in an online Maven
repository. This can be useful for developers who want to include their Studio project in their build process.
All projects exposed through Maven are protected so that only contributors on the project are able to access the project in the Studio Maven
repository.

101
This is how to setup the Maven client to be able to access Studio Maven artifacts:
1. First you need to tag your project from Studio Client - see Version Control.
This will generate a version of your project that can be accessed by Maven.
2. Then you need to configure your Maven client to use authentication when accessing the Studio Maven repository. For this,
edit (or create if it does not exist) the ~/.m2/settings.xml file and add the following entry under the settings tag:
<servers>
....
<server>
<id>nuxeo-studio</id>
<username>your_studio_username</username>
<password>your_studio_password</password>
</server>
...
</servers>
3. Then in the POM (or a parent POM) where you need to add the dependency to the Studio project you should declare the
Studio Maven repository like this:
<repositories>
...
<repository>
<id>nuxeo-studio</id>
<url>https://connect.nuxeo.com/nuxeo/site/studio/maven</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
...
</repositories>
You notice we used the same server ID than in the settings.xml file. The repository is located under the
same root as Studio client (but using the Maven relative path).
4. Now you need to declare the dependency in your POM to point to the desired version of your Studio project.
The project artifact key will be computed as follow: maven_group:project_id:version.
The maven_group defaults to nuxeo-studiobut can be changed from the Project Settings view in Studio
Client. It is recommended to use the pattern com.mycompany for commercial (closed source) projects and org.myc
ompany for Open Source projects.
The project_idis the ID of you project and is unique between all projects in Studio - you can get you project ID
from the Project Settings view in Studio Client - look after Project Id property.
The versionis the tag name of your project tag. Note that only tags and latest development code are accessible
through Maven.
Let say you created a project tag named 1.0 and your project ID is myproject and you are using the default nuxeostudio group. In that case your Maven dependency will be:
<dependency>
<groupId>nuxeo-studio</groupId>
<artifactId>myproject</artifactId>
<version>1.0</version>
</dependency>

102

The list of available versions for a given project is visible at:
https://connect.nuxeo.com/nuxeo/site/studio/projects/{PROJECT_ID}
or
https://connect.nuxeo.com/nuxeo/site/studio/maven/{MAVEN_GROUP}/{PROJECT_I
D}/
with MAVEN_GROUP=nuxeo-studio by default.
The list of available resources for a given project and tag (or version) is visible at the given URL:
https://connect.nuxeo.com/nuxeo/site/studio/maven/{MAVEN_GROUP}/{PROJECT_I
D}/{VERSION}/
with MAVEN_GROUP=nuxeo-studio by default and VERSION=0.0.0-SNAPSHOT for the
current development code.
Application Templates
Nuxeo Studio includes an Application Templates library composed of other Studio projects or samples that you can use as a basis for your own
project. This enables you to import new document types, lifecycles, workflows, features in your project as a template that you can edit to adapt it
to your project.
And to make Nuxeo Studio discovery easier, we automatically import the "Default configuration" template that correspond to your target
application when a Studio project is created. You can then see how the configuration is done and start your project from it.
In the Application Templates library, you will find very complex ready-to-use templates for complete function use cases (such as "Human
resources - Vacation request workflow") or some unitary cases, such as "Custom Doc ID generation" or "Nuxeo School Sending Emails".
You can start with the how to page about importing a template and then start importing some templates and refer to the following documentation
for each of them.
Default configuration templates

To make Studio discovery easier, in each newly created project we automatically import the "Default configuration" template that
correspond to your target application (DM, CMF, etc), so that you just have to start modifying what has been imported. These default
configuration templates implement some core elements you see in the Nuxeo application you downloaded.
If you want to customize those elements, the "Default configuration" templates are what you need!
The Application templates below are available to help you discover how the default configuration of Nuxeo applications is done.
Nuxeo DM default configuration template

The Nuxeo DM default configuration template implements the elements below:
Document types: File, Folder, Workspace, Domain,
Automated structure: (one domain = workspaces + sections + templates),
Default advanced search screen,
Default content listing columns.
Nuxeo CMF configuration template

The Nuxeo CMF configuration template implements the elements below:
Documents types: new default case and case item,
Vocabularies used by default case and case item.
Templates reference
You'll find here a page per application template, so as to provide you main information to discover the Application Templates in the best

103

conditions.
The available application template descriptions are:
Configuration Management
Contract management
Custom Doc ID Generation
Human resources - Vacation request workflow
Configuration Management
This documentation describes how Nuxeo can be used to set up a Configuration Management System.
Configuration management process creates challenges an application like Nuxeo can help to handle. As stated by the CMMI approach, "The
purpose of Configuration Management (CM) is to establish and maintain the integrity of work products using configuration identification,
configuration control, configuration status accounting, and configuration audits."
The Studio application template called Configuration_management_nux focuses on configuration identification and control trough specific
document types. Although this first template is not a complete configuration management application, it shows how Nuxeo can be used to handle
concepts like Configuration, Configuration items, and Baselines from creation, manipulation, to audit and verification.
The best way to follow this documentation is to import the application template in your Studio project, find here the documentation on how to use
application templates in a Studio project.
Being already familiar to Studio main aspects is recommended to understand this documentation, if not the case, you can start by our how to get
started guide.
A resource section at the end links all the resources used in this documentation.
Configuration management
A documentation tree supposed to be managed by the application is called a Configuration. Every file and folder created in it will be under
configuration management control.
For that, they have specific metadata inherited from the schema "configuration_management". For example, every file is linked to its parent
configuration and has a unique reference given on creation. If a document is copied into another configuration, the parent configuration is
updated, but the reference stays the same. It enables to watch a file throughout its configurations and evolutions (a specific tab is added on the
type File to display every location and configuration of the file copies).
All references and links between a configuration item and its parent configuration are managed through Automation Chains launched by Event
Handlers.
This template has been created to be used with usual doc types like File, in that purpose, the default document type has
been overridden. The challenge is that the plugin should stay transparent if you work with a File that is not under configuration
management control, the consequent condition is that Automation Chains launched by Event Handler must be able to differentiate the
files that are under CM control and the file that are not. The solution was to use the operation Execution Flow > Run Document Chain
with a condition in the parameter.
For example "CM-OnConfDocumentCreation" is launched at every file and folder creation and tests that the parent is under
configuration control before launching the actual automation chain, the syntax for conditional operation is:
@{Document.parent["managed_in_configuration"]=='true'?'CM-OnConfDocumentCreationIfConfParent':'CM-Void'}
The versioning system of Nuxeo is used to manage and know which files are validated or working versions. By choice, every minor version is
know as a reviewing and working version whereas major version are used only for validated version of the document. Please note that no specific
validation process such as a RACI has been configured for this first version.
So working under configuration management with Nuxeo consists as creating a Configuration (one per project or product typically). Then creates
the project tree and the project files. These files can be new files or can be copied (forked) from other projects. The File minor and major versions
are used to know which are validated or not, and the Configuration tab on Files gives a look to all major version and copies of this file throughout
the system.
Baseline
One very important aspect of configuration management is being able to know in which state was the documentation set at key moments of the
project, for example at client releases. These snapshots of the configuration state are called Baselines : a baseline reflects the state of the
configuration at a specific moment, it's a view of latest validated versions of all documents of the configuration.
To manage baselines, a doc type Baseline can be created into a Baseline_library. By default, a Baseline is in pending state as the baseline can
be prepared and then generated only when needed. A user action is provided on the Baseline Folder Toolbar to actually baseline the
configuration.
It launches the baselineConfiguration automation chain which role is to set to the baseline to generated state and actually generate the baseline
using a specific automation operation.

104

The specific operation is called "Baseline Configuration" and has been implemented with Nuxeo IDE (please see the resources for the source
code of the operation).
The operation calls a recursive method that will copy the configuration tree into the baseline and will also create a virtual copy of the latest
validated version of the document.
This virtual copy is called a proxy in Nuxeo and it's a read only copy the latest major version of the document. (A proxy is very much like a
symbolic link on a Unix-like OS: a proxy points to a document and will look like a document from the user point of view) . Proxies are used to be
able to see the same document from several places without to duplicate any data which exactly what is need when generating a baseline. We do
not want to duplicate the document, just create a link towards it.
more info on proxies here: Repository Concepts
In the end, when a baseline is generated, it shows the same tree than the parent configuration, but each folder only contain proxies of latest
validated version of the Files.
Generate Baseline Automation Operation.

If you take a look at the baseline operation source code, you will see that it gets the configuration parent folder, the baseline parent folder and call
a recursive method (baselineFolder) with those 2 folders as parameters. BaselineFolder gets the children of the configuration node :
if they are folderish it copies them into the baseline node and recall itself on each new child node,
if the node is not folderish, it looks for the latest major version and create a proxy of the document into the baseline node.
Resources
The configuration management template consists in a studio project plus a specific automation operation.
They need to be both deployed on a server to work. To only deploy and test, you can use the marketplace package that regroups everything in
one package. If you prefer to see exactly what is included in the package and maybe customize it, you can import the Studio Application Template
and get the operation source code on github.
Configuration management marketplace package:
Configuration Management Marketplace package
Studio Configuration Management Application Template:
Can be found in Studio > Settings And Versioning > Application Template
Nuxeo Specific Baseline Configuration Operation Sources:
https://github.com/fvadon/nuxeo-configuration-management-poc
Nuxeo documentation on proxies:
Repository Concepts
Configuration Management on Wikipedia:
http://en.wikipedia.org/wiki/Configuration_management
CMMI for development:
http://www.sei.cmu.edu/library/abstracts/reports/10tr033.cfm
Contract management
This documentation describes how to manage contracts in Nuxeo with the application template Contract Management, available from Nuxeo
Studio.
The first parts of this page are a guide for functional user into the Contract Management application.
A more technical description is available at the end of this documentation for information on how the application template is designed with Nuxeo
Studio.
The different sections of this tutorial are:
Introduction
The content model
The workflow
Roles in the workflow
The workflow steps
Creation and Validation of Contracts
Automatic renewal management

105

Version Management
Batch
Technical description
Naming
Custom contract ID
System metadata
Introduction
The application enables you to manage your contracts, by defining contract owners and letting the DMS manage for you their lifecycle, so as to be
able to stop them before their automatic renewal, or so as to know when to renegotiate the conditions... You should expect high ROI if you are not
accustomed to such practices!
The content model

The Nuxeo contract management application template provides three documents types:
Contract_Library:
The contract library is a folder designed to hold contracts. Each contract library has a specific metadata: person_in_charge, that will be inherited
by contracts inside the library. Permissions are set automatically to give Read and Write permission to the person in charge who should be a
purchaser. Other roles are available inside the application, see the roles section for more information. A contract library is owned by one user
only.
Inheritance to contracts is performed by the system to make sure the person in charge is always consistent between a contract library and its
children contracts. So it is very simple to change the person in charge on a whole set of contracts, just change the person in charge of the
contract library.
Contract:
Contract is the main document type. It has its own life cycle (see the Workflow section for more info on the contract life cycle) and its own
metadata set, specific to contract management, such as a starting and an expiring date. The system enables to deal with auto-renewal contracts
through a checkbox at the contract creation.
Contracts can only be created in a contract library.
Here is a screenshot of the creation page of a contract.
The reference of the contract is automatically created using the contract type filled in at the creation.

106
Contract_viewer:
This document type is a specific type dedicated to filtering and visualizing contracts depending on your role and the contract life cycle states. It
contains no data directly but several tabs that look for and display contracts wherever they are inside the real arborescence.
A use case example is: if I am a jurist and that I have contracts to validate, I do not want to look for them in every purchaser's library. So I can
create a contract viewer wherever I want, my personal workspace for instance, and it will display all the contracts waiting for a jurist validation.
This is also useful to provide a way to access contracts waiting for a jurist validation even if I do not have Read permission on a part of the
arborescence that leads to the contract.
The tabs of a contract viewer are:
- My contracts in validation and redaction: shown to purchasers only, to display their contracts in these two life cycle states in which they
should work on.
- My contracts and libraries: display all contracts and contracts libraries of the current user if he is a purchaser.
- Contracts to be verified: the tab of the jurists, displays all contract waiting for legal verification.
- Contracts waiting for signature: the tab for managers, displays all contracts that should be signed.
- Auto-renewal contracts expiring soon: displays all contracts that are about to auto-renew in case an action should be done on it by
managers.
- Content: the default tab; it displays all contracts and contract libraries of the repository (if you have at least Read permission on them), it comes
with a filter to easily and quickly find contracts on info like their life cycle state, the person in charge, etc...
The workflow
In the example of contract management, 3 roles are available: a purchaser who creates the contract and starts the workflow, a jurist who does the
legal validation of the contract and finally a manager who signs the contract.
There should be 3 groups of users to use the contract management application:
purchasers
jurists
managers
The workflow steps

There are several steps to the life cycle of a contract. Some steps should be changed by a user (for example, to send the contract to validation)
and some states will change automatically. Two steps ("onGoingBeingResiliated" and "onGoingRenewalOK") are used specifically to manage
auto-renewal contracts.
Here is the life cycle of a contract:

107
Creation and Validation of Contracts

Redaction
When a purchaser is in a contract library he is in charge of, he can create a new contract with the button "New Contract" and fill in all the required
metadata of the contract. Once the purchaser has created its contract, he can send it to the legal verification by clicking on the action "Send to
verification":
Verification (legal)
When a contract is sent to verification by a purchaser, the system automatically updates the status logging date and the permissions to allow a
jurist to modify the contract, whereas the purchaser can now only see it. A jurist can quickly find any contract waiting for legal verification by using
the document type "Contract_Viewer":
When the jurist has verified the contract he can send it back to the purchaser in charge by clicking on the action "Send To validation":
Validation
At this step, the jurist cannot modify the document anymore but he can still read it. The purchaser can do the final validation before sending it to a
manager for signature:
SentWaitingForSignature
When a contract is sent for signature, nobody can edit it anymore but managers. A manager can easily find all contracts waiting for signature
through a contract viewer.

108
If the manager is OK with the document, he can mark it as signed:
Signed
The signed state is a temporary stage where the contract is ready to start, and will start automatically when the starting date is reached. A
contract has to be signed before it can goes to "OnGoing".
OnGoing
At this stage the contract is active, the next step will depend on whether the contract has automatic renewal or not.
Automatic renewal management

At the creation of the contract, the purchaser can choose if the contract should be renewed automatically or not. This will be taken into account at
the expiring date.
If the contract is not in auto-renewal mode, it will automatically go to "Expired" the day after the expiring date.
In the case of an auto-renewal contract, it is important to know that the expiring date is approaching because some actions may be required
before this date, such as terminate it. For that purpose, a special content view is available for managers to display all auto-renewal contracts
expiring soon (in less than three months):
Then, when a manager goes to an auto-renewal contract, he can do several actions:

Approve auto-renewal: the contract goes to "OnGoingRenewalOK" and will not be displayed in the view anymore, it will be renewed
automatically for a year at the expiring date.
Cancel Auto-Renewal: it puts the contracts to "OnGoingBeingResiliated", the contract will be sent to "Expired" automatically after the
expiring date and will not be displayed in the view anymore.
Nothing: if the manager does nothing on the contract, it stays in the views until the expiring date and then, the contract is renewed
automatically for a year and stays in "OnGoing" state.
Version Management
At each step of the workflow the version of a contract will be incremented automatically on a minor or a major version (depending on the step) so
that every changes on a contract are stored, and each version of the contract are always available. However, it is always possible for each
contributor of the workflow to increment version manually.
Batch
As seen before, several events happen automatically such as the auto-renewal of contracts. All these actions are done by a batch operation. On a
final application, this batch should be run automatically every night for example. In this demo case, the batch operation has to be launch manually
by the user action "Batch Contract State", this action is available in the user menu and will update all contracts inside Nuxeo that should be

109

updated (expired or renewed):
Technical description
Here are a few tips about the Contract management application template. You can import this project directly in your Studio project and deploy it
to your server. Once you are familiar with it, you can start customizing it if necessary. You can read the documentation on how to use application
templates in a Studio project.
This template is a complete use case of using Nuxeo Studio to implement a Business Case. You will find custom life cycles, content views,
document types, notifications, actions ... It is designed to provide a ready-to-use template for contract management workflows, especially to deal
with automatic renewal contracts and specific views and reminders.
Being already familiar with Studio main aspects is recommended to understand the template, if not the case, you can start by our how to get
started guide.
Naming
As the contract management template is supposed to be imported into other projects, it is very important that every item is easily recognizable.
This is the reason why item names are prefixed with CM as contract management.
Automation chains are named after the user action or the event handler that triggers them, for instance:"CM-SendToValidation" is triggered by
"CM-UA-Send_To_Validation_customActions", which is a user action (UA) displayed in the document summary action (_customActions).
Event handlers and their corresponding automation chains are name like "OnXXXXtion", for instance the event handler that captures the creation
of a contract is named "CM-OnContractCreation".
Automation chains are named depending on what they are supposed to do, for instance, if they start with "SendTo", it means that the document
will change of life cycle state during this chain, the final state is the end of the chain name: "CM-SendToValidation" sends the contract the
validation state. The prefix Ac means a simple action in which the state of a document is not changed like the creation of a document for instance
("CM-AcCreateCMLibrary").
And finally, a few automation chains are launched only from other automation chains using the operation Execution Chain>Run Document chain.
These chains are prefixed with "Sys" as System
Custom contract ID
At the contract creation, the contract type can be chosen. The contract type is used to create an automatic reference. This feature uses the logic
of the template: Custom Doc ID Generation
System metadata
Several metadata are never seen by users. These metadata are used in different ways by the system, for instance "recall_renewal_date" is the
date used to know if the contract will expire soon. It corresponds to the expiring_date_updated minus 3 months. These metadata are very
important for the system but are invisible to user. They are managed by event handlers and system automation chain (prefixed with Sys).
They are 2 recall dates:
"recall_renewal_date": Used in the content view "CM-AutoRenewalContractsSoon" to display all auto-renewal contracts expiring in less
than three months
"recall_signature_date": Corresponds to the signature date plus 15 days. It is not used, but could be consumed in a content view all
contracts waiting for a signature for more than two weeks.
Others date that are not filled in by the user are:
"expiring_date_updated": It is first a simple copy of "expiring_date_initial", but then this the actual expiring date, "expiring_date_initial" is
never modified.
"sent_date", "signed_date", "to_validation_date", "to_verification_date": these dates are only used for logging purpose, to remember

110

when the contract was sent to one these states.
Custom Doc ID Generation

It is very frequent that you need to generate incremental IDs with a business prefix that can depend on the context or the document being created.
This tutorial shows a simple use case, where the ID is generated depending on the document type: if the document is an invoice, it starts with INV
-, if it is a proposal, it starts with PROP-, if it is a salary sheet, it starts with WAG-...
In our usecase, the type is a metadata value that can be managed via a vocabulary.
Another vocabulary enables to choose the prefix name depending on the type. Of course, the number associated to the ID evoluates incrementaly
and independently for each value of the type metadata.
The key tool to generate IDs is the scripting function Fn.getNextId(String key) that gets a unique value for a given key. Each
time this function is called using the same key a different string will be returned (actually an incremented number).
In this tutorial, we will:
Override the File type definition to add a "type" property.
Declare the two required vocabularies in Studio (one for the list of types, and one for the associated prefix used in the ID generation)
Configure the event listener and associated automation chain that will concretely generate the ID and store it on the document.
Adding a "Type" Property to File Document Type

In this tutorial, we need the "file" document type to specifically have two metadata:
The "type" metadata, for which the user selects values among "Proposal", "Order", "Letter",... The selected type will determine the
document's ID composition. This metadata doesn't exist in any of the built-in schemas, so it needs to be added.
The "uid" metadata, that will store the generated business ID. This metadata exists already in any document type inheriting from
"Document" type.
To respect those two constraints, we will create a new document type that inherits from File (which itself inherit from Document) and will add the
"type" file. This will take 3 steps :
1. create a schema with the new "type" metadata,
2. create the new "File" document type that will override the default "file" document type,
Overriding a type definition is as simple as creating a new document type with the same name as the one being overridden.
3. create the File's forms.
Step 1: Creating a Schema with the New "Type" Metadata

1. Click on the Schemas item in the Studio tree, and click on New.
2. Fill-in the required information and click on the Next button.
Feature ID: additionalInfo
Schema prefix: additionalInfo
3. Click on the Add field button to add a line and fill it in:
Name: type
Type: string
Multi-Valued: not checked.
If a document is an instance of a type that holds this schema, to get the type property, you will have to use the following XPath
expression: additionalInfo:type.
4. Click on the Save button.
The schema is saved.
Step 2: Creating the New "File" Document Type

1. Click on the Documents item of Studio tree, and click New.
2. On the creation pop up window, fill in the informations below and click on the button Next:
ID: File
Extends: Nothing
Label: File
Description: a description of the document type
3. Fill the the Definition tab.
For containment rules implemented in our use case: a File is created in a Workspace or a Folder.
We don't need to filter any tabs.
We select the facets that are contributed for File type in the original contribution: Commentable, Publishable, Versionable.
4. In the schemas section, choose the following existing schemas: file (for the document's main content), files (for the attachment) and
don't forget the one you have just declared: additionalInfo.
5. Click on Save.
We will now build the associated forms.

111
5.
Be Careful
In the Schema tab, do not try to define already used schemas' names such as "file", it will lead to errors.
Step 3: Creating the File's Forms

1. Click on the Creation layout tab.
2. Drag'n drop, and edit the associated widget of the following properties:
dc:title: title field in dublincore schema,
dc:description: description field in dublincore schema,
file:content: content field (property that stores the real file) in file schema,
uid:uid: Uid field in uid schema
additionalInfo:type: type field in additionalInfo schema.
Double click on each of the widget you drop and choose a consistent title, etc...
For step by step guidance on how to edit forms, check the how-to How to Define a Document Type.
Now, we need to create the vocabularies used to populate the type list and to compose the ID.
Declaring Vocabularies
Now that the "File" document type has been overridden with our new file that has AdditionalInfo schema, we need to create the vocabularies
used to select the document type and generate the first part of the document's ID.
See how to add a new vocabulary.
1. Create a simple vocabulary "TypeLabel" with the values below, that will fill the drop-down list to edit the "type" metadata.
ID
Label
proposal
Proposal
invoice
Invoice
law_act
Law act
advertisement
Advertisement
2. Create a simple vocabulary "TypePrefix", that will give the corresponding prefix for UID generation, depending on the selected "type".
ID
Label
proposal
Prop
invoice
Inv
law_act
LA

112

advertisement
Ad
The values ID must be the same in both vocabularies.

3. Go and edit the widgets used for the Type and UID metadata to indicate the values should be taken in these vocabularies.
Next, we need to create and configure the automation chain that will generate the UID.
Configure the ID generation using functions

In the two previous steps, we have:
created a new "File" document type with "type" and "UID" metadata,
created the vocabularies for type drop-down list values and for the prefix that will be used to generate the UID.
Now, we want the UID of "files" to be updated just after the creation of the document. This ID will be formed using the prefix corresponding to the
type of the document and an incremental number.
To do this, we will create a listener (step 1 below) that will call an automation chain to update the uid:uid of the document (step 2 below) using
the Fn.getNextId and Fn.getVocabularyLabel functions.
Step 1: Creating the Listener

1. Click on Event Handlers in Studio tree (Automation section) and click on New.
2. On the "Create Event Handler" window, enter the Feature Id as UIDUpdateListener and click Next.
3. On the listener configuration form:
select "Document created" in the events list, to update the UID of the document only when the document is created,
select "File" in the filtering section, to limit execution of the listener to File document type.
Click the Create link under "Select the operation chain that should be executed by the handler" to create the automation
chain.
Step 2: Creating the Automation Chain to Update the UID

After clicking the Create link the listener is automatically saved and the operation chain creation pop up window is displayed.
1. Fill the name of the automation chain : UIDUpdateChain and click OK.
2. Edit the chain with the parameters below.
3. Click Save.
You can now deploy your plugin in a Nuxeo DM application.
Step
Operation
Parameter 1
Parameter 2
Fetch > Context Document(s)
Execution Context > Set Context

Variable
Name: typeValue
Value: @{Document["additio
nalInfo:type"]}

Variable
Name: prefixValue
Value: @{Fn.getVocabularyL
abel("TypePrefixVocabula
ry", typeValue)}

Variable
Name: idValue
Value: @{prefixValue}-@{Fn
.getNextId(prefixValue)}
Document > Update Property
Value: @{idValue}
xpath: uid:uid
If you use the editor, be careful to remove the key's double quotes in functions.
Human resources - Vacation request workflow

This documentation needs to be updated because the implementation of the shared template is now based on Content Routing
The goal of this tutorial is to explain the Studio application template : Human resources - Vacation request workflow.
This template is a complete use case of using Nuxeo Studio to implement a Business Case. You will find custom lifecycles, content views,
document types, notifications, actions ... so as to provide a ready-to-use template for HR workflows.

113

The best way to follow this documentation is to import the application template in your Studio project, find here the documentation on how to use
application templates in a Studio project.
Being already familiar to Studio main aspects is recommended to understand this documentation, if not the case, you can start by our how to get
started guide.
The different sections of this tutorial are :
The content model
The workflow
The workflow steps
Permissions
Display
Troubleshooting
The content model

In the Studio document section, you will find 2 documents types :
HumanResourcesFolderStructure :
It contains the HRHolidayRequests. It is a structured folder created with Structure template feature, and for each user it is created thanks to
listener "CreateHumanResourceFolder" that is executed at the creation of workspace type documents which path starts with
"/default-domain/UserWorkspaces".
HRHolidayRequest :
This is the main document type. It holds the holiday request data : beginning date, end date, managers, number of each vacation day type...
Holiday requests are associated with life cycle HRHolidayRequestLifecycle that holds request life cycle states, from draft to accepted trough
operational and then HR validation.
A "request vacation period" button is created in Human Ressource folder by the User Action "NewHolidayRequestAction" that triggers the
Automation Chain "CreateHolidayRequestChain". This chain first navigates to the user holiday folder and then shows the Holiday Creation page.
You can see here that some fields are already predefined with 0 values.

114
The zeros are filled in by the Automation Chain "HRHolidayRequestDefaultValuesChain". This chain is launched by the event handler
"HRHolidayRequestDefaultValuesEventListener" triggered on a empty HRHolidayRequest created event.
The workflow
In the process of validating a holiday request, 3 persons are involved : the request creator who starts the workflow, the user operational manager
who validates the request and finally the HR manager who confirms the request validation. Two groups are predefined : hr_operational_managers
and hr_manager.
During the validation workflow, tasks are assigned and emails are sent to the different people involved, so it is necessary to get their names and
emails at some points. It is easy to know who is the request creator as it is stored in the "dc:creator" field. The HR manager is also no very difficult
as we will send tasks and emails to the whole HR Manager group. But getting the user operational manager is a little more tricky.
The solution is to use a vocabulary and the fonction @{Fn.getVocabularyLabel("Vocabulary","id"}. The vocabulary is used to store the operational
manager of each user, the id will be the user, and the label will be operational manager.
In our case, it is mandatory to populate the vocabulary "EmployeeManagerMapping" either in your Studio project, or in Nuxeo as it will be used in
every automation chain where the operational manager is required.
Here is an exemple where jack is the operational manager of john :
The workflow steps

The workflow is started with a click on the user action "StartWorkflow" that launches the Automation Chain "SendToManager". Then all others
steps are crossed by task validations.
SendToManager :
This automation chain creates a Holiday request approval validation task to the operational manager and send him an e-mail notification. Please
note the e-mail is created using a template, it enables to send a rich mail using html-like formatting and parameters fetched from the context
(document creator, request beginning date...).
Then document life cycle is set to "op_manager_approval", several properties of the document are updated (request creation date...) and Read &
Write permission is granted to the operational manager so that he can make modifications if needed.
Operational manager validation
When the operational manager validates his task, it launches "OMValidatedChain". This chain set the document life cycle state to
"hr_manager_processing", creates a task to HR manager and send an email to both HR manager and the request creator.
If the Operational manager rejects the request, it sets the request to "rejected" and send an e-mail notification to the creator of the request.
HR manager validation
If a HR manager validates the holiday request, it sets the state to accepted, and send an e-mail notification to both the creator of the request and
his operational manager.
Permissions
During the different steps of the workflow, people have different needs of accessing the requests, those needs change with life cycle states. For
example, operational manager does not need the write permission when the request is in draft state.

115

Permissions are managed in the workflow with Document>Set ACL, and Document>Remove ACL operations.
A base permission is defined and created with the Automation Chain "SetUpBaseHolidayRequestWorkflowACL" which grants permission to read
for the user operational manager and write for the request creator.The permission is named "HolidayRequestWorkflow" with the operation
Document>Set ACL. It will then be easy to handle (remove for example) this permission by using its name in Document>Remove ACL.
After the base permissions are set, each operation of the workflow sets specific permissions, for instance : write permission to HR manager when
he has to validate the request.
This way of doing insures that the minimal required acces rights are set for each operation of the workflow.
Display
Content views :
When going the human ressource folder, each user has access to different views depending on his role. For example, an operational manager
can see all pending request of his team.
This view are defined in the search and listing section of Nuxeo studio and are displayed in additional tabs of the human ressources folder
depending once again on user role.

116
The user menu human ressource link

The studio project adds an entry directly in the user menu to navigate to human ressource folder thanks to the user action "GoToHR". The bound
automation chain is "GoToHRSpaceChain". This chain not only navigates to the user's humane ressource folder and but also checks that it exists
and if not, launches another automation chain to create the human ressource folder.
Troubleshooting
A little bit of configuration is required to make the workflow works properly, please feel free to check the following items in case you encounter
problems when testing the project.
E-mail configuration :
In almost each steps of the workflow, e-mails are sent, so make sure your email configuration is correct (mail.smtp.host, mail.smtp.port) in your
configuration file. The configuration file may be situated in various places depending on your OS, the installation type... Here is a link to find it on
Windows
EmployeeManagerMapping vocabulary :
As explain in the first part of the Workflow section of this tutorial, users are linked to their operational manager thanks to
the EmployeeManagerMapping vocabulary, so make sure this vocabulary is populated before fulfilling a holiday request.
Using Application Templates

To import an Application Template:
1. Click on the Import button in the top menu.
You can also access the Application Templates library from the Settings & Versioning menu located by default at the bottom
of the left column.
All the available templates are displayed. If a template is not compatible with your project target version (ex: Nuxeo DM 5.4.0, Nuxeo DM
5.4.2), it is displayed with a little sign
that says "not compatible".
2. Click on the Details link of the template that you're interested in to check what the template includes.
A window pops up that displays the list of all elements the template includes: definition of new documents, automation chains, etc, new
icons and images, new widgets...

117
3. Click on Import this template.

4. On the confirmation window that pops up, click on OK.
A feedback window pops up to indicate that the import was successful.
5. Click on OK.
The icon
is displayed next to the imported template, indicating that this template has been imported.
Your project is reloaded with all the template's features. You can now browse your project with the new imported features and edit them.
If you modify something, Studio will tell you that you broke some other configuration by displaying the errors, and you'll be able to adapt
every dependent thing. Also you'll be able to rename the imported features if you need.
Using several application templates
Some templates declare the same object. For instance two templates can declare the "Folder" document type. In that case, Nuxeo
Studio will refuse to import the second template until you rename the previous object, to avoid collision.

118
Frequently Asked Questions

Is it possible to export a Studio project in Eclipse ?
Nuxeo Studio and Connect architecture
Is it possible to export a Studio project in Eclipse ?

Nuxeo Studio role is to generate XML configuration from your instructions. The plugin you can download from Nuxeo Studio is a strict set of XML
files and pictures you would have uploaded in Studio. To be sure of this, you can rename the JAR you downloaded, unzip it and have a deeper
look: You will find the "sources" of your project. Technically, nothing prevents you from importing the files in Eclipse, doing some modifications
from there and committing changes in your own source repository. Yet, this would not be a good idea because:
You will definitively lose the ability to maintain your project in Nuxeo Studio, as there is no reverse path. That means no ability to easily
modify a automation chain by drag'n drop, no ability to customize quickly the layout, no ability to benefit from easy customization of new
features (that would not be yet in the version on which you started the project).
You will lose the "easy-maintenance" value of Studio. Indeed, to upgrade a plugin made with Studio, you just need to change the version
of the distribution on which your project is based, in the preferences. Nuxeo Studio generates the good XML for your target application
version.
We can see the reasons why you would like to switch your project to Eclipse:
You might want to "switch" to Eclipse because your are blocked in Studio and cannot manage to do everything you want. In that case:
First, check if contributing an external declaration in the Advanced Settings/Registries unblocks you (external type, operation,
facet, action, ...).
Don't hesitate to submit your problem by using the Help Request form or to your Nuxeo Support Team: It is always very
interesting to get your feedback, we prioritize the Studio roadmap with it!
If the reason why you would want to export the code is for easier maintenance of configuration sources, you should have a look at the Ve
rsion Control page, where you will see that you can commit your changes, track them and create tagged versions of your project.
If there are other reasons why you would want to import the project into Eclipse, share it in the comment section of this page!
Nuxeo Studio and Connect architecture

Software architecture
Nuxeo Connect is mainly based on Nuxeo Platform (CAP + DM) with a set of additional custom plugins.
Nuxeo Studio is used to generate all the Domain model and associated configuration
Client / Project / Support package
Forms, Content Views ...
Nuxeo JSF UI (Layouts, Content views, Actions) is used for backoffice
manage client accounts
manage projects
...
WebEngine is used to
generate the web front end
generate the marketplace site
expose the Maven Servlet
JAX-RS is used to expose the REST API
used by connect-client to list and download packages
used by JIra
nuxeo-gwt is used to integrate the Studio GWT module with Nuxeo
In addition Connect leverages some additional software :
CAS for SSO
VertX for collaboration inside a Studio Project
JGit for Git access
JIRA
About Connect Data

Principles
Nuxeo Connect manage several kind of data that are technically managed by different services and storage.
Nuxeo Repository (PostgreSQL + Binary Manager on NFS)
store client / projects / subscription info (as Documents)

119

store meta-data about Studio project
Git (NFS)
each Studio Project is asssociated with a Git Repository
each Git repository stores complete history about the Studio Project
LDAP (replicated local LDAP)
manage user accounts
Backup and Recovery

All the data is backuped everyday :
dump PGSQL database
tgz of nuxeo Blob Store
tgz of the nuxeo configuration
tgz of Git Filesystem for Studio
projects are grouped by first letter
"source" and built of tagged jars are backuped separately
(LDAP Server used by connect is replicated).
Retention policy is:
keep the first backup of any month forever
keep the first backup of the second half of any month for 1 year
keep the last 30 days
The backups are stored on an EBS and on an internal Nuxeo NAS.
Security
Nuxeo Connect defines ComputedGroups and SecurityPolicies that enforce security logic :
a user can have access only to project he is member of
Marketplace download is checked against security policies
Access to a Studio Project is checked against security policies
Download of a Studio project via Maven Servlet is checked against security policies
There is no direct access to the data, all access have to go throught Nuxeo Platform that enforce the secutiry checks.
Connect Technical Architecture

Hosting
Nuxeo Connect platform is hosted on AWS :
Nuxeo and PostgreSQL nodes run on an Ubuntu image
We use ELB for load balancing
EBS is used for storage and for backup
Architecture :
Connect architcture is currently composed of :
ELB with https endpoint that manages LoadBalancing with affinity:
affinity on JSessionID
affinity on Studio projectID
2 Nuxeo Tomcat VM (Nuxeo 5.7 at this time)
1 VM with PGSQL, VertX and the NFS export
Monitoring
Since Connect was aligned on Nuxeo 5.7, it is now using Graphite to report Nuxeo and system metrics.
Logs are centralized using Logstash, ElasticSearch and Kibana.
Collaboration Mode
It is possible to activate a collaborative mode on Nuxeo Studio, so as to let several people work together on the same project. This page
provides some details about this feature.
Enabling Collaboration Mode

120

The collaboration mode comes with a Gold Support contract. You can talk about this feature to your support or sales contact, they can enable
it on your project.
Seeing Connected Users

On the top left corner of Nuxeo Studio interface, you can see the list of connected users. Note that you can subscribe to as many accounts as
you need.
In this section
Enabling
Collaboration Mode
Seeing Connected
Users
Locking a Feature
Browsing a Feature
That Is Not
up-to-Date
Committing on Save:
Providing Better
Visibility to Who
Modified What
Locking a Feature
On the screenshot above, we see the user aescaffre is browsing a feature which the user sguitter is already editing. Nuxeo Studio alerts
aescaffre that the feature is locked and also disables the "Save" button which is greyed. Studio did lock the feature automatically, sguitter
didn't have to lock it on purpose: everywhere sguitter goes in Studio, the corresponding feature is locked in real time on aescaffre 's browser,
and vice versa.
Note that aescaffre can steal the lock so as to prevent situations where sguitter has gone to lunch and stayed on the feature, preventing
aescaffre from being productive
Browsing a Feature That Is Not up-to-Date

121
Because Studio works completely client side, you would need to always fully refresh your page to make sure you have the latest state
server-side. Fortunately, with the collaboration mode, Studio alerts you in real time that the page you are browsing is not up-to-date: someone
has pushed a more recent version on the server. That way, you never override someone else's work. You just need to click on the "reload"
button before starting working on the feature instance.
Committing on Save: Providing Better Visibility to Who Modified What
As you can see, it is possible to enable the "commit on save" mode, from your project preferences. That way, each time you save, you do a c
ommit. This is very useful when you are several persons working at the same time on a project, to understand what modifications where
done, by whom.
The changes view gives you the history of the commits, and for each selected commit the changed files (at the bottom). Then, you can even
have the detailed diff for each of the files:

122
Roadmap
Nuxeo Studio is shipped in the Software as a Service style (SaaS), from your Connect account. This enables us to frequently update Studio,
without disturbing your development cycle. We leverage this capability to continuously update the software so as to fix identified bugs, and will at
the same time communicate a very clear and discrete roadmap for main evolutions and features.
What Is Keeping Us Busy: main coming features.
Releases History: See the content of all previous major releases of Nuxeo Studio
What Is Keeping Us Busy

In 2014, we will focus on user experience:
providing more automated check,
improving global navigation: utilities for finding objects, interlinked objects browsing, ...
working on auto-completion or at least an easy way to include a technical id in the middle of your expression,
improving the visibility of elements (ex: provide a better interface for automation chains so as to quickly view what it does),
making sure the same level of service is exposed on all the features (refactoring, locking, enablement, ...),
providing some means for branch management, so as to improve collaboration and allow having qualification branch, production branch,
...
On the feature side, the main evolution will concern automation chains, with ability to have parametrized chains, and error management (features
currently available at lower level in the platform but not yet exposed in Studio). You should also expect some small improvements on the workflow
side and as usual, better widgets, new operations, etc...

123
Release Note History

20
19
18
2.17
2.15
2.14
20
Release Notes - Nuxeo Studio - Version 20
Sub-task
[NXS-1553] - Remove references to refId in target platform contributions
[NXS-1794] - Expose DEV target platform for Nuxeo developers
[NXS-2132] - Minimize codemirror resources for Studio
Bug
[NXS-2050] - Fix Preview tab enablement on documents
[NXS-2079] - Improve UmbrellaException stack traces
[NXS-2100] - Fix release script tag and dry run
[NXS-2102] - Fix display of the "Path tree" widget type
[NXS-2103] - Fix available operators for a generic search widget
[NXS-2107] - Fix default value init on XSD import
[NXS-2110] - Dropping an operation should make it editable
[NXS-2112] - Fix Query filter formatting after save
[NXS-2114] - Fix Read/Edit toggle mode on code mirror editor in automation chain
[NXS-2115] - Fix issues in YAML editor
[NXS-2117] - Fix "foldable" property label on toggleable form widget type
[NXS-2118] - Fix container widget behaviour in tabs
[NXS-2134] - Fix incorrect verification of the target platform when migrating section tab
[NXS-2135] - Fix unknown target platform message
[NXS-2139] - Cursor is not aligned with text lines in query filters text area
[NXS-2140] - When clicking on "Switch editor" there is a bug
Improvement
[NXS-1923] - Handle administrators on Studio
[NXS-2109] - Make it possible to scroll down the chain while dropping an operation
[NXS-2111] - Improve appearance of nxql completion
[NXS-2113] - Improve UX of nxql auto-completion
[NXS-2127] - Add nxql auto-completion on multi-valued where clause when possible
New Feature
[NXS-1998] - Add hint for NXQL on code mirror integration
[NXS-2028] - Integrate new target platform module in Studio
[NXS-2053] - Allow edit of automation chain in plain text
[NXS-2092] - Add the "Collection Search" widget to the content view search screen
Task
[NXS-2097] - Remove the loading of olark
[NXS-2120] - Synchronize widget types definitions for 5.9.5
[NXS-2129] - Release Studio 20
[NXS-2130] - Add target platform 5.9.5
19
Sub-task
[NXS-2015] - Upgrade dev launcher to Nuxeo 5.9.3
[NXS-2016] - Add the deployAtEnd configuration to the maven deploy plugin
Bug

124
[NXS-1567] - Improve readability of an automation chain

[NXS-1719] - In a complex widget, hide subwidget labels option does not default to indicated value
[NXS-1834] - Fix broken link on Lifecycle help popup
[NXS-1853] - Add safe edit to Studio registries
[NXS-1854] - "Import Layout" does not always import the vocabulary name
[NXS-1965] - Fix link to online demo for "Live edit link" listing widget
[NXS-2012] - Add validation error when two schemas have the same prefix
[NXS-2018] - Fix Studio label saving when value is the same as widget label
[NXS-2035] - Fix sample CSV vocabulary files to be consistant with "actual" CSV files
[NXS-2041] - Login box shouldn't move up when News box is deactivated
[NXS-2062] - Fix Studio version in DevLauncher
[NXS-2074] - Fix bad replacements when releasing Studio
[NXS-2084] - Fix Studio build when using the release profile
[NXS-2085] - Fix target platforms used in tests
[NXS-2089] - Problem adding Tags widget to Content View
[NXS-2095] - Allow subwidgets configuration for a generic widget in search layouts
Clean up
[NXS-2076] - Clean up tests output and some error logs
Improvement
[NXS-1604] - Labels of checkboxes and radiobuttons should be clickable
[NXS-1939] - Enable CSV export on DAM standard listing
[NXS-2081] - Make text/select inputs larger on project editor
[NXS-2088] - Display a confirmation dialog before deleting an operation
[NXS-2096] - Rename Input Parameters tab on automation feature
New Feature
[NXS-2070] - Make it possible to set input parameters on an automation chain
Task
[NXS-2014] - Align Studio on Nuxeo 5.9.3
[NXS-2073] - Add 5.9.4 target Platform
[NXS-2087] - Add collectionMember schema for filtering in content views
[NXS-2098] - Update Chain parameter tab help text
[NXS-2099] - Set string as a readonly choice for the type of parameter on chain parameter tab
User story
[NXS-2071] - Automation screen > Update styles
[NXS-2086] - Nuxeo Identity > Nuxeo Studio
18
Sub-task
[NXS-1699] - Display the "Extra schemas" in document types
Bug
[NXS-1851] - Fix nested complex types generation in schemas
[NXS-1991] - Fix wrong chain directory widgets
[NXS-1995] - Fix exception on Transitions tab of a workflow node
[NXS-2000] - Fix declaration of facets
[NXS-2002] - Fix validation on complex fields search like complexSchema/*1/item
[NXS-2003] - XSD generator fails to properly generate the nested complex types
[NXS-2006] - Fix generated layouts when using nested complex types
[NXS-2013] - Fix studio-web module pom declaration for release scripts
[NXS-2027] - Fix layout tooltips after ajax re-render
[NXS-2031] - Re-Enable the possibility to add default values in schemas for multi-valued fields
[NXS-2046] - Fix functional tests on 5.9.3-SNAPSHOT due to changes on user creation form
[NXS-2048] - Fix typo in content view flags validation error

125
Improvement
[NXS-1996] - Syntax highlight > Review styles
[NXS-2004] - Add more lines by default to the codemirror editor on XML extension and css views
[NXS-2043] - Reference new automation doc in Studio
[NXS-2044] - Remove "new" marker on Nuxeo 5.8
New Feature
[NXS-1928] - Allow copy/pasting a Studio project
[NXS-1934] - Add new mvel functions for escalation rules
Task
[NXS-1948] - Change the marketing tracker
[NXS-1963] - Specify a dedicated "target platform information management" service
[NXS-1969] - Test the 5.9.2 release in integration tests
[NXS-2020] - Switch Studio on going versionning to main digit upgrade.
[NXS-2034] - Tooltips > Replace jquery tooltips by tipsy tooltips
[NXS-2037] - Add 5.9.3 target platform and remove 5.9.1
[NXS-2040] - Synchronize operations for 5.8 and 5.9.3
[NXS-2045] - Synchronize branding changes for 5.9.3
2.17
Release Notes - Nuxeo Studio - Version 2.17
Bugs
[NXS-1363] - Workflow editor is marked as dirty after navigating to the graph editor without modifying it
[NXS-1378] - Document types are created twice with using the keyboard to create it
[NXS-1447] - bug in content view filter configuration with complex property
[NXS-1684] - Validating a user action creation with the keyboard creates the action twice
[NXS-1790] - Life cycle uses old icons
[NXS-1801] - Disable olark rules request in dev launcher and tests
[NXS-1831] - Fix builtin Directory operations
[NXS-1885] - Fix styling of the features tree in "new" popup
[NXS-1919] - Update login.jsp templates with proper escaping
[NXS-1922] - Add validation warning when using a messages_fr.properties file instead of messages_fr_FR.properties on 5.8
[NXS-1926] - Fix duplicate Yes (default value) option in text widget (view mode)
[NXS-1929] - Fix crash on select2 widgets having already a value set for the 'width' property before 2.16
[NXS-1936] - Make sure the 5.9.1 release is tested
[NXS-1937] - Fix loading of some projects
[NXS-1946] - Fix access key CTRL+Space on XML Extension editor
[NXS-1952] - Optimize xstream parsing
[NXS-1960] - Don't add empty assignee to task
[NXS-1973] - Fix error popup when saving subwidget
[NXS-1976] - Input editor is not enabled at first on the CSS integration of CodeMirror
[NXS-1982] - Error when I click on a saved studio faceted search from my Home
Improvements
[NXS-398] - Avoid saving the popup when pressing the enter key on a textarea
[NXS-1724] - Automation Chain specific documentation should be unfolded when not empty
[NXS-1796] - Unblock select2 suggestion widget in subwidgets for complex fields for target platform >= 5.7.3
[NXS-1800] - Expose PublishSpace and MasterPublishSpace facets
[NXS-1870] - Review style of help messages
[NXS-1886] - Improve "resize graph" action on workflow
[NXS-1895] - Add validation for MVEL expressions
[NXS-1918] - Update widget types definitions
[NXS-1951] - Allow referencing large CSV files in vocabularies
[NXS-1953] - Implement lazy loading of large features
[NXS-1974] - Add minor improvement of the import CSV popup
[NXS-1980] - Branding: make "Background covers all the screen" checked by default
[NXS-1981] - Show a "new" sticker next to new boolean "Background covers all the screen" in branding
Tasks
[NXS-1842] - Specify and prototype autosuggest

126

[NXS-1844] - Synchronize widget types definitions
[NXS-1908] - Mockups of Automation Chain screens improvements
[NXS-1944] - Expose category BREADCRUMB_ACTIONS for 5.9+ target platforms
[NXS-1947] - Minimize CodeMirror javascript resources
[NXS-1949] - Release Studio 2.17
[NXS-1954] - Optimize validation of MVEL expressions
[NXS-1964] - Mail templates > Update templates
[NXS-1967] - Add new target platform for 5.9.2 and deprecate 5.9.1
[NXS-1970] - Improve test screenshots
[NXS-1985] - Fix default value for display action in select users/groups widget type
User stories
[NXS-1966] - Vocabularies: review CSV import screen
2.15
In a Nutshell
In the latest release of Nuxeo Studio we have exposed some of the latest capabilities in the Nuxeo Platform v5.8, offering more configurability.
Heres whats new:
DAM widgets are now available in Studio. Widgets such as Video Storyboard, Video Reader, Picture Web View and more can be used in
your tabs.
All Select2.js widgets have been exposed in Studio, with all their options. Select2.js widgets are the suggestion widgets in the platform.
Use suggestion widgets in simple selection and multi-selection controls for users (silently replacing the previous implementation),
directories, documents (silently replacing the previous implementation). For advanced integration a widget is also available to support any
operation which will return some correctly formatted JSON, .
These widgets offer new and interesting possibilities, such as being able to define the NXQL query used inline, or being able to format a
value displayed in a list, thus making it possible to display multiple fields of a document in each drop-down item.
New categories of actions were added in the header and the footer. In particular, you can use the "Main Tabs" category to add new
navigation links to some strategic locations in your repository (links will appear beside the Home and Document Management tabs).
New operations are exposed.
Some additional noteworthy improvements include:
The faceted search configured with Studio that uses full text search is now compliant with the top-right suggestion box. If you click on the
full-text search from the suggestion box (provided you have a full text search field on your faceted search) everything will work smoothly.
Default application templates for DM and DAM have been updated.
A new parameter in the flavors has been added: if you don't want the default "blue" that appears on the selected main tab, you'll have to
set a new color.
Better Management of Fast Track Transition

Finally we took your feedback into account and improved the management of the fast track transition.
There is still room for improvement, but now when you connect and your project is on a Fast Track version that is not supported by Studio
anymore (e.g. 5.7.2), Studio forces you to go the target version setting screen where you can set an existing value (you may want to migrate to
5.8 currently).
Also note the new download link beside the target platform that makes it easy for you to get the correct version of Nuxeo!
JIRA Release Notes

Sub-task
[NXS-1439] - Summary widgets handling their labels
[NXS-1633] - Add DAM widget types
[NXS-1736] - Expose new operations in Studio
Bug
[NXS-826] - Manage problem of the modal pane actions
[NXS-1668] - Deprecate facet HiddenInFacetedSearch and remove Indexable facet
[NXS-1737] - Remove chain select widget types from Studio contributions
[NXS-1766] - Fix removal of selected packages when switching target platform
[NXS-1773] - Fix content view cache default values when using the DAM flag
[NXS-1775] - Setting Vocabulary Widget doesn't work

127

[NXS-1782] - Olark do not fetch rules definition
[NXS-1786] - Page index.html is not displayed on Studio
[NXS-1787] - Fix Studio webdriver tests now that main tabs are using uppercase
[NXS-1788] - Olark is saying to much Hello to customer
[NXS-1789] - Fix error on a application templates
[NXS-1792] - Fix collabctl script to work when no terminal is present
[NXS-1799] - Fix Export to PDF custom result layout
[NXS-1803] - Cleanup spurious *HF* versions on RC releases in MP packages
[NXS-1804] - A facet on a document is there on connect-test and not on connect
[NXS-1806] - Downloaded package descriptors must be consistent with later downloaded package
[NXS-1807] - Wrong session logout in UpdatePackage
[NXS-1810] - Add better warning for nested surrounding forms
[NXS-1812] - Remove directory operations from 5.7.3 contributions
[NXS-1816] - Fix installation of old package instead of SNAPSHOT one
Improvement
[NXS-1680] - Selecting "Foldable = Yes" in a Container widget's properties doesn't make it foldable
[NXS-1726] - Workflow transitions should have different colors
[NXS-1771] - Remove "section content" default tab from 5.8 contributions
[NXS-1780] - Improve presentation of deprecated target platforms
[NXS-1784] - Add suggest box configuration for faceted search content views
[NXS-1809] - Add a direct download link of Nuxeo next to target platform
New Feature
[NXS-1683] - Add a chat feature on Studio using quick integration component Olark
[NXS-1767] - Add new action categories for header and footer
Task
[NXS-1519] - Branding > Update header styles and values
[NXS-1652] - Remove dataTableNoBorder class on widgetTable
[NXS-1735] - Update widget types that will be based on Select2
[NXS-1740] - Upgrade layout-api to benefit from new json features
[NXS-1754] - Change available fast tracks for 5.8 release
[NXS-1759] - Test the 5.7.3 release
[NXS-1761] - Update widget types definitions
[NXS-1774] - Add olark json file rules on connect-test
[NXS-1778] - Update available operations for 5.8
[NXS-1783] - Upgrade default application templates for 5.8
[NXS-1811] - Branding > Update default values
[NXS-1813] - Login > Allow users to remove the background-cover rules
[NXS-1814] - Remove "new" markers on workflows and tabs features
User story
[NXS-1455] - Configure DAM with Studio
2.14
In a Nutshell
This time, we put the emphasis on stabilizing/improving what exists and taking feedback of our dear users, more than on adding new features:
5 evolutions/new features, 15 improvements and 19 bug fixes!
Some of the new features in this version include:
A new "Tabs" widget, compatible with Nuxeo Platform 5.7.3, that enables the display of tabs in the location of your choice. Previously,
display options for tabs were limited to matching the default UI. Rendering options will be coming next.
New workflow features available with Nuxeo Platform 5.7.3 have been integrated in Studio: multi-task node, re-assignment support,
new workflow events, new Automation scripting objects.
Some noteworthy improvements:
Your project name and the feature you are working on are now displayed as the title of your browser tab or window.
Different colors are used on workflow transitions to improve readability of the graph.
The scripting assistant no longer improperly nests the @{} markers in the expression. It now tries to understand the position in the
existing expression.

128

It is now possible to override the login page and configure the theme in Studio.
Some bugs:
The "Select All" shortcut "CTRL+A / Cmd+A" is back on Chrome and Safari.
Long transition names are now properly handled in the workflow graph.
Detailed List
Bugs
[NXS-1149] - Select All short cut in Studio doesn't work when using webkit based browsers
[NXS-1172] - Long transition name breaks the connection line between two tasks
[NXS-1391] - Workflow node recursive loop in graph doesn't show up with Chrome browser
[NXS-1413] - Cannot select system properties in Advanced Search edition screen for Path widget
[NXS-1443] - Allow schema field name "content" for type "blob"
[NXS-1536] - Life cycle error message on initial state is not accurate
[NXS-1539] - class cast exception error while editing operation parameters
[NXS-1552] - Fix grid layout when hiding some widgets
[NXS-1630] - Workflow editor crashes when trying to clear graph if a graph contains a loop on one node
[NXS-1632] - Welcome page: window does not show scroll if content is high
[NXS-1634] - Target info display problem for studio projects still having "dm" as a target platform
[NXS-1667] - Fix DM contributions holding DAM contributions
[NXS-1694] - Sub-workflow node and escalations rules shouldn't be availabe in the graph editor for a target platform before 5.7.2
[NXS-1695] - Typo in sub-workflow variables tooltip
[NXS-1705] - Fix error when target version is unknown
[NXS-1707] - Fix the widget generated for the task layout when using a workflow/node variable of type 'blob' and a widget of type "File"
[NXS-1712] - Add back functional tests on 5.4.2
[NXS-1715] - Fix migration of inverted event handler condition
[NXS-1716] - Fix custom EL expression sample on workflow availability tag
[NXS-1729] - Studio fails to build the JAR when a subworkflow id is not provided
[NXS-1743] - marketplace package not compatible with HF distribution
[NXS-1751] - Fix JS error when loading a Studio project
[NXS-1755] - Fix random error on test StudioTargetPlatformITCase
Improvements
[NXS-655] - Label changes
[NXS-1357] - Upgrade jsPlumb to 1.5.1
[NXS-1441] - Add current object name to window/tab title
[NXS-1445] - Scripting assistant shouldn't nest @{ } instructions
[NXS-1651] - Label homogeneity > Review Labels of document definition
[NXS-1692] - Display target packages on Studio project in back office
[NXS-1708] - Show warning when declaring a workflow and a node variable with the same name
[NXS-1709] - Change error message when there is no stop node in the graph to use 'stop' instead of 'end'
[NXS-1723] - Add new workflow events
[NXS-1727] - Add workflow related expressions in the EL builder
[NXS-1728] - Add validation error if no workflow is set on a node of type sub-workflow
[NXS-1731] - Add "Resume workflow" operation to Studio
[NXS-1738] - Remove warning regarding the fact that no file widget is used while the document type has a binary property
[NXS-1748] - Use different colors to draw transitions on a node with more than one outgoing transition
[NXS-1749] - Add a "soon deprecated" marker for the last fast track
[NXS-1750] - Change order of target platforms
New Features
[NXS-1612] - Add n-tasks node support
[NXS-1683] - Add a chat feature on Studio using quick integration component Olark
[NXS-1721] - Add support of task re-assignment
[NXS-1732] - Allow task reassignment
[NXS-1747] - Make the new "Tabs" widget available on Studio
[NXS-1758] - Allow configuring subtabs
Tasks
[NXS-1195] - Add non-regression tests for chain creation from action feature
[NXS-1395] - Allow "startswith" operator on content views and searches for system properties from 5.7
[NXS-1466] - Update login screen configuration for 5.7
[NXS-1576] - Labels > Homogenize Life cycle label

129

[NXS-1648] - Add a minimal integration test of the workflow feature
[NXS-1664] - Improve colspan attributes in layout forms tables
[NXS-1677] - Mark 5.7.1 target platform as deprecated and remove dev marker from 5.7.2
[NXS-1706] - Test 5.7.2 release in integration tests
[NXS-1753] - Change available fast tracks for 5.7.3 release
[NXS-1757] - Temporarily disable validation warnings when using deprecated widget types
Section 508 Compliance (VPAT)

Date: April 30, 2014 - (Work in progress)
Product: Nuxeo Studio
Summary Table
Guideline
Applicable
Compliance
Section 1194.21 Software Applications and

Operating Systems
Applicable
Supports with exceptions
Section 1194.22 Web-based internet

information and applications
Applicable
Section 1194.23 Telecommunications

Products
Not Applicable
Section 1194.24 Video and Multi-media

Products
Not Applicable
Section 1194.25 Self-Contained, Closed

Products
Not Applicable
Section 1194.26 Desktop and Portable

Computers
Not Applicable
Section 1194.31 Functional Performance

Criteria
Applicable
Section 1194.41 Information, Documentation,

and Support
Applicable
Section 1194.21 Software Applications and Operating Systems

Criteria
Supporting Features
Remarks
(a) When software is designed to run on a

system that has a keyboard, product
functions shall be executable from a
keyboard where the function itself or the
result of performing a function can be
discerned textually.
Most of Nuxeo Studio's core functionality is

keyboard accessible. Exceptions are: Setting
hidden tabs (Document Type), "New" button
(b) Applications shall not disrupt or disable

activated features of other products that are
identified as accessibility features, where
those features are developed and
documented according to industry standards.
Applications also shall not disrupt or disable
activated features of any operating system
that are identified as accessibility features
where the application programming interface
for those accessibility features has been
documented by the manufacturer of the
operating system and is available to the
product developer.
Supports
Nuxeo Studio does not interfere with or

deactivate the accessibility features of the
operating system.

130

(c) A well-defined on-screen indication of the
current focus shall be provided that
movesamong interactive interface elements
as the input focus changes. The focus shall
be programmatically exposed so that
Assistive Technology can track focus and
focus changes.
Nuxeo Studio provides a visual indication of

focus for most interactive elements.
(e) When bitmap images are used to identify

controls, status indicators, or other
programmatic elements, the meaning
assigned to those images shall be consistent
throughout an application's performance.
Supports
Images are used consistently within Nuxeo

Studio.
(f) Textual information shall be provided

through operating system functions for
displaying text. The minimum information
that shall be made available is text content,
text input caret location, and text attributes.
Supports
Textual information is available to assistive

technology in Nuxeo Studio.
(g) Applications shall not override user

selected contrast and color selections and
other individual display attributes.
Some buttons and other visual information in

Nuxeo Studio is either lost or has very low
contrast when used in Windows High
Contrast mode.
(h) When animation is displayed, the

information shall be displayable in at least
one non-animated presentation mode at the
option of the user.
Supports
Nuxeo Studio has no core features that

utilize animation.
(i) Color coding shall not be used as the only

means of conveying information, indicating
an action, prompting a response, or
distinguishing a visual element.
Supports
In some cases Nuxeo Studio uses color to

convey information, including:
1. To display items with errors
2. To display items with warnings
(j) When a product permits a user to adjust

color and contrast settings, a variety of color
selections capable of producing a range of
contrast levels shall be provided.
Not applicable
Nuxeo Studio does not implement such

feature
(k) Software shall not use flashing or blinking

text, objects, or other elements having a
flash or blink frequency greater than 2 Hz
and lower than 55 Hz.
Supports
Nuxeo Studio has no flashing or blinking text,

objects or other elements.
(l) When electronic forms are used, the form

shall allow people using Assistive
Technology to access the information, field
elements, and functionality required for
completion and submission of the form,
including all directions and cues.
Some form controls do not have accessible

names
Section 1194.22 Web-based Internet Information and Applications

Criteria
Supporting Features
Remarks
(a) A text equivalent for every non-text

element shall be provided (e.g., via "alt",
"longdesc", or in element content).
Text alternatives are available for core

Nuxeo Studio features using non-text
elements. Some images do not have alt text,
including:
Some decorative images used for layout do
not include null alt attributes
(b) Equivalent alternatives for any multimedia

presentation shall be synchronized with the
presentation.
Supports
Nuxeo Studio core features do not include

any multimedia presentations.

131

(c) Web pages shall be designed so that all
information conveyed with color is also
available without color, for example from
context or markup.
In some cases Nuxeo Studio uses color to

convey information, including:
1. To display items with errors
2. To display items with warnings
(d) Documents shall be organized so they

are readable without requiring an associated
style sheet.
Does not support
As Nuxeo Studio is a web-based application

(not a document), its UI relies heavily on the
use of associated style sheets.
(e) Redundant text links shall be provided for

each active region of a server-side image
map.
Not applicable
Nuxeo Studio does not use image maps.
(f) Client-side image maps shall be provided

instead of server-side image maps except
where the regions cannot be defined with an
available geometric shape.
Not applicable
Nuxeo Studio does not use image maps.
(g) Row and column headers shall be

identified for data tables.
Supports
(h) Markup shall be used to associate data

cells and header cells for data tables that
have two or more logical levels of row or
column headers.
Not applicable
Nuxeo Studio UI does not contain data tables

that have two or more logical levels of row or
column headers.
(i) Frames shall be titled with text that

facilitates frame identification and navigation.
Supports
When used for user navigation, frames have

title
(j) Pages shall be designed to avoid causing

the screen to flicker with a frequency greater
than 2 Hz and lower than 55 Hz.
Supports
Nuxeo Studio UI does not cause screen

flicker with a frequency greater than 2 Hz
and lower than 55 Hz.
(k) A text-only page, with equivalent

information or functionality, shall be provided
to make a web site comply with the
provisions of this part, when compliance
cannot be accomplished in any other way.
The content of the text-only page shall be
updated whenever the primary page
changes.
Not applicable
Accessibility provisions in Nuxeo Studio can

be provided without requiring a separate
text-only version.
(l) When pages utilize scripting languages to

display content, or to create interface
elements, the information provided by the
script shall be identified with functional text
that can be read by Assistive Technology.
(m) When a web page requires that an

applet, plug-in or other application be present
on the client system to interpret page
content, the page must provide a link to a
plug-in or applet that complies with
1194.21(a) through (l).
Not applicable
(n) When electronic forms are designed to be

completed on-line, the form shall allow
people using Assistive Technology to access
the information, field elements, and
functionality required for completion and
submission of the form, including all
directions and cues.
(o) A method shall be provided that permits

users to skip repetitive navigation links.
(p) When a timed response is required, the

user shall be alerted and given sufficient time
to indicate more time is required.
Supports
Nuxeo Studio core functionality does not

require that an applet, plug-in or other
application be present.
Nuxeo Studio does not require a timed

response as part of its core functionality.
Section 1194.31 Functional Performance Criteria

132

Criteria
Supporting Features
Remarks
(a) At least one mode of operation and

information retrieval that does not require
user vision shall be provided, or support for
Assistive Technology used by people who
are blind or visually impaired shall be
provided.
Most of Nuxeo Studio's core functionality is

keyboard accessible. Setting hidden tabs
(Document Type), some buttons
(b) At least one mode of operation and

visual acuity greater than 20/70 shall be
provided in audio and enlarged print output
working together or independently, or
support for Assistive Technology used by
people who are visually impaired shall be
provided.
Supports
Nuxeo Studio supports the use of screen

magnifiers.
(c) At least one mode of operation and

user hearing shall be provided, or support for
Assistive Technology used by people who
are deaf or hard of hearing shall be provided
Supports
Nuxeo Studio does not require user hearing.
(d) Where audio information is important for

the use of a product, at least one mode of
operation and information retrieval shall be
provided in an enhanced auditory fashion, or
support forassistive hearing devices shall be
provided.
Supports
Nuxeo Studio does not require user hearing.
(e) At least one mode of operation and

user speech shall be provided, or support for
Assistive Technology used by people with
disabilities shall be provided.
Supports
Nuxeo Studio does not require user speech.
(f) At least one mode of operation and

fine motor control or simultaneous actions
and that is operable with limited reach and
strength shall be provided.
Most of the parts of Nuxeo Studio that cannot

be operated using the keyboard alone have
large target areas that would not cause
problems for people with fine motor control or
limited reach and strength.
Section 1194.41 Information, documentation, and support.

Criteria
Supporting Features
Remarks
(a) Product support documentation provided

to end-users shall be made available in
alternate formats upon request, at no
additional charge.
Supports
Online help is available for Nuxeo Studio
(b) End-users shall have access to a

description of the accessibility and
compatibility features of products in alternate
formats or alternate methods upon request,
at no additional charge.
Online help is available for Nuxeo Studio
(c) Support services for products shall

accommodate the communication needs of
end-users with disabilities.
Nuxeo Studio Online Documentation is

compatible with screen-reader technology.
However, only electronic versions of all
product support documentation are available.

133

134

Nuxeo Studio Documentation

Uploaded by

Copyright:

Available Formats

Nuxeo Studio Documentation

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Nuxeo Studio Documentation

Uploaded by

Copyright:

Available Formats

Studio Documentation

1.4.2 Installing the Studio JAR Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Studio Documentation Center