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
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 |
 |
 |
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 |
/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 |
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 |