Hi,
emma peel (2020-08-15):
> I like the gitlab interface, and I think I am starting to feel comfortable on it.
> But I must say that I find uncomfortable the lose of the privileges
> I have since moving from Redmine.
Thank you so much for sharing, both the good and the bad!
> I have noticed I am a 'reporter' in gitlab. Is there a reason I am
> not a 'developer' anymore, like in Redmine?
There's indeed a reason why I mapped authorization from the previous
Gitolite + Redmine setup to GitLab this way during the migration.
I'll explain it below.
But first, I want to make something extra clear: my explanation below
does *not* mean your current GitLab access level is set in stone!
I'll come back to this on the mailing list that is currently
authoritative for this sort of things.
So, previously we had 2 things in terms of authorization:
- Gitolite handled access to Git repositories
- Redmine handled access to issues
Now we have 1 thing: GitLab, that does both (and more, actually, but
we don't fully use it yet). On the one hand, it's a simpler model,
with one single place to configure and maintain consistency. OTOH,
this gives us less fine-grained parameters to play with.
In the case at hand, in a nutshell: giving you access level to GitLab
issues, equivalent to what you had on Redmine, would give you
significantly higher access level to Git than what you had before.
For example, Developer access allows overwriting Git tags,
which is not negligible.
While doing the migration, I opted for *not* giving folks such extra
access to Git compared to the previous state of things. This felt like
the right thing to do as a first iteration, because granting extra
access to Git requires possibly long or difficult conversations, which
I did not have time to facilitate back then. For some people,
unfortunately the result is that I lowered their access level to
issues :/
So, for the folks who are negatively impacted by this, what we need to
do now is basically to identify needs (in terms of access level to
issues) and then decide if it's OK, in order to satisfy them, to raise
someone's access level *both* to issues and to Git. This can only be
a case-by-case conversation. In the current state of our governance
model, the final decision belongs to tails@.
> Thing I used to be able to do in Redmine and I cannot do now are:
I'm very grateful you started this process by identifying and sharing
your needs :)
Below I'll refer to permission levels as documented there:
https://gitlab.tails.boum.org/help/user/permissions.html#project-members-permissions
> Editing titles and descriptions of tickets from other people:
> -------------------------------------------------------------
>
> Sometimes there are tickets that start with not much information,
> and after debugging for a while, the problem gets better understood
> and can be defined.
>
> In Redmine, when this happened I used to edit the tickets title or
> description and this made the ticket more understandable without
> going through the whole list of comments, and it was also better for
> when the ticket was on a list.
>
> I feel that we are now duplicating tickets just because we cannot
> edit them.
Heard. I had no idea.
This requires Developer access.
> Moving tickets from one component to the other
> ----------------------------------------------
>
> I have opened at least one ticket in tails/tails, that I would like to move to tails/sysadmin: https://gitlab.tails.boum.org/tails/tails/-/issues/17870
>
> But I cannot do it, and is a ticket I opened. I would like to have this privilege.
It seems this requires Developer access *both* in the origin and
destination projects: in this case, both on tails/tails and tails/sysadmins.
See at the end of this email for tails/tails.
Regarding tails/sysadmins, once their new
GitLab workflow is in place
(
https://gitlab.tails.boum.org/tails/gitlab-config/-/merge_requests/8)
we can discuss who shall have Developer access there :)
> Assign tickets to other people
> ------------------------------
>
> I used to be able to assign tickets to sajolida for review or
> triaging, should I now do that as a mention?
You should already be allowed to do that. I see other Help Desk
members assigned issues to me recently. Can you please double-check?
But perhaps you mean MRs? Assigning MRs indeed requires
Developer access.
> while doing frontdesk I triage new tickets, and if I assign them to
> somebody, I get them out of the 'unassigned' pool.
In passing, note that this is not part of the Help Desk's job since
a year (69697e004a1739e877c01dc733e1b96be954f4ac). I was not aware
that you were still doing it.
Cheers!
