archiva-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deng Ching <>
Subject Re: New Feature - Request/Grand access to repositories
Date Thu, 30 Apr 2009 02:35:49 GMT
Sounds like a good feature to me :)
Have you thought of how you'll implement this in Archiva? It's using Redback
for the security system and from the features below, it looks like most of
the changes will be in Redback.

If there's anything we can do to help out specially in figuring out parts of
the code, just send a mail here or in the dev list :) There's also a
#archiva in


On Wed, Apr 29, 2009 at 3:20 PM, U Gopalakrishnan <>wrote:

> Hello,
> I would like know what the list thinks about a new feature described below
> for Archiva. If there are many thump-ups for this then I would go ahead
> with trying to implement it
> Background : In a enterprise deployment of Archiva, there could be many
> product repositories hosted on a single archiva server and many hundreds
> of users for archiva with different access permission and restrictions.
> Currently in archiva there is no way for a user to request access, so it
> need to be via another communication channel (e.g. a mail/call  to the
> archiva admin). This could get quite out of control when there are 100s of
> users and many repositories in the server, So I am suggesting the
> following new features for Archiva for streamlining the request/grand
> access process.
> 1. As user of the archiva repository, I should be able to request
> read/write access to a single/multiple repositories.
> 2.Administrator(s) of Archiva should get notification mails when a user
> raises a request
> 3. On receiving the notification, administrator should be able review the
> request in the archiva admin page and make a grand/reject decision on the
> request.
> 4. The user should get a notification mail once the admin complete his
> review of the request.
> Also we could log all these events to the archiva audit log.
> Any thoughts/comments?
> Thanks
> Gopal

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message