[GRASS-dev] tracker write/read access at GForge

Hi,

The trackers for GRASS at GForge are ready to be deployed and announced
[1]. There is one thing stopping me though. I believe that it should be
possible to have project members with no writing access for trackers.
So that only selected members could modify and *delete* tickets
sumbitted. And although GForge seems to provide such option via setting
'Read' access for a given 'Role', it doesn't work as I expect it. Even
if I create a user with a 'Junior Developer' Role, who has only Read
access for trackers, he is still able to delete and remove tickets as
if he was an admin.

I read the GForge manual [2], but found no answer. What's wrong (with me?)?

Best,
Maciek

[1]http://wald.intevation.org/tracker/?group_id=21
[2]http://gforge.org/docman/view.php/1/34/gforge_manual.pdf

Hi Maciej,

On Monday 23 October 2006 22:37, Maciej Sieczka wrote:

The trackers for GRASS at GForge are ready to be deployed and announced
[1].

nice!

There is one thing stopping me though. I believe that it should be
possible to have project members with no writing access for trackers.
So that only selected members could modify and *delete* tickets
sumbitted.

Can you tell me more about the use case behind this user role?
In my opinion it is good to give a member of the team the right
to manipulate tracker entries as first permission.

And although GForge seems to provide such option via setting
'Read' access for a given 'Role', it doesn't work as I expect it. Even
if I create a user with a 'Junior Developer' Role, who has only Read
access for trackers, he is still able to delete and remove tickets as
if he was an admin.

I read the GForge manual [2], but found no answer. What's wrong (with me?)?

This could be a bug in the gforge software that we are running on wald.
Best is to add a report how to reproduce the problem to the
http://wald.intevation.org/projects/siteadmin
We already know a few shortcomings and work to overcome them.
Our next step will be to upgrade to a newer version of gforge,
for this we run staging tests first.
This is also the prerequisite for us to do further improvements
to the software.

Best Regards,
Bernhard

--
Managing Director - Owner, www.intevation.net (Free Software Company)
Germany Coordinator, fsfeurope.org (Non-Profit Org for Free Software)
www.kolab-konsortium.com (Email/Groupware Solution, Professional Service)

Hi Bernhard!

Bernhard Reiter wrote:

On Monday 23 October 2006 22:37, Maciej Sieczka wrote:

There is one thing stopping me though. I believe that it should be
possible to have project members with no writing access for trackers.
So that only selected members could modify and *delete* tickets
sumbitted.

Can you tell me more about the use case behind this user role?

To minimise the likelyhood of somebody deleting something by accident.

In my opinion it is good to give a member of the team the right
to manipulate tracker entries as first permission.

I absolutely agree all members must be able to comment/reply/change
status of custom elements, the subject and so on.

But not everyone should have admin rights, ie. to be able to inevitably
delete a ticket, a custom element or the whole tracker. 2 admins should
be enough.

And although GForge seems to provide such option via setting
'Read' access for a given 'Role', it doesn't work as I expect it. Even
if I create a user with a 'Junior Developer' Role, who has only Read
access for trackers, he is still able to delete and remove tickets as
if he was an admin.

I read the GForge manual [2], but found no answer. What's wrong (with me?)?

This could be a bug in the gforge software that we are running on wald.
Best is to add a report how to reproduce the problem to the
http://wald.intevation.org/projects/siteadmin

Done:
http://wald.intevation.org/tracker/index.php?func=detail&aid=218&group_id=1&atid=162

We already know a few shortcomings and work to overcome them.
Our next step will be to upgrade to a newer version of gforge,
for this we run staging tests first.
This is also the prerequisite for us to do further improvements
to the software.

Do you have some time schedule for that?

Regards,
Maciek

On Sunday 29 October 2006 02:51, Maciej Sieczka wrote:

> This could be a bug in the gforge software that we are running on wald.
> Best is to add a report how to reproduce the problem to the
> http://wald.intevation.org/projects/siteadmin

Done:

http://wald.intevation.org/tracker/index.php?func=detail&aid=218&group_id=1&atid=162

Thanks for the report and for describing the need. I agree
that it is not good if everybody can delete item elements.

> We already know a few shortcomings and work to overcome them.
> Our next step will be to upgrade to a newer version of gforge,
> for this we run staging tests first.
> This is also the prerequisite for us to do further improvements
> to the software.

Do you have some time schedule for that?

No fixed schedule, some of the staging tests are already done.
I expect the upgrade to happen before the end of the year, though.
It well might happen earlier. (And I hope so).

Bernhard

--
Managing Director - Owner, www.intevation.net (Free Software Company)
Germany Coordinator, fsfeurope.org (Non-Profit Org for Free Software)
www.kolab-konsortium.com (Email/Groupware Solution, Professional Service)