Editing Archive:OneShare (section)

==Core==

===Data Model (seb)===

Tasks

* What is a bare minimum for metadata?
* What do we do with Uni divisions/hierarchy? Part of extended schema? Part of core-data?
* What do we do with the security model eg viewing/editing permissions? see below.
* Do we include or provide different subjects hierarchies (eg JACS...)? As an optional feature?
* What is the name of a 'resource'? A 'Resource' or a 'Share'? 
* What are the basic data types?? On EdShare we have shares, collections, bookmarks, shoppbasket. On LBox we have resources, "resource_collection" -> need to harmonize.

 Also see sections on Collections, Bookmarks.


 Priority: high, core feature!
 Time: dev < 1 week, politics < 1 month hopefully

Dev to make decisions

===User Xperience===

Define a user workflow i.e.:

* How does the user interact with the repository? 
* What is their path through the site for creating, managing their resources? Is it consistent?

On Edshare, this needs loads of improvements :)

Make links to all features (browsing, searching etc) intuitive/easy to find/consistent.

 Priority: low
 Time: 1-2 dev, 1 week politics

===UI Styling===

Create a unique, generic style for OneShare. This should be eye-catching but generic/neutral enough (cf. a vanilla EPrints install).

This include: default citations for resources and files, site template, frontpage, <add more>.

* Also we could package the LBox & EdShare styles as optional themes?

 Priority: low
 Time: unknown?

===Security (seb)===

Please view [[OneSharePerms]].

====Viewing Permissions====

Use EdShare Soton's advanced viewing permissions to share with selected users, schools etc.

Previews are also included into that model i.e. you cannot see previews for a resource if you're not allowed to view/download the resource.

====Editing Permissions====

Cf. Viewing Permissions but for editing.

Maybe merge viewing + editing perms into a more generic ACL system.

====ACLs for Viewing and Editing items?====

We could create a system of ACL (Access Control List) for each share/resource and add the appropriate hooks in the code:"can_user_edit", "can_user_view".

* The idea on EdShare Soton is good (share with school, uni, x/y) but need refactoring/rewriting.
* How do we generalise this to EPrints and add the right hooks to the existing eprints code? Maybe ask TimB for advice.

 Priority: low
 Time: 3-4 days to refactor/generalise

====HTTPS====

* Make all the code COMPLIANT to HTTPS :)

===Defaults (seb)===

We need to have default browse views, searches etc. which reflects our metadata schema and interests.

Concerns:
* Views: browse by uni hierarchy? by tag? by course code? (+meprints views)
* Searches: search our metadata fields
* Documents namedsets: add multimedia mime types to EPrints
* EPrints type: let's remove all the default types (article, book...)?
* EPrints fields: let's remove all the default -unused- eprint fields? Maybe be careful of hard-coded fields in the code.
* EPrint Worflow
* User Workflow
* LDAP: most Uni will have a LDAP server
* User roles
* more?

===EdShare's links===

EdShare Soton allows users to share files -or- links and even caches the shared links.

* What do we do with this feature? Is this a customised EdShareSoton feature?