This is a brainstorm of all actions that can be done in eprints, see r1343 for the initial version.

User Roles

Generic Roles

anonymous

Default permissions

valid-user

Any logged-in user

Roles for data objects

This is not a closed list. The site admin can invent any new roles they like.

eprint.owner

The owner of the eprint object

eprint.author

An author of the eprint object

eprint.editor_in_scope

A user who's editorial scope matches this object. Gives EPRINT_IN_EDIT_SCOPE

user.owner

The owner of the user object

Roles defined by user record

This mirrors the current user 'types', and may be expanded? TODO: Add all the relevent privilege's groups.

usertype.user

Standard user, can @deposit

usertype.editor

Editor-flagged user, can @editor

usertype.admin

Administrator-flagged user, can @edit-subject, @edit-user

Specific Roles

user-id

Privileges granted by username and password

group-id

Privileges granted by group membership

Implementation

The existing editor configuration is used to determine whether a user has the editor role for a data object (only applicable to EPrint).

# Can current user perform $privilege on $dataobj
$session->has_privilege( $privilege, [$dataobj] );

sub check
{
 my ( $user, $privilege, $dataobj ) = @_;

 # admin is God
 return true if $user and $user is admin;

 # get a list of roles for this $user
 my $func = $user->{session}->get_archive->get_conf( "user_roles" );
 $func ||= \&EPrints::Auth::user_roles;

 @roles = &{$func}( $user, $dataobj );

 # $user can always be anonymous (this might be used to make currently
 # public functions private)
 push @roles, qw( anonymous );

 my @permitted_roles = ();
 # check the $user has $permission in at least one of their @roles
 for {select $role,$net from permissions where role is in @roles and permission=$permission}
 {
  push @permitted_roles, $role if ($net is null || $net matches $remote_host);
 }
 # maybe the $user is a member of a group with $permission
 if( $user ) {
  for {select $role,$net from permissions join groups where user = $user->id and permission=$permission}
  {
   push @permitted_roles, $role if ($net is null || $net matches $remote_host);
  }
 }
 # By finding all valid roles for the user the calling code may
 # provide alternative interfaces (e.g. 'staff' or 'user' view)
 return @permitted_roles;
}

permissions

Permissions could include additional checks against the data object, although this is probably overkill.

Network-based access privileges are a 1% case, but having it here is relatively inexpensive.

name	type	description
role	char	user or group identifier
permission	char	permission constant
net_from	int	requesting user must originate from net (or null for any)
net_to	int	other end of the net range

groups

Groups provide an abstraction of many fine-grained privileges, allowing roles to be defined (e.g. administrators, editors, etc.) that many users are added to. A typical eprint's role is the eprint.owner who has privileges to edit an eprint in their inbox, to submit it to the buffer, derive clones and versions, and to request deletion.

name	type	description
user	char	user identifier
group	char	group identifier (must be prefixed by '@')

Privileges

Macros

tbc

These could easily be implemented by 'groups' (e.g. subscription becomes @subscription). The default 'userauth' 'user' is then a member of @subscription, @set-password, @deposit, @change-email, and @change-user.

@subscription

EDIT_USER_SUBSCRIPTIONS

@set-password

EDIT_USER_PASSWORD

@deposit

CREATE_EPRINT_INBOX, DERIVE_EPRINT_CLONE, DERIVE_EPRINT_VERSION, EDIT_EPRINT_INBOX, MOVE_EPRINT_INBOX_BUFFER, REQUEST_EPRINT_DELETION

@change-email

EDIT_USER_EMAIL

@change-user

LOGIN_USER, LOGOUT_USER, EDIT_USER

@editor

DELETE_EPRINT_*, EDIT_EPRINT_*, EDIT_EPRINT_*_ALL, MOVE_EPRINT_*, VIEW_EPRINT_*

@staff-view

VIEW_EPRINT_*_ALL

@edit-subject

EDIT_ARCHIVE_SUBJECTS

@edit-user

DELETE_USER, EDIT_USER_FULL

Actions on dataset

VIEW_EPRINT_INBOX/VIEW_EPRINT_BUFFER/VIEW_EPRINT_ARCHIVE/VIEW_EPRINT_DELETION

search dataset, view buffer

Actions on eprints

