Thalia Business Layer Design Specifications
v. 1.1

ContentsDomain.1
Public Domain.3
Users.3
Libraries.6
Items.6
Authorizations.7
Categories.9
Maps (Albums and Slideshows).9
Tagging.11
Thalia Set up.12

Domain

Thalia is a centralized image storage and management service and it is hosted on a central server (or a cluster of servers). However, we would like to provide our users their own unique virtual domains. Each domain will have its own URL, eg. hst.thalia.mit.edu for HST users , and ap.thalia.mit.edu for Architecture and Planning users. Domains are also completely independent of each other. Each domain will have its own users, own public library, and own user spaces.
We have established a wildcard dns record to the IME server or virtual server. For example, *.thalia.mit.edu points to the thalia.mit.edu server in DNS. We are using Apache's mod_rewrite module to accept the URLs to existing domains and reject the urls that points to non-existing domains. For examples, if we configure two domains HST and AP. Request to those two domains will be forwarded to their URLs and all the other requests will be rewritten to the main server thalia.mit.edu. An error will be returned telling the user "Domain not recognized". In thalia1.0, we will have a public domain. If a user points to a non-existing domain, he/she will be bounced to the public domain.
Alfresco has a store/workspace concept which can be mapped neatly to our domain concept. A repository consists of one or more workspaces, each of which contains its own tree of nodes. Alfresco supports multiple workspaces. Alfresco's default store/workspace is "SpacesStore". We will create stores for each of our domains.
We have an utility called BuildThaliaDomain.jar which will build new domains. Before starting the thalia-ime, run "java -classpath ./lib -jar BuildThaliaDomain.jar [DOMAIN NAME]" to build the new domains. Make sure the alfresco repository is pointing at the correct server.
Any servlet in our system will first retrieve the server name from the request and it can be parsed to get the domain name. Then we will check to see if the domain exists or not. If not, an error will be returned.
The domain names are case-insensitive and is represented as all upper-case in our system. We don't have any domain related APIs because we believe that the domain concept should be completely transparent to the users.
In the web.xml file, the parameter serverComponents is related to domain definition. It specifies how many parts a valid domain(sever) URL consists. The domain name is always the first part. If serverComponents is set to 4, then the URL thalia.mit.edu is a invalid domain url. The URL hst.thalia.mit.edu is valid and hst is parsed as the domain name.
The following is the basic domain structure. Everybody has READ permission for the domain root. users_home is where users home spaces reside. If a new user jsmith is created, the system will create a jsmith-space under users-home and a jsmith's library under jsmith-space. Users' home space will not inherit permission from its parent and the only permission will be all control for the specified user. libraries_home is where public library and team libraries reside. Collections_home and slideshows_home are for collections and slideshows. Users in the domain will have permission to add children in libraries_home, collections_home, and slideshows_home, so the users can create new libraries, collections, and slideshows. However, the children will not inherit these permissions. The initial permission for the children will only be all control for the creator. The creator can create other permissions via sharing.

Public Domain

Public Domain is designed to support users who are interested in Thalia on a personal/academic level. Users can access the public domain via https://mv-ezproxy-com.ezproxyberklee.flo.org or can be directed to this url if the user doesn't specify a domain or specified a domain that doesn't exist.

If the user is not a registered user in the system, he/she will be prompted to either self-register or browse as guest. If the user is using http to access the public domain, he/she will always be treated as a guest. During self-registration, the user can enter first name, last name, department and email address. The isadmin field should be taken out from the UI. The user id field is filled with the id specified by the certificate and the user should not be able to edit it. The IME will modify the user HTTP POST api to allow user to self-reg when in the public domain. .

The manage user option should still be available from the UI to give the user a way to edit his/her profile. The IME will change user HTTP PUT api to allow the user to modify his or her info in the public domain. The IME will change user HTTP DELETE api to allow the user to delete his or her own account. The registered user in the public domain will be able to get a list of all users.

The user will not be able to do metadata mapping or categorization. The user will be able to use tagging.

