3. Manage Site Settings

1. Site Home Page

1. Site Settings

Link available in the dashboard view of a site. The link itself brings you into
the first tab, the dropdown menu brings you into a particular section of the Site
Settings.





2. Site Settings - General

(star) Note: A change to Site and possibly SiteService is required to allow the setting of Site Owner (site.getCreatedBy()), otherwise this would be 4 hours effort at worst, after talking to Ian we are
going to handle this using some hacking and cheating to avoid thawing kernel

ToDo :

Domain

Description

Work Estimate

Technical

Saving all of the data on the page

32 hours

Data Feed

Data Feed that allows updating a sites Site owner (createdBy), Site name (title), Site description (shortDescription,description), Status (published), Public/Private (pubView) and Default Role (joinerRole)

16 hours (star)

 

 

Total: 32 hours (Incomplete est.)

1. Site Owner

We envision this to be someone who is responsable for the site. For now, this
will pop-up a lightbox screen which will allow you to pick someone from the
member list and make him the site owner. If there is no site owner, we pick someone
from the list of maintainers, if there is no maintainer, we pick the Sakai
Administrator (uses feed from above)

ToDo :

Domain

Description

Work Estimate

Feedback

Gather feedback from institutions to see whether this 1 owner approach would work

8 hours

Design

Design the lightbox that shows the list of users and lets you pick one

8 hours

Technical

Implementation

24 hours

 

 

Total: 30 hours

2. Site Id

The site id will be shown inside the url of the webpage. The site id cannot
be changed at this point anymore.

3. Member's Default Role

We rename this to: All new members become





3. Site Settings - Members

Note that currently getMembers() returns all user ids with no sorting or paging ability. This tends to be turned into a huge list of Participant or User or whatever is desired. Suggest sending all users for now and sorting in javascript OR implementing a sorta REST interface which is somewhat inefficient but can improve when the Sakai code improves (reduce the estimate if page/sort is deemed unimportant)
Notes: The last login is stored in a table and uses a listener, structure like so: UserId, Time, SiteRef
The SiteRef is null if it indicates the last login to the system, otherwise it is the last access to the site,
probably would require a set of observers to keep the table up to date.
The feed here would need to pull all memberships for the site and then include that total count in the data returned. It would also need to respond to the page and perpage get variables and respond to sort options as well.
This will be built into the existing membership feeds here: /direct/membership/describe
(code in the core-providers in EB)

ToDo :

Domain

Description

Work Estimate

Data Feed

Feed that gets the list of members for a site, including username, email, last login, role and status. Also make this feed pageable and sortable

16 hours

 

 

Total: 16

1. Select All vs Select All Visible

This is an attempt to not to make this page less to heavy to load. Select All
would select all of the records in the recordset (300 here), while Select All
Visible would only select the items visible on this page.

ToDo :

Domain

Description

Work Estimate

Technical

Implement this selection mechanism

8 hours

 

 

Total: 8 hours

2. Paging

Mechanism used to page through the members. This isn't the most elegant option
yet, and might need some redesigning.

ToDo :

Domain

Description

Work Estimate

Design

Look at the Fluid Pager and possible design

6 hours

Technical

Look at implementation of Fluid pager

24 hours

 

 

Total: 30 hours

3. Members

These member names are links to a profile page of that member. This will
be implemented to show a step up to the concept of social networking.

ToDo :

Domain

Description

Work Estimate

Design

Design this profile page

See comments

Technical

Implement

16 hours

 

 

Total: 16 hours

4. Emails

When you click on this, it will try to send an email (mailto-function)

5. Last login

Displays the date the user has logged in the last time on the system/visited the site.
There are a couple ways to get this but none are particularly efficient. It would be good to have a lastlogin stored on the user.
This would use the last login table from the feeds above. Access to the data should be simple since it would
just be a lookup of the membership based on the userId and siteRef.
/direct/membership/describe

ToDo :

Domain

Description

Work Estimate

Design

Look at whether we want to display last site visit or last system visit

See comments

Data Feed

Check scalibility and data availability of this last login field

4 hours

 

 

Total: 4 hours

6. Roles

List of available roles within the site
Feed would be simply to get the available roles and statuses OR set the role/status for a user in a site
Add this feed to the membership provider: /direct/membership/describe

ToDo :

Domain

Description

Work Estimate

Data Feed

Data feed that changes the role/status of user(s) inside a site

4 hours

Data Feed

Include the list of available roles in site feed

4 hours

 

 

Total: 8 hours

7. Status

Tells whether that user is currently active or inactive. If the user is inactive,
the previous fields grey out. If the user hasn't logged in yet, we still keep this
active/inactive field and the last login field would just say "Never".

