IPKM/nmreval
16
2
Fork 1
Code Issues 44 Pull Requests Actions Packages Releases Wiki Activity

migrate bug report to gitea #1

New Issue
Closed
opened 2023-02-04 10:47:16 +00:00 by dominik · 6 comments
dominik commented 2023-02-04 10:47:16 +00:00
Member
Copy Link
Copy Source
No description provided.
dominik self-assigned this 2023-02-04 10:47:16 +00:00
dominik commented 2023-02-04 11:15:47 +00:00
Author
Member
Copy Link
Copy Source

Users are redirected to phabricator for issue, use API to create issues.

Users are redirected to phabricator for issue, use API to create issues.
dominik added the
Status
Need More Info
 label 2023-02-04 14:22:39 +00:00
dominik commented 2023-02-04 14:36:18 +00:00
Author
Member
Copy Link
Copy Source

Users are redirected to phabricator for issue, use API to create issues.

This does not work for arbitrary users: API does not allow username/password and retrieving a token needs a login, so the issue can be created here directly...

> Users are redirected to phabricator for issue, use API to create issues. This does not work for arbitrary users: API does not allow username/password and retrieving a token needs a login, so the issue can be created here directly...
markusro commented 2023-02-05 13:37:24 +00:00
Owner
Copy Link
Copy Source

IMHO there are two ways to tackle this:

The way organizations work in gitea it seems like I have to reevaluate the strategy. This does not work as I thought, i.e.
I can not use a team from another Organization, users are not automatically in the IPKM-public org, etc.

  1. Move the repo to IPKM and assign agvogel team as owner, so that the actual users can create tickets. This is OK for this repo, but intergroup collaboration should be also possible. I have to look how I can do this.
    The default for IPKM would be then "public" and IPKM-public is not needed anymore.
    This would solve the LDAP mapping of the groups, as that is already setup.

  2. Create a dummy user, make a token. That access token can be used then for that ticket creation. The dummy user must be in the correct team. The user creating the ticket is then basically unknown to gitea, one could put the username in the body of the template though.

IMHO there are two ways to tackle this: The way organizations work in [gitea](https://docs.gitea.io/en-us/permissions/) it seems like I have to reevaluate the strategy. This does not work as I thought, i.e. I can not use a team from another Organization, users are not automatically in the IPKM-public org, etc. 1) Move the repo to IPKM and assign agvogel team as owner, so that the actual users can create tickets. This is OK for this repo, but intergroup collaboration should be also possible. I have to look how I can do this. The default for IPKM would be then "public" and IPKM-public is not needed anymore. This would solve the LDAP mapping of the groups, as that is already setup. 2) Create a dummy user, make a token. That access token can be used then for that ticket creation. The dummy user must be in the correct team. The user creating the ticket is then basically unknown to gitea, one could put the username in the body of the template though.
markusro commented 2023-02-05 14:25:03 +00:00
Owner
Copy Link
Copy Source

The damaris-script-library repository is working I think:

https://gitea.pkm.physik.tu-darmstadt.de/IPKM/damaris-script-library/settings/collaboration

The rights look correct:

  • Owners
  • administrators
  • agvogel
  • can add second team (read only)
The damaris-script-library repository is working I think: https://gitea.pkm.physik.tu-darmstadt.de/IPKM/damaris-script-library/settings/collaboration The rights look correct: - [x] Owners - [x] administrators - [x] agvogel - [x] can add second team (read only)
markusro commented 2023-02-05 14:27:58 +00:00
Owner
Copy Link
Copy Source

Shall I move it the IPKM organization?
We would have to fix the links again ...

Shall I move it the IPKM organization? We would have to fix the links again ...
markusro self-assigned this 2023-02-06 19:41:47 +00:00
markusro commented 2023-02-06 19:42:28 +00:00
Owner
Copy Link
Copy Source

This is moved to the other org (IPKM).

This is moved to the other org (IPKM).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Kind/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Crash
This issue describes unexpected shutdowns or non-responsive behaviors
 Kind/Documentation
Improves documentation
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New feature
Priority
Critical
The priority is critical
Priority
High
The priority is high
Priority
Low
The priority is low
Priority
Medium
The priority is medium
Priority
Very low
The priority is very low
Reviewed
Duplicate
This issue or pull request already exists
Reviewed
Invalid
Invalid isssue
Reviewed/Won't Fix
This issue won't be fixed
Status
Need More Info
Feedback is required to reproduce issue or to continue work
Status
On Hold
This issue or pull request is on hold
Status
Stale
Issues without activity for more than 6 months
Type/BDS
Issues connected to BDS
 Type/DSC
Issues connected to DSC
 Type/Fit
Issue is connected to fitting data
 Type/General
issue connected to general functionality
 Type/NMR
Issues connected to NMR
No labels
Status
Need More Info
Milestone
No items
No Milestone
Assignees
Clear assignees
aahmad (Arshid Ahmad) anisar (Aqsa Nisar) ckolb (Christian Kolb) cwolter (Celine Wolter) dominik (Dominik Demuth) dwuerz (David Würz) elisa (Elisa Steinruecken) fwolter (Finn Wolter) huczhang (Huanchen Zhang) jepsinrajkp (Jepsinraj Kakkuzhiyulla Parambath) kschroeder (Katharina Schroeder) malbrecht (Maximilian Albrecht) mandal (Suvendu Mandal) markusro (Markus Rosenstihl) mbergmann (Mark Bergmann) mhaneke (Markus Haneke) robin (Robin Horstmann) saeckech (Christoph Säckel) skloth (Sebastian Kloth) skrueger (Sandra Krüger) ypiliauskaya (Yauheniya Piliauskaya)
No Assignees markusro dominik
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: IPKM/nmreval#1