In departmental domains, we show the users all the libraries, albums, and slideshow they can see. In the public domain, this might be annoying to the users if they can see lots of libraries. We should probably change all our library, map, and item apis to retrieve the user's own libraries, maps, slideshows, vs. all the visible one. The UI will need to change to make the users find their own things easier. Flickr has three picture categories: your photos, photos from your contacts, and everybody's photos. We probably will not implement contacts, so we should have only two categories: your photos and other photos.

Bandwidth limit. Flickr has an allowance of 100MB each calendar month. It is a bandwidth limit, and not an amount of space that you have on flickr. This allowance is set to 0 at midnight on the first of each calendar month. The user should be able to see the limit.
Do we need the public library?
Should we allow the users to create libraries other than the personal one? If we want to give the users an url to their images, they need to put those images in a global downloadable library and the url http://mv.ezproxy.com.ezproxyberklee.flo.org/item/xxxx/download will work. We probably don't want the users to create libraries freely because they might intentionally create zillions of libraries and bring down the system. We can either limit the numbers of libraries they can create, or give them two libraries. One is the personal library and they can set permissions. The other is the personal public library which is global readable and downloadable.
In a departmental domain, people should be able to freely share their pictures. However, in the public domain, I might not want certain people share their pictures with me. We might want to implement some kind of blocking mechanism. If user A wants to block user B, user B will not be able to share pictures with user A and user A will be removed from all user B's permissions. User B will also be removed from user A's permissions. The user can see a list of users they are currently blocking and can also choose to unblock them (however, their previous rights are not restored).
We probably need a way to disable a user if the user is behaving inappropriately or have offensive material in his/her space. If a user is disabled, he/she can't login. All accesses on his/her images are removed. Only admin users can access his/her account to review the materials.

Users

We have three types of users: a super user, a domain admin user, and a domain user. A super user is a user that has super power across domains. He/She can do anything in any domain including creating the domain admin users. A domain admin user is a user that has super power in the specific domain. He/She can do anything in that domain including creating, modifying and deleting domain users. Domain admin will need to login specifically as a domain admin (via a button on the UI) to fully achieve domain admin privilege. Otherwise he or she will only do things he or she have explicit rights to do. For example, if user A is a domain admin, but he doesn't have explicit rights to see library1. When user A login, he will not see library 1. However, if he logs in specifically as domain admin. He can see all libraries in the system including library1. A domain user is a regular user in the domain. He/She can write to the public library and also has all control to his/her own user space including his own personal library. He/she can also create libraries, collections, and slideshows. He has all control over the objects of his creation. A domain user can share his/her library and collections with other users. This will be discussed in detail in the authorization section.
We identify a user using both the user's X509 certificate and the domain the user is accessing. If the user jsmith is accessing hst.thalia.mit.edu and ap.thalia.mit.edu, he is treating as two different users. We achieve this by appending the domain prefix in front the user name, so jsmith is hst-jsmith in the HST domain and ap-jsmith in the AP domain. The two users have different rights, different spaces in those two domains and are treated as two completely different users. Again this is transparent to the users.
We create our users directly in Alfresco and use Alfresco's user and person model to store our user attributes. We also modified alfresco's contentModel.xml to extend to person model to store the isAdmin attribute. (Don't forget to replace the contentModel.xml file with our own). isAdmin is the attribute to indicate if somebody is a domain admin or not. We also use a mapping file to store the superusers. The mapping file is defined in web.xml as parameter userConfigFile and is of xml format. It stores the super admins' names. name is the user name without the domain prefix and this is always the name the user will seea:

<user-list>
<user><name>dongq</name>
<domain>ADMIN</domain>
<isAdmin>true</isAdmin>
</user>
</user-list>

This file shows that user dongq is a super user. Everytime we need to change the super user info we need to restart the server because this info is read into the memory at start up and never changes during the life time of the service.
When a domain is first created, the super user will log into the new domain. The super user can register himself/herself in any domain via resttest.jsp. Then the super user can create other domain admins. Domain admins can create other domain admins and users.
When a user accesses a domain URL, if no certificates is presented or if the user is not a valid domain user, the user will be treated as guests.
When a new user is created in the domain, we first create the user's home space in user-spaces folder with the user's default library before creating the user in the system. The new user has admin control to his/her home space and admin control of the personal library. The new user will also have write control to the public library.
User names are case-insensitive and are represented in the system as all lower-case letters.
Domain users have to be managed through the domain URL. The domain tag in the xml file when registering or updating a user is ignored. The domain info is always derived from the url.
In the web.xml file, there are a few user related parameters: alfrescoAdmin, alfrescoAdminPwd, alfrescoUserPwd. alfrescoAdmin and alfrescoAdminPwd are admin user and password for Alfresco. If a super user and domain admin are trying to do administrative tasks in alfresco, like creating and deleting users, this user name and password will be used to proxy for the actual user. alfrescoUserPwd is the secret password for all users. All users will be created in Alfresco with this password. We use the actual user name and this password to log into Alfresco and Alfresco takes care of all the permissions and we don't have to implement our own authorization. Please be careful when you change the alfrescoUserPwd value. All the existing Thalia users in Alfresco will need to have their password updated also.
Also Alfresco's web service API does not support guest login and thalia needs to support guest users. A user is created in Alfresco manually (via the Alfresco web client) and since that user does not have any permission in any of the domain, we use that user as our guest user. The user name and password are stored in web.xml as alfrescoGuest and alfrescoGuestPwd.
Users have the following fields: name, isAdmin, firstname, lastname, emailaddress, organization (default to MIT) and the xml text for a full user object:          <user>
         <name>jsmith</name>
     <firstname>John</firstname>
     <lastname>Smith</lastname>
     <emailaddress>jsmith@mit.edu</emailaddress>
        <organization>MIT</organization>
     <isAdmin>false</isAdmin>
     </user>

The alfresco user object does not have a field which we can use to indicate if a user is domain admin or not. We extended the user object to add a isAdmin field.

edit contentModel.xml in alfresco's tomcat\webapps\alfresco\WEB-INF\classes\alfresco\model directory

find <type name="cm:person"> block in the file
put <property name="cm:isAdmin">
    <type>d:text</type>
    </property>
      Before the </properties> line

There are two sets of APIs for the user objects. One is users, which will get all users in the domain via its GET method. The other is user. Its GET method will retrieve a user, POST method will create a user, PUT method will update a user and DELETE method will delete a user. When a user is deleted, his/her home space remains intact. Next time the same user is created, he/she will have the same home space.

Libraries

Thalia uses its own custom model for library, collection, slideshow, items. The custom model is defined in thaliaModel.xml and is referenced by thalia-model-context.xml. Don't forget to drop those two files in Aflresco's extension directory.
Libraries are repositories for images. There are three types of libraries: public library, personal library, and team libraries.
Every domain will have a public library under libraries_home. It is created automatically when the domain is first established. Everybody has read permission to this library and domain users have write permission to the library. Public library can not be deleted. Public library properties can not be modified.
Personal library resides in the user's home space and is automatically created when a new user is registered. Only that user has full-control to his/her personal library. The user can give other users read, download, write, or admin rights to his/her personal library. Personal library can not be deleted. Even when a user is deleted, his/her personal space still remains.
Libraries has two fields title and description, along with some auditing fields: createdBy, createdDate, lastModifiedDate, modifiedBy. The xml text for a library looks like:        <library>
      <id>fe215db6-ec5b-11db-b809-d59de43b7676</id>
      <title>dongq's Library</title>
      <description>dongq's Personal Library</description>
      <createdBy>dongq</createdBy>
     <createDate>2007-04-16T16:49:38.765-04:00</createDate>
     <modifiedBy>dongq</modifiedBy>
     <modifiedDate>2007-04-16T16:49:38.765-04:00</modifiedDate>
     </library>

There are two sets of APIs for the library objects. One is libraries, which will get all libraries in the domain the current user has rights to view via its GET method. If you append an "all" at the url, it will retrieve all the items in the libraries also. The other is library. Its GET method will retrieve a library, POST method will create a library, PUT method will update a library and DELETE method will delete a library.

Items

Items are contents under libraries. Items don't have their own permissions. They always inherit permissions from its parent library.
Items contain Dublin-core metadata: title,identifier, description, creator, date, format, language, rights, publisher, contributor, source, coverage, relation, subject, type. If the item is an image file, we also create a large, a medium, and a thumbnail jpeg images based on the master image. Therefore it will contain info about those three images. It also has some auditing fields: createdBy, createdDate, lastModifiedDate, modifiedBy. The xml text for a full item looks like:<item>
<libraryid>8bd219f0-f271-11db-b5bc-05f275694451</libraryid>
<id>fddb7233-ec8e-11db-b809-d59de43b7676</id>
      <title>flowers</title>
    <description>Spring flowers</description>
    <createdBy>dongq</createdBy>
    <createDate>2007-04-16T22:54:42.640-04:00</createDate>
<modifiedBy>dongq</modifiedBy>
   <modifiedDate>2007-04-16T22:54:44.093-04:00</modifiedDate>
   <contributor>Jane Smith</contributor>
   <creator>John Smith</creator>
   <date>3-3-2006</date>
<format>jpeg</format>
   <language>English</language>
   <publisher>none</publisher>
   <rights>unspecified</rights>
   <source>personal album</source>
   <type>none</type>
       <mimeType>image/jpeg</mimeType>
       <size>615466</size>
   <thumbnail>*http://localhost:8180/alfresco/guestDownload/direct/workspace/AP/fea61542-ec8e-11db-b809-d59de43b7676/thumbnail*</thumbnail>
   <medium>*http://localhost:8180/alfresco/guestDownload/direct/workspace/AP/fead4136-ec8e-11db-b809-d59de43b7676/medium*</medium>
    <large>*http://localhost:8180/alfresco/guestDownload/direct/workspace/AP/feb46d29-ec8e-11db-b809-d59de43b7676/large*</large>
</item>

To enhance performance, we cache the ids of thumbnail, medium and large child nodes as properties on the item node. We also cache the mimetype and size information of the master image.
We use the file extension (converted to lower case) to determine a file's mime type. The java library javax.activation.MimetypesFileTypeMap is used. In addition to the default mime types, additional mime types are defined in mime.types files in WEB-INF.
There are two sets of APIs for the item objects. One is items, which will get all items in the given library via its GET method. The other is item. Its GET method will retrieve an item, POST method will upload and create an item, PUT method will update an item and DELETE method will delete an item.

Authorizations

The following are Alfresco permissions:

ReadPropertiesReadChildren
WritePropertiesReadContent
WriteContent

ExecuteContent DeleteNode
DeleteChildren
CreateChildren
LinkChildren
DeleteAssociations
ReadAssociations
CreateAssociations
ReadPermissions
ChangePermissions

It also has permission groups:

Read: includes ReadProperties, ReadChildren, ReadContent

Write: includes WriteProperties, WriteContent

AddChildren: includes CreateChildren and LinkChildren

Delete: includes DeleteNode and DeleteChildren

FullControl:
Mapping between Thalia permissions and Alfresco permissions:

read - ReadProperties + ReadChildren + ReadContent

download --- ReadProperties + ReadChildren + ReadContent + ExecuteContent

write ---- AddChildren + Delete + Write + Read + ExecuteContent

admin --- FullControl
This model has an "ugly" workaround for an Alfresco bug. The read permission should not contain ReadContent. The read permission only gives people rights to see the item and read its metadata. It doesn't give them to write to view the master image. However, Alfresco will not be able to search on that item if we don't have the ReadContent bit. So the read permission is actually the same as the download permission. To distinguish between the two, we add a useless ExecuteContent to download and control the download permission in the IME level instead of letting Alfresco handle it.
Here are the permissions set by the thalia system:

At the domain root level, we grant read permission to all

Libraries-home, collections-home, and slideshow-home grants AddChildren to all the users so the users can create things under them

However, when a library, collection, or slideshow is created, it doesn't inherit permission from its parent folder. It only grants ALL permission to the user who creates it. Even the public library and personal libraries don't inherit permission from their parent folders, so querying permissions will be less complicated.
Thalia modifies the Alfresco's permissionsDefinitions.xml file to add Thalia related permissions. Don't forget to replace Alfresco's permissionsDefinitions.xml with our own.
The xml text for an authorization is:

Maps (Albums and Slideshows)

We use display maps to express albums (was named collections) slideshows and saved search. Libraries are for storing images. Albums and slideshows are for organizing and presenting images. Users can organize their images and put them into different albums and slideshows for different purposes. Albums and slideshows don't store the physical images, but the links to images.
Maps are very similar to library and have the same fields title and description, along with the same auditing fields: createdBy, createdDate, lastModifiedDate, modifiedBy. Maps have one additional field: type. Type can be one of the three values: collection, slideshow or savedsearch. Here is the xml representation of a collection map:<displaymap>
                        <type>COLLECTION</type>
                        <id>941d92ea-fa08-11db-bb62-4745336857f3</id>
                        <title>test map</title>
                        <createdBy>dongq</createdBy>
                        <createDate>05-04-2007 03:50 PM</createDate>
                        <modifiedBy>dongq</modifiedBy>
                        <modifiedDate>>05-04-2007 03:54 PM</modifiedDate>
   </displaymap>

Maps have the same permission model as libraries also. However, instead of containing images using child association, the maps contain an xml document which expresses the map content. The IME doesn't parse the content. It only saves and retrieves the content for the UI. Here is an example of a map content:       <item-list>
<item>
                        <id>33081f79-17d7-11dc-b94c-6de5bdf91ac0</id>
                        <title>bellasam4.JPG</title>
                        <createdBy>dongq</createdBy>
                        <createDate>06-11-2007 00:49 AM</createDate>
                        <modifiedBy>dongq</modifiedBy>
                        <modifiedDate>06-11-2007 00:49 AM</modifiedDate>
                        <mimeType>image/jpeg</mimeType>
                        <size>74931</size>
                        <thumbnail>http://mv.ezproxy.com.ezproxyberklee.flo.org/alfresco/guestDownload/direct/workspace/AP/337a6958-17d7-11dc-b94c-6de5bdf91ac0/thumbnail</thumbnail>
                        <medium>http://mv.ezproxy.com.ezproxyberklee.flo.org/alfresco/guestDownload/direct/workspace/AP/33e49ceb-17d7-11dc-b94c-6de5bdf91ac0/medium</medium>
                        <large>http://mv.ezproxy.com.ezproxyberklee.flo.org/alfresco/guestDownload/direct/workspace/AP/344c115d-17d7-11dc-b94c-6de5bdf91ac0/large</large>
   </item>
<item>
                        <id>c19fb93c-17d7-11dc-b94c-6de5bdf91ac0</id>
                        <title>bella4.jpg</title>
                        <createdBy>dongq</createdBy>
                        <createDate>06-11-2007 00:53 AM</createDate>
                        <modifiedBy>dongq</modifiedBy>
                        <modifiedDate>06-11-2007 00:53 AM</modifiedDate>
                        <mimeType>image/jpeg</mimeType>
                        <size>388546</size>
                        <thumbnail>http://mv.ezproxy.com.ezproxyberklee.flo.org/alfresco/guestDownload/direct/workspace/AP/c21bee2b-17d7-11dc-b94c-6de5bdf91ac0/thumbnail</thumbnail>
                        <medium>http://mv.ezproxy.com.ezproxyberklee.flo.org/alfresco/guestDownload/direct/workspace/AP/c28de9ed-17d7-11dc-b94c-6de5bdf91ac0/medium</medium>
                        <large>http://mv.ezproxy.com.ezproxyberklee.flo.org/alfresco/guestDownload/direct/workspace/AP/c322fe10-17d7-11dc-b94c-6de5bdf91ac0/large</large>
</item>
        <count>2</count>
</item-list>

There are two sets of APIs for maps. One is maps, which will get all maps of a certain type via its GET method. The other is map. Its GET method will retrieve a map or its content, POST method will create a map, PUT method will update a map and its content. DELETE method will delete a map. If the user deletes an image from a library, and the image has a link in one more more map objects. The link is not deleted because we believe it is the map owner's responsibility to clean up the links.

Tagging

Tagging is a keyword that the users can assign or associate with the items for purpose of classification and search. We used alfresco's category service in our limited release to implement tagging. However, the users are more used to Flickr style tagging, which is simple, flat, and user definable.
In Thalia 1.0 we start to design a new tagging method based on the users' requirement. We will use the old category system as a way to extend metadata or do admin-controlled categorization.
We want to allow the users to do the following regarding to tagging

Add tags to an item
Modify tags applied to an item
Retrieve all the tags applied to an item
Search by one or multiple tag
Browse for all the tags
Rename a tag
Delete a tag
Alfresco doesn't provide support for tagging yet, so we have to come up with our own. We have two designs. The first one is to put the list of tags directly onto the item object. The second one is to create a tag object and link it to items by association. Neither method seems ideal, so we used the first one because it is simpler.
We created a new aspect called "thalia:tagging" with one multi-value property "thalia:tags". It is defined as:

<aspect name="thalia:tagging">
<title>tagging</title>
<properties>
         <property name="thalia:tags">
                     <type>d:text</type>
             <mandatory>false</mandatory>
                     <multiple>true</multiple>
      </property>
</properties>
</aspect>
This aspect is applied to the thalia:item object. This method provides function 1-4 very well, but function 5-7 very poorly. As a matter of fact, because the performance for function 5-7 is so bad, we didn't bother implement function 5-7. No new servlet is necessary because we only added a new property to the item object. Please refer to the item servlet for add, modify, and retrieve tag. Please refer to the items servlet for searching on tags. Alfresco is also planning on provide tagging support in the future. We still need more info from them as for the timeline and features. We don't know if we will use our design until we get more info from Alfresco.

Thalia Set up

Things to do when setting up a new cluster:

A. get subdomain for F5

B. get a Wild card certs for F5

C. Don't forget install the alfresco license (in shared/classes/alfresco/extension/license)

D. have ops set up F5Things to do when setting up thalia:

Install ImageMagic on the server that will be running the Thalia UI and IME.

1. go to www.imagemagick.org and get the source distribution:ImageMagick-6.3.2-9.tar.gz

2. unzip and unstar ImageMagick-6.3.2.tar.gz and cd to ImageMagic-6.3.2 directory

3. by default, the base installation directory is /usr/local. binary files go in /usr/local/bin and

library files go in /usr/local/lib. If you want to specify an installation prefix other than /usr/local, you

can do it by specify the --prefix=PATH in step 4

4. ./configure (specify the path here if necessary. Please note that the binary files should be in the system path)

5. make install

6. for more info, please refer to the Install-unix.txt in the package

7. after installation, you should be able to type "convert" command and get the help page.

B. put thaliausers.xml in /home/thalia/conf. This file should contain info about system super users. The file should have the format:

<user-list>
<user><name>colodzin</name>
<domain>ADMIN</domain>
<isAdmin>true</isAdmin>
</user>
<user><name>amb</name>
<domain>ADMIN</domain>
<isAdmin>true</isAdmin>
</user>
<user><name>dongq</name>
<domain>ADMIN</domain>
<isAdmin>true</isAdmin>
</user>
<user><name>iannuzzo</name>
<domain>ADMIN</domain>
<isAdmin>true</isAdmin>
</user>
<user><name>dracus</name>
<domain>ADMIN</domain>
<isAdmin>true</isAdmin>
</user>
</user-list>
The system super users can self-register in any domain by going to https://\[domain\].thalia.mit.edu/resttest.jsp and click on the super user self reg button.

C. Customize the Alfresco Server:

1. Stop Alfresco server

2. put our custom model (includes thaliaModel.xml and thalia-model-context.mxl) in the extension folder

3. put our custom model (includes thaliaModel.xml and thalia-model-context.mxl) in the extension folder

4.       edit Alfresco's permissionsDefinitions.xml. Put the following definition within the <permissionSet type="sys:base" expose="all"> block right after <permissionGroup name="Execute" allowFullControl="false" expose="false"> <includePermissionGroup type="sys:base" permissionGroup="ExecuteContent" /> </permissionGroup>:The definition is the following:
<permissionGroup name="ThaliaWrite" allowFullControl="false" expose="false">
        <includePermissionGroup type="sys:base" permissionGroup="Write"/>
   <includePermissionGroup type="sys:base" permissionGroup="Read"/>
   <includePermissionGroup type="sys:base" permissionGroup="AddChildren"/>
   <includePermissionGroup type="sys:base" permissionGroup="Delete"/>
   <includePermissionGroup type="sys:base" permissionGroup="ExecuteContent"/>
      </permissionGroup>

      <permissionGroup name="ThaliaRead" allowFullControl="false" expose="false">
           <includePermissionGroup type="sys:base" permissionGroup="ReadProperties"/>
           <includePermissionGroup type="sys:base" permissionGroup="ReadChildren"/>
      <includePermissionGroup type="sys:base" permissionGroup="ReadContent"/>
      </permissionGroup>
      <permissionGroup name="ThaliaDownload" allowFullControl="false" expose="false">
           <includePermissionGroup type="sys:base" permissionGroup="ReadProperties"/>
           <includePermissionGroup type="sys:base" permissionGroup="ReadChildren"/>
           <includePermissionGroup type="sys:base" permissionGroup="ReadContent"/>
      <includePermissionGroup type="sys:base" permissionGroup="ExecuteContent"/>
      </permissionGroup>

5. edit contentModel.xml:

find <type name="cm:person"> block in the file
put <property name="cm:isAdmin">
    <type>d:text</type>
    </property>
      Before the </properties> line

6. add the admin account specified by alfrescoAdmin in web.xml in Alfresco's authority-services-context.xml file.

7. change the default admin account password to the same as thaliaAdmin. Don't use the default admin password.

8. start Alfresco server

9. create the user specified by alfrescoAdmin and alfrescoAdminPwd in web.xml. This is our admin user.

10. create the user specified by alfrescoGuest and alfrescoGuestPwd in web.xml. This is our guest user (because the web service api doesn't support guest login).

11. Run the BuildThaliaDomain.jar library to create the domains. The file is under /home/qing/dist on isda-thalia1, 2, and 5. The syntax is $JAVA_HOME/bin/java -classpath ./lib -jar BuildThaliaDomain.jar [alfresco repository location] [DOMAIN NAME]
For example, to create the TEST domain on isda-thalia6 do:
$JAVA_HOME/bin/java -classpath ./lib -jar BuildThaliaDomain.jar http://mv.ezproxy.com.ezproxyberklee.flo.org/alfresco TEST
Please be aware that the jar file was compiled using java6, so if the JAVA_HOME points to a location older than java6, it will not work.

You can run the jar file from any server to manage any domain in any alfresco repository. You just need to specify the alfresco repository address as the first argument.

D. create directory structure:

/home/thalia/conf

/home/thalia/log

/home/thalia/bulkimage

/home/thalia/tmp
E. upload the thalia war file onto the UI and IME server.

F. set the domain specific metadata mapping

F: run cronjob to clean up the log, tmp, and bulkimage directories.

Child pages

Thalia Business Layer Design Sepcifications