ToDo :

Domain

Description

Work Estimate

Technical

Implementation

2 hours

 

 

Total: 2 hours

8. Update

This button will be removed, as saving will happen automatically after making a
new selection in the dropdownboxes.

ToDo :

Domain

Description

Work Estimate

Design

Design Feedback on auto-saving

4 hours

 

 

Total: 4 hours

9. Delete selected

This would remove the selected people from the site.
This works as described in the feed description page: /direct/membership/describe

ToDo :

Domain

Description

Work Estimate

Note

Design

Design confirmation lightbox that shows up when Delete button is being pressed

2 hours

Technical

Implementation

4 hours

Data Feed

Feed that allows to remove members from a site

2 hours

(tick) /direct/membership/describe

 

 

Total: 8 hours

10. Select a Command

This list will activate once a user is selected, and will allow you to bulk update
the list of selected users (e.g. change status to active, change status to inactive, change role to x)
The bulk update feed should already be completed in membership provider. /direct/membership/describe

ToDo :

Domain

Description

Work Estimate

Design

Come up with the actual commands

3 hours

(tick) done

Technical

Implementation

12 hours

 

 

Total: 12 hours

11. Add Members

This button activates the Add Members lightbox (see 3.4).





4. Site Settings - Members - Add Members

1. New Members

For now, we will ask for user email addresses only, as this is most likely
easily rememberable for people. This does need investigation.
We might also add some kind of search function to this screen
(e.g. search for people with a first name and last name, ...).
NOTE: review the add participants helper code/work as this has already solved many of the technical issues related to lookup/resolution of users
WARNING: We cannot go forward with this until there are clearer requirements about how the users should be listed (by username, lastname, id order, ?) and looked up (by email, username, etc., ?) and even displayed (displayname only?, gmail style?, ?)

ToDo :

Domain

Description

Work Estimate

Feedback

Get feedback on the "add based on an email address" - approach

8 hours

Design

Design the search screen/helper

*36 hours

Technical

Get feedback on how well this search function would work combined with LDAP directories

4 hours

 

 

Total: 12 hours (Incomplete est.)

*These hours not included in totals. I recommend we stick with the email approach for now using the simple text box with line break as designed.

2. Default Role

This will default to the Default Role set in 3.2.

3. Optional Message

This optional message will be inserted into the invitation email that will
be send.
NOTE: How should this message be handled in the feed though?

ToDo :

Domain

Description

Work Estimate

Technical

Implement optional message concept

 

 

 

Total: ? (Incomplete est.)

4. Send invitation

This will add the selected users to the site, give them the selected role
and send out an invitation email.
May want to allow adding each user with a different role rather than doing all users with the same role?
Look at the new add participants stuff for tips.
NOTE: How should we handle the configuration of the email message?
This would be part of the memberships feed but would include an extra option for sending the email.
/direct/memberships/describe

ToDo :

Domain

Description

Work Estimate

Design

Design confirmation message + feedback message

4 hours

Technical

Implementation

16 hours

Data Feed

Feed that adds users to a site with a specified role and sends out an email invitation with a custom email message

16 hours

 

 

Total: 20 hours (Incomplete est.)





5. Site Settings - Roles & Permissions - Modify Permissions

As most of this is controlled by the super admin in the Realms tool, we will
drop these screens for now. We might want to change the second screen so that it
becomes an aggregate view of all permissions for tools used within the site.

ToDo :

Domain

Description

Work Estimate

Design

Redesign page for aggregate tool permission view

16 hours

Technical

Investigate whether such an aggregated view can be achieved

 

Technical

Implement a set of widget permissions that control controlling widget layouts, changing settings on widgets, ...

32 hours

 

 

Total: 48 hours (Incomplete est.)





6. Site Settings - Import/Export

For now, we will remove the Copy My Sites and Site Templates tabs.

1. Red areas

All of these fields will be removed from the screen. The screen will allow
you to import a site's "structure" (tools - dashboard layout - settings),
and export the structure of the current site too.

ToDo :

Domain

Description

Work Estimate

Design

Re-design screen

4 hours

Feedback

Request feedback from the WG looking at archiving

6 hours

Technical

Investigate how export and import happens nowadays

 

 

 

Total: 10 hours (Incomplete est.)

2. Site Backup & More

We will rename this tab to Admin, and it should contain some explanatory
text of what the screen does

ToDo :

Domain

Description

Work Estimate

Design

Rename tab

10 min

 

 

Total: 10 min





TOTAL HOURS = ~226 (5.7 person weeks)