litvinovg/vivo
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

NIHVIVO-2936 Aggregated the sections about "change" to be located together. Need to still clean up some html, but wanted to commit this in case anyone wanted to make edits and this was a big change to the layout.

Browse source
This commit is contained in:
ejc12 2011-07-18 22:59:22 +00:00
parent bd4e43af11
commit 544cbcdcbd
1 changed files with 1156 additions and 1066 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

776
doc/upgrade-1.3.html
View file

@ -36,15 +36,14 @@
If you need to do a fresh install, please consult the VIVO Release
1 v1.3 Installation Guide found on <a href="http://vivoweb.org/support">vivoweb.org</a>
or the install.html file located in the <code>doc</code>
directory of
the VIVO source code distribution. The installation document also has a
directory of the VIVO source code distribution. The installation document also has a
list of the required software and versions (there are no new hardware
or software requirements for V1.3).
</p>
<h3 id="announcement">Release Announcement for V1.3</h3>
V<!-- Release Announcement -->IVO Release 1.3 incorporates changes to
the search indexing, user
accounts, menu management, ontology, and visualizations.
the search indexing, user accounts, menu management, ontology, and
visualizations.
<br>
<h4>Search</h4>
VIVO 1.3 will feature notable improvements to the local search,
@ -140,53 +139,46 @@
<li>
<a href="#preparation">Before Performing the Upgrade</a>
</li>
<li>
<a href="#changes">Noteworthy Changes</a>
<br>
</li>
<ol class="roman2">
<li>
<a href="#triple_store">Triple Store</a>
</li>
<li>
<a href="#theme">Theme Changes</a>
<a href="#theme">Theme</a>
</li>
<li>
<a href="#template">Template</a>
</li>
<li>
<a href="#listview">List View</a>
</li>
<li>
<a href="#authorization">Authorization</a>
</li>
</ol>
<li>
<a href="#upgrade_process">The Upgrade Process</a>
</li>
<li>
<a href="#ontology">Ontology Changes</a>
<ol class="roman2">
<a href="upgrade-1.3.html#ontology">Ontology</a>
<ol class="roman3">
<li>
<a href="#verify_ontology_upgrade">Verify Ontology upgrade
process</a>
<a href="upgrade-1.3.html#verify_ontology_upgrade">Verify
Ontology upgrade process</a>
</li>
<li>
<a href="#ontology_knowledge_base">Ontology knowledge base
<a href="upgrade-1.3.html#ontology_knowledge_base">Ontology
knowledge
base
manual review</a>
</li>
</ol>
</li>
<li>
<a href="#template">Template Changes</a>
</li>
<li>
<a href="#listview">List View Changes</a>
</li>
<li>
<a href="#authorization">Authorization Changes</a>
<ol class="roman2">
<li>
<a href="#accounts_created">User Accounts are created for
externally authenticated users</a>
</li>
<li>
<a href="#email_on_accounts">E-mail address becomes an
important part of User Accounts</a>
</li>
<li>
<a href="#root_account">Each VIVO installation will have a
'root' account</a>
</li>
</ol>
</li>
</ol>
</toc>
<h3 id="preparation">I. Before Performing the Upgrade</h3>
<p>
Please ensure that backups are created of the:
@ -203,14 +195,16 @@
</li>
</ul>
<p>
The upgrade process is similar to the original install process with
The upgrade process is similar to the original install process
with
the following EXCEPTIONS:
</p>
<ul>
<li>
If you are still in RDB mode, it is required that you move your
triple store to SDB while still at V1.2
(see <a href="#triple_store">Triple Store</a>
If you are still in RDB mode, it is required that you move
your
triple store to SDB while still at V1.2 (see <a href="#triple_store">Triple
Store</a>
info below).&nbsp;
<br>
</li>
@ -226,11 +220,14 @@
It is not necessary to add RDF data.
</li>
<li>
First-time login of the administrator account after the upgrade
First-time login of the administrator account after the
upgrade
process is complete will use the password previously set, NOT the
default password used on the first login after the initial
installation. With V1.3 there is also a new root user. Please see the
section on <a href="#authorization">Authorization changes</a> for more information.
section on <a href="#authorization">Authorization changes</a>
for more
information.
</li>
<li>
The first time Apache Tomcat starts up after the upgrade, it
@ -239,7 +236,11 @@
below for more information.
</li>
</ul>
<h3 id="triple_store">II. Triple Store</h3>
<h3 id="changes">II. Noteworthy Changes
</h3>
<h4 id="triple_store">i. Triple store changes
<br>
</h4>
<p>
VIVO 1.3 now requires you to use Jena's SPARQL database (SDB) for
the triple store technology.&nbsp; Jena's legacy relational database
@ -252,8 +253,8 @@
queries are issued directly against the underlying database. This
allows VIVO installations to display data from large RDF models while
requiring only a small amount of server memory to run the application.
There is a tradeoff in response time: pages may take slightly longer
to load in SDB mode, and performance will depend on the configuration
There is a tradeoff in response time: pages may take slightly longer to
load in SDB mode, and performance will depend on the configuration
parameters of the database server. Additionally, advanced OWL reasoning
(not enabled by default in either mode) is not possible in SDB mode.
With SDB, only the default set of inferences (inferred rdf:type
@ -267,8 +268,7 @@
process in the background while the RDB system is running. This will
reduce the delay in initial startup after the application is redeployed
with deploy.properties set for SDB. <span style="font-weight: bold;">Note
that
it is important not to edit any data anywhere in the application
that it is important not to edit any data anywhere in the application
while this background conversion is running</span>.
</p>
<p>
@ -281,7 +281,8 @@
Click the button that appears on this page.
</p>
<p>
During the course of the SDB setup, which may take several hours on
During the course of the SDB setup, which may take several hours
on
a large database, subsequent requests to /sdbsetup will display a
message that the operation is still in progress. When a request for
this page shows a message that the SDB setup has completed
@ -291,22 +292,367 @@
</p>
<p>
</p>
<h3 id="theme">III. Theme Changes</h3>
<h4 id="theme">ii. Theme changes</h4>
<p>
The vivo-basic theme was deprecated with VIVO V1.2 and is not persent in the
V1.3 release as it does not support V1.2 or V1.3 features.
It is highly recommended that you use the wilma theme or modify the
wilma theme for branding and/or to create a custom look and feel. Please see the
<a href="http://sourceforge.net/apps/mediawiki/vivo/index.php?title=Site_Administrator_Guide">Site Aministration Guide</a>
for more information about customizing your theme.
The vivo-basic theme was deprecated with VIVO V1.2 and is no longer
present in the V1.3 release as it does not support V1.2 or V1.3
features. It is highly recommended that you use the wilma theme or
modify the wilma theme for branding or to create a custom look and
feel. Please see the <a href="http://sourceforge.net/apps/mediawiki/vivo/index.php?title=Site_Administrator_Guide">Site Administration Guide</a>
for more information about customizing your
theme.
</p>
<h3 id="upgrade_process">IV. The Upgrade Process</h3>
</toc>
<h4 id="template">iii. Template changes</h4>
<toc>
<ul>
<li>
<p>
The <code>${stylesheets}</code>, <code>${scripts}</code>,
and<code>${headScripts}</code>
<code>add()</code>
methods now take the
full tag as an argument.
This will require a change to all calls to these methods in the
templates. This change allows for specification of attributes such as <code>media</code>
directly in the tag. For example:
</p>
<blockquote>
1.2: <code>${stylesheets.add("/css/individual/individual.css")}</code>
<br>
1.3: <code>${stylesheets.add('&lt;link rel="stylesheet"
href="${urls.base}/css/individual/individual.css" /&gt;')}</code>
</blockquote>
<p>
Note the inclusion of <code>${urls.base}</code>
in the 1.3
example. The <code>add()</code>
method no longer prefixes the context
path to the url, so the full url must be specified in the tag.
</p>
</li>
<li>
The <code>addFromTheme()</code>
methods of the <code>${stylesheets}</code>,<code>${scripts}</code>,
and<code>${headScripts}</code>
objects have been deleted. Substitute as
shown in the preceding example.
</li>
<li>
<code>propertyGroups.getPropertyAndRemoveFromList()</code>
in the individual templates has been deprecated. The replacement method
is<code>propertyGroups.pullProperty()</code>.
There is no change in functionality.
</li>
</ul>
</toc>
<h4 id="listview">v. List view changes</h4>
<toc>
<code>&lt;query-base&gt;</code>
and <code>&lt;query-collated&gt;</code>
have been replaced with a single query <code>&lt;query-select&gt;</code>
that contains tags for fragments to be used only in the collated
version of the query. This and other changes are documented in <code>/vitro/doc/list_view_configuration_guidelines.txt</code>.
<br>
<br>
</toc>
<h4 id="authorization">v. Authorization changes</h4>
<toc>
<p>
In release 1.3, the VIVO authorization system has some extensive
changes. In summary, these are:
</p>
<ul>
<li>
Each user will have a user account, even if the user logs in
by
Shibboleth or some other external authentication system.
</li>
<li>
E-mail is used to notify user's when an account is created for
them, or when an administrator edits their account.
</li>
<li>
A "root" user account exists which has access to all pages and
all data fields. This is a powerful tool that can hold some surprises.
</li>
</ul>
</toc>
<toc>
<h4 style="margin-left: 40px;" id="accounts_created">a. User Accounts
are created for externally
authenticated users</h4>
<dl>
<dd>
<p style="margin-left: 40px;">
With release 1.3, each authenticated
user will have a user
account. If someone logs in using an external authentication system,
and no user account matches their external login credentials, an
account will be created.
</p>
<p style="margin-left: 40px;">
The user will be prompted to enter
information for the
account
being created: first name, last name, and e-mail address.
</p>
</dd>
</dl>
</toc>
<toc>
<h4 style="margin-left: 40px;" id="email_on_accounts">b. E-mail address
becomes an important
part
of User Accounts</h4>
<dl style="margin-left: 40px;">
<dd>
<p>
Prior to release 1.3, each user account was identified by a
Username field. This field was labeled as “E-mail address” on some
pages in VIVO, but no mail was ever sent. In release 1.3, this has
changed, so the e-mail address is fully used, both for identification
and for communication with the user.
</p>
</dd>
</dl>
</toc>
<div style="margin-left: 40px;">
<toc>
<h5 style="margin-left: 40px;">1. User Account data is restructured</h5>
</toc>
</div>
<toc>
<dl style="margin-left: 40px;">
<dd>
<p>
Prior to release 1.3, the Username field (also referred to as
'e-mail address') was used for several purposes:
</p>
<ul>
<li>
Idenfiying the user account.
</li>
<li>
Part of the user’s credentials when logging in (along with
a
password).
</li>
<li>
Connecting the user account to an external authentication
system, like Shibboleth or CUWebAuth.
</li>
<li>
Connecting the user account to a personal Profile page.
</li>
</ul>
<p>
With release 1.3, these functions are handled by two separate
fields called EmailAddress field and ExternalAuthId.
</p>
<ul>
<li>
EmailAddress is used when logging in (along with a
password).
</li>
<li>
EmailAddress is used to send notifications to the user
about
changes to his/her account (see below).
</li>
<li>
The ExternalAuthId is used when logging in using an
external
authentication system.
</li>
<li>
The ExternalAuthId is used to connect the user account to
a
personal Profile page.
<blockquote>
<strong>Note:</strong>
With release 1.3, the
ExternalAuthId can now be matched against either an untyped literal or
a string literal in the Profile page.
</blockquote>
</li>
</ul>
<p>
There are other changes to the internal structure of the user
accounts data, but they are important mostly to the VIVO software
developers, and you are not likely to notice them.
</p>
</dd>
</dl>
</toc>
<div style="margin-left: 40px;">
<toc>
<h5 style="margin-left: 40px;">2. Existing User Accounts are migrated</h5>
</toc>
</div>
<toc>
<dl style="margin-left: 40px;">
<dd>
<p>
If you are upgrading to VIVO release 1.3 from an existing
VIVO
installation, the user accounts in your system will be migrated into
the new data structures. When migrating an account, both the
EmailAddress field and the ExternalAuthId field will be set to the
value of the Username field in the old account. The new account should
behave as the old account did.
</p>
<p>
When creating a new user account, or editing an existing one,
the system requires that your e-mail address be in a valid form, like <code>somebody@somewhere.edu</code>.
You
should
plan
for
this
as
part of your migration to release 1.3
</p>
</dd>
</dl>
</toc>
<div style="margin-left: 40px;">
<toc>
<h5 style="margin-left: 40px;">3. E-mail is incorporated into the
workflow for User Accounts</h5>
</toc>
</div>
<toc>
<dl style="margin-left: 40px;">
<dd>
<p>
With release 1.3, VIVO users receive e-mail notifications
when
an account is created or modified for them or by them.
</p>
<p>
When an administrator creates a user account, the user will
receive an e-mail notification, telling them that the account has been
created, and providing a link to VIVO that will allow them to set a
password on the account.
</p>
<blockquote>
<strong>Note:</strong>
when creating the account,
the
administrator may indicate that it will only be used with an external
authentication system like Shibboleth or CUWebAuth. In this case, the
account will not require a password, and the e-mail notification
message to the user will not provide a password link.
</blockquote>
<p>
When an administrator edits a user account, he may choose to
reset the password. As with a new account, the user will receive
notification with a link to VIVO that will allow them to set a new
password.
</p>
<p>
If a user changes the e-mail address on his account, he will
receive a notification message to that effect.
</p>
<p>
If a user account is auto-created for a user with external
authentication credentials, the user will receive a notification
message.
</p>
</dd>
</dl>
</toc>
<div style="margin-left: 40px;">
<toc>
<h5 style="margin-left: 40px;">4. Disabling e-mail notificiation</h5>
</toc>
</div>
<toc>
<dl style="margin-left: 40px;">
<dd>
<p>
The e-mail notification relies on two configuration
properties:<code>email.smtpHost</code>
and <code>email.replyTo</code>. If either of these properties is
missing or empty, VIVO will not attempt to send e-mail notifications to
users.
</p>
<p>
This can be useful for small or experimental installations of
VIVO, or where e-mail notification is not desired.
</p>
<p>
If e-mail notifications are disabled, an administrator must
set
a password on each new account, since the user will have no way of
setting it. When the user logs in for the first time, VIVO will require
them to change their password to one of their own choosing.
</p>
</dd>
</dl>
<h4 style="margin-left: 40px;" id="root_account">c. Each VIVO
installation will have a 'root'
account.</h4>
<dl>
<dd>
<p style="margin-left: 40px;">
Prior to release 1.3, each VIVO
installation was created with
a
default administrator’s account. In release 1.3, there is no such
account. Instead, each VIVO installation will have a “root” account.
</p>
<p style="margin-left: 40px;">
The email address for the root
account is specified in
deploy.properties, like this:
</p>
<pre style="margin-left: 40px;">rootUser.emailAddress = vivo_root@mydomain.edu</pre>
<div style="margin-left: 40px;">
The password for this account is
automatically set to <code>rootPassword</code>,
but
you
will
be
required
to change the password the first time you log
in.
</div>
<blockquote style="margin-left: 40px;">
<strong>Note:</strong>
the<code>initialAdminUser</code>
is no longer use.
</blockquote>
<p style="margin-left: 40px;">
The root account is not a site
administrator’s account – it
is
more powerful than a site administrator’s acocunt. The root account is
permitted to visit any page in a VIVO application. It is permitted to
see any data property, and to enter data into any field. As such, the
root account can be very useful and rather dangerous. It can also give
you a distorted view of what your VIVO site looks like, since data is
shown which other accounts cannot see.
</p>
<p style="margin-left: 40px;">
The root account is not intended for
routine, every day use.
The best way to use the root account is to create a site
administrator’s account. After that, use the root account only when
necessary.
</p>
</dd>
</dl>
<h3 id="upgrade_process">III. The Upgrade Process</h3>
<p>
1. Download the new distribution file and unpack it into a new
source directory.
</p>
<p>
2. Create a new deploy.properties using the same values as in your
2. Create a new deploy.properties using the same values as in
your
previous installation and set values for the new variables as described
below (vitro.local.solr.url, vitro.local.solr.ipaddress.mask,
vitro.home.directory, email.smptHost, email.replyTo,
@ -316,7 +662,7 @@
<p>
<!-- deploy.properties table from install.html -->
</p>
<table border='1' bordercolor="#CCCCCC" cellspacing="5">
<table border="1" bordercolor="#cccccc" cellspacing="5">
<tbody>
<tr>
<th>
@ -328,7 +674,8 @@
</tr>
<tr>
<td colspan="2">
Default namespace: VIVO installations make their
Default namespace: VIVO installations make
their
RDF resources available for harvest using linked data. Requests for RDF
resource URIs redirect to HTML or RDF representations as specified by
the client. To make this possible, VIVO's default namespace must have a
@ -440,7 +787,8 @@
</tr>
<tr>
<td colspan="2">
Directory where the VIVO application will store
Directory where the VIVO application will
store
the data that it creates. This includes uploaded files (usually images)
and the Solr search index. Be sure this directory exists and is
writable by the user who the Tomcat service is running as.
@ -504,7 +852,8 @@
</tr>
<tr>
<td colspan="2">
Change the username to match the authorized user
Change the username to match the authorized
user
you created in MySQL.
</td>
</tr>
@ -532,7 +881,8 @@
</tr>
<tr>
<td colspan="2">
Specify the Jena triple store technology to use.
Specify the Jena triple store technology to
use.
SDB is Jena's SPARQL database; this setting allows RDF data to scale
beyond the limits of the JVM heap. Set to RDB to use the older Jena RDB
store with in-memory caching.
@ -548,7 +898,8 @@
</tr>
<tr>
<td colspan="2">
Specify the maximum number of active connections
Specify the maximum number of active
connections
in the database connection pool to support the anticipated number of
concurrent page requests. It is not necessary to adjust this value when
using the RDB configuration.
@ -721,7 +1072,8 @@
<strong>Special notes regarding source files</strong>
<ul>
<li>
This process assumes any changes made to the application were
This process assumes any changes made to the application
were
made in the source directory and deployed, and were not made directly
within the Tomcat webapps directory.
</li>
@ -732,7 +1084,8 @@
files and add any changes to them at that time.
</li>
<li>
NIH-funded VIVO implementations will need to apply the Google
NIH-funded VIVO implementations will need to apply the
Google
Analytics Tracking Code (GATC) to <code>googleAnalytics.ftl</code>
in
the theme:<pre>[new_source_directory]/themes/[theme_dir]/templates/googleAnalytics.ftl</pre>
@ -744,7 +1097,9 @@
implementation sites and a copy of your institution's tracking code,
see the <a href="https://confluence.cornell.edu/display/ennsrd/Google+Analytics+for+UI">VIVO
Google
Analytics wiki page</a>.
Analytics
wiki
page</a>.
</li>
<li>
If you had used the <code>vivo/contrib/FLShibboleth</code>
@ -763,12 +1118,14 @@
that modification.
</p>
<p>
5. Stop Apache Tomcat and from your VIVO source directory, run ant by typing: <code>ant all</code>
5. Stop Apache Tomcat and from your VIVO source directory, run
ant
by typing: <code>ant all</code>
</p>
<p>
6. Start Apache Tomcat and log in to VIVO.
</p>
<h3 id="ontology">V. Ontology Changes</h3>
<h3 id="ontology">IV. Ontology Changes</h3>
<h4 id="verify_ontology_upgrade">i. Verify Ontology upgrade process</h4>
<p>
After Apache Tomcat is started, these files should be reviewed to
@ -802,7 +1159,8 @@
<code>ontologies/update/changedData/removedData.n3</code>
</dt>
<dd>
An N3 file containing all the statements that were removed from
An N3 file containing all the statements that were removed
from
the knowledge base.
</dd>
</dl>
@ -811,7 +1169,8 @@
<code>ontologies/update/changedData/addedData.n3</code>
</dt>
<dd>
An N3 file containing all the statements that were added to the
An N3 file containing all the statements that were added to
the
knowledge base.
</dd>
</dl>
@ -835,7 +1194,8 @@
Class or Property renaming
</dt>
<dd>
All references to the class (in the subject or object position)
All references to the class (in the subject or object
position)
will be updated to the new name. References to the property will be
updated to the new name.
</dd>
@ -869,7 +1229,8 @@
Annotation property default values
</dt>
<dd>
If a site has modified the value of a vitro annotation (such as
If a site has modified the value of a vitro annotation (such
as
displayRankAnnot or displayLimitAnnot) so that it is no longer using
the default, then that setting will be left unchanged.
<br>
@ -878,279 +1239,6 @@
new default value will be propagated to the knowledge base.
</dd>
</dl>
<h3 id="template">VI. Template changes</h3>
<ul>
<li>
<p>
The <code>${stylesheets}</code>, <code>${scripts}</code>, and<code>${headScripts}</code>
<code>add()</code>
methods now take
the full tag as an argument. This will require a change to all calls to
these methods in the templates. This change allows for specification of
attributes such as <code>media</code>
directly in the tag. For
example:
</p>
<blockquote>
1.2: <code>${stylesheets.add("/css/individual/individual.css")}</code>
<br>
1.3: <code>${stylesheets.add('&lt;link rel="stylesheet"
href="${urls.base}/css/individual/individual.css" /&gt;')}</code>
</blockquote>
<p>
Note the inclusion of <code>${urls.base}</code>
in the 1.3
example. The <code>add()</code>
method no longer prefixes the context
path to the url, so the full url must be specified in the tag.
</p>
</li>
<li>
The <code>addFromTheme()</code>
methods of the <code>${stylesheets}</code>,<code>${scripts}</code>,
and<code>${headScripts}</code>
objects have been deleted. Substitute as
shown in the preceding example.
</li>
<li>
<code>propertyGroups.getPropertyAndRemoveFromList()</code>
in
the individual templates has been deprecated. The replacement method is<code>propertyGroups.pullProperty()</code>. There is no change in
functionality.
</li>
</ul>
<h3 id="listview">VII. List view changes</h3>
<code>&lt;query-base&gt;</code>
and <code>&lt;query-collated&gt;</code>
have been replaced with a single query <code>&lt;query-select&gt;</code>
that contains tags for fragments to be used only in the collated
version of the query. This and other changes are documented in <code>/vitro/doc/list_view_configuration_guidelines.txt</code>.
<h3 id="authorization">VIII. Authorization changes</h3>
<p>
In release 1.3, the VIVO authorization system has some extensive
changes. In summary, these are:
</p>
<ul>
<li>
Each user will have a user account, even if the user logs in by
Shibboleth or some other external authentication system.
</li>
<li>
E-mail is used to notify user's when an account is created for
them, or when an administrator edits their account.
</li>
<li>
A "root" user account exists which has access to all pages and
all data fields. This is a powerful tool that can hold some surprises.
</li>
</ul>
<h4 id="accounts_created">i. User Accounts are created for externally
authenticated users</h4>
<dl>
<dd>
<p>
With release 1.3, each authenticated user will have a user
account. If someone logs in using an external authentication system,
and no user account matches their external login credentials, an
account will be created.
</p>
<p>
The user will be prompted to enter information for the account
being created: first name, last name, and e-mail address.
</p>
</dd>
</dl>
<h4 id="email_on_accounts">ii. E-mail address becomes an important part
of User Accounts</h4>
<dl>
<dd>
<p>
Prior to release 1.3, each user account was identified by a
Username field. This field was labeled as “E-mail address” on some
pages in VIVO, but no mail was ever sent. In release 1.3, this has
changed, so the e-mail address is fully used, both for identification
and for communication with the user.
</p>
</dd>
</dl>
<h5>a. User Account data is restructured</h5>
<dl>
<dd>
<p>
Prior to release 1.3, the Username field (also referred to as
'e-mail address') was used for several purposes:
</p>
<ul>
<li>
Idenfiying the user account.
</li>
<li>
Part of the user’s credentials when logging in (along with a
password).
</li>
<li>
Connecting the user account to an external authentication
system, like Shibboleth or CUWebAuth.
</li>
<li>
Connecting the user account to a personal Profile page.
</li>
</ul>
<p>
With release 1.3, these functions are handled by two separate
fields called EmailAddress field and ExternalAuthId.
</p>
<ul>
<li>
EmailAddress is used when logging in (along with a
password).
</li>
<li>
EmailAddress is used to send notifications to the user about
changes to his/her account (see below).
</li>
<li>
The ExternalAuthId is used when logging in using an external
authentication system.
</li>
<li>
The ExternalAuthId is used to connect the user account to a
personal Profile page.
<blockquote>
<strong>Note:</strong>
With release 1.3, the
ExternalAuthId can now be matched against either an untyped literal or
a string literal in the Profile page.
</blockquote>
</li>
</ul>
<p>
There are other changes to the internal structure of the user
accounts data, but they are important mostly to the VIVO software
developers, and you are not likely to notice them.
</p>
</dd>
</dl>
<h5>b. Existing User Accounts are migrated</h5>
<dl>
<dd>
<p>
If you are upgrading to VIVO release 1.3 from an existing VIVO
installation, the user accounts in your system will be migrated into
the new data structures. When migrating an account, both the
EmailAddress field and the ExternalAuthId field will be set to the
value of the Username field in the old account. The new account should
behave as the old account did.
</p>
<p>
When creating a new user account, or editing an existing one,
the system requires that your e-mail address be in a valid form, like <code>somebody@somewhere.edu</code>.
You
should plan for this as part of your migration to release 1.3
</p>
</dd>
</dl>
<h5>c. E-mail is incorporated into the workflow for User Accounts</h5>
<dl>
<dd>
<p>
With release 1.3, VIVO users receive e-mail notifications when
an account is created or modified for them or by them.
</p>
<p>
When an administrator creates a user account, the user will
receive an e-mail notification, telling them that the account has been
created, and providing a link to VIVO that will allow them to set a
password on the account.
</p>
<blockquote>
<strong>Note:</strong>
when creating the account, the
administrator may indicate that it will only be used with an external
authentication system like Shibboleth or CUWebAuth. In this case, the
account will not require a password, and the e-mail notification
message to the user will not provide a password link.
</blockquote>
<p>
When an administrator edits a user account, he may choose to
reset the password. As with a new account, the user will receive
notification with a link to VIVO that will allow them to set a new
password.
</p>
<p>
If a user changes the e-mail address on his account, he will
receive a notification message to that effect.
</p>
<p>
If a user account is auto-created for a user with external
authentication credentials, the user will receive a notification
message.
</p>
</dd>
</dl>
<h5>d. Disabling e-mail notificiation</h5>
<dl>
<dd>
<p>
The e-mail notification relies on two configuration properties:<code>email.smtpHost</code>
and <code>email.replyTo</code>. If either of these properties is
missing or empty, VIVO will not attempt to send e-mail notifications to
users.
</p>
<p>
This can be useful for small or experimental installations of
VIVO, or where e-mail notification is not desired.
</p>
<p>
If e-mail notifications are disabled, an administrator must set
a password on each new account, since the user will have no way of
setting it. When the user logs in for the first time, VIVO will require
them to change their password to one of their own choosing.
</p>
</dd>
</dl>
<h4 id="root_account">iii. Each VIVO installation will have a 'root'
account.</h4>
<dl>
<dd>
<p>
Prior to release 1.3, each VIVO installation was created with a
default administrator’s account. In release 1.3, there is no such
account. Instead, each VIVO installation will have a “root” account.
</p>
<p>
The email address for the root account is specified in
deploy.properties, like this:
</p>
<pre>rootUser.emailAddress = vivo_root@mydomain.edu</pre>
The password for this account is automatically set to <code>rootPassword</code>,
but
you will be required to change the password the first time you log
in.
<blockquote>
<strong>Note:</strong>
the <code>initialAdminUser</code>
is no longer use.
</blockquote>
<p>
The root account is not a site administrator’s account – it is
more powerful than a site administrator’s acocunt. The root account is
permitted to visit any page in a VIVO application. It is permitted to
see any data property, and to enter data into any field. As such, the
root account can be very useful and rather dangerous. It can also give
you a distorted view of what your VIVO site looks like, since data is
shown which other accounts cannot see.
</p>
<p>
The root account is not intended for routine, every day use.
The best way to use the root account is to create a site
administrator’s account. After that, use the root account only when
necessary.
</p>
</dd>
</dl>
</div>
<!-- #wrapper-content -->
<div id="footer" role="contentinfo">
<p class="copyright">
@ -1175,5 +1263,7 @@
</div>
</div>
<!-- #footer -->
</toc>
</div>
</body>
</html>