• CREATE_EPRINT_INBOX
• CREATE_EPRINT_BUFFER
• CREATE_EPRINT_ARCHIVE
• CREATE_EPRINT_DELETION
  • Create in i/b/a/d,
  • b/a/d only applicable to system api
• DELETE_EPRINT_INBOX .. REJECT FROM INBOX
• DELETE_EPRINT_BUFFER .. REJECT
• DELETE_EPRINT_ARCHIVE
• DELETE_EPRINT_DELETION
  • delete from i/b/a/d, owner-delete
• DERIVE_EPRINT_VERSION
  • add a new version
• DERIVE_EPRINT_CLONE
  • use as a template
• EDIT_EPRINT_INBOX
• EDIT_EPRINT_BUFFER
• EDIT_EPRINT_ARCHIVE
• EDIT_EPRINT_DELETION
  • edit in i/b/a/d, owner-edit
• EDIT_EPRINT_INBOX_ALL
• EDIT_EPRINT_BUFFER_ALL
• EDIT_EPRINT_ARCHIVE_ALL
• EDIT_EPRINT_DELETION_ALL
  • 'staff'-edit b/a/d
• MOVE_EPRINT_INBOX_BUFFER .. SUBMIT
• MOVE_EPRINT_BUFFER_INBOX .. BOUNCE, UNSUBMIT
• MOVE_EPRINT_BUFFER_ARCHIVE .. APPROVE
• MOVE_EPRINT_ARCHIVE_BUFFER
• MOVE_EPRINT_ARCHIVE_DELETION .. DELETE
• MOVE_EPRINT_DELETION_ARCHIVE .. UNDELETE
  • move from archive to deletion (delete),
  • move from deletion to archive (undelete)
• REQUEST_EPRINT_DELETION
  • request deletion of an eprint
• VIEW_EPRINT
• VIEW_EPRINT_ALL
  • preview abstract, view abstract ('jump-off') page, view all details ('staff' view)
• VIEW_EPRINT_FILES
• VIEW_EPRINT_FILES_ALL
  • download files, download all (secured) files ('staff' view)

User Records

DELETE_USER

delete a user record

EDIT_USER_EMAIL

change email

EDIT_USER_PASSWORD

change password

EDIT_USER/EDIT_USER_ALL

edit user record, edit all user details ('staff' view)

EDIT_USER_SUBSCRIPTIONS

modify subscriptions

LOGIN_USER/LOGOUT_USER

login (only applicable to anonymous role), logout, change user (only applicable to user role)

REGISTER_USER/VALIDATE_USER

register (only applicable to anonymous role?)

VIEW_USER/VIEW_USER_ALL

view user homepage, view all user details ('staff' view)

VIEW_USER_CONTRIBUTIONS

view eprints created by user

Other

EDIT_ARCHIVE_PRIVILEGES

edit privileges database *tbd

EDIT_ARCHIVE_SUBJECTS

edit subject tree

VIEW_ARCHIVE_STATUS

view archive status

VIEW_PAGES_BROWSE

view browse pages

VIEW_PAGES_STATIC

view static pages

End-user Configuration

Subject-based group privileges

# Create a group containing the user 'lac' 
> add lac ecs_editors
# Grant ecs_editors buffer-edit privileges for
# computer-science subjects (made up code)
> add ecs_editors EDIT_BUFFER "?subject=D*"
# And accept/reject privileges
> add ecs_editors MOVE_INBOX_BUFFER "?subject=D*"
> add ecs_editors MOVE_BUFFER_ARCHIVE "?subject=D*"
# Allow ecs_editors to request deletion
> add ecs_editors REQUEST_DELETION "?subject=D*"

Domain-based privilege

# The user lac is allowed to accept papers when he
# is in 152.78.*, or at 67.92.10.5
> add lac MOVE_BUFFER_ARCHIVE "152.78.0.0/16,67.92.10.5"

ArchiveConfig?.pm

$c->{user_groups} = sub {
  my( $user, $dataobj ) = @_;

  my @list = EPrints::Auth::user_groups($user,$dataobj);
  
#  push @list, "something";

  return @list;
}

Actions and SOAP

It seems to me that each of these actions maps very neatly to a web service method. Especially as you could make some services available to anonymous - eg. basic search and see-full-metadata. If you wanted.