Members in created team for org cannot view issue details.

[bkraul]

• Gitea version (or commit ref):
• Git version: 15d0ac7
• Operating system: Ubuntu 18.04 LTS
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL: https://try.gitea.io/issues )
  • No
  • Not relevant
• Log gist:

Description and Screenshots

When creating an organization, a default Owners team is created. All members in the owners team can view and modify all repos in organization, including issues.

A new team is created, called "Managers", a read-only team, to allow managers to view issues. All other items are disabled. What should happen, is that when going to the issues section, they should see all open/closed issues for all repos in organization.

In my build, 15d0ac7, team users can see the list of issues, but they get a 404 when clicking on the detail of the issue, as follows:

On the try.gitea site, I created the following user:

• user: arrow_user
• pass: Password1

And assigned it to my new organization, in a new team called "Managers", Arrow, which has a test repo in it.

Update:

It appears the desired behavior works correctly on try.gitea. I am not sure what I am doing wrong in my instance. I am running off a docker container, and I have just updated it to the latest, the issue persists. My apologies for the ever-changing information here. I want to make sure I am providing accurate data.

[bkraul]

This is the output from the docker container log:

[Macaron] 2018-05-12 15:27:08: Started GET /org/project1/issues/1 for 192.168.113.4
[Macaron] 2018-05-12 15:27:08: Completed GET /org/project1/issues/1 404 Not Found in 11.553263ms
[Macaron] 2018-05-12 15:27:42: Started GET /issues for 192.168.113.4
[Macaron] 2018-05-12 15:27:42: Completed GET /issues 200 OK in 53.552068ms
[Macaron] 2018-05-12 15:27:44: Started GET /org/project2/issues/1 for 192.168.113.4
[Macaron] 2018-05-12 15:27:44: Completed GET /org/project2/issues/1 404 Not Found in 10.398302ms

[bkraul]

Update, this is happening in two separate docker environments, so it can be replicated. I am using gitea/gitea:latest.

[bkraul]

Any updates on this?

[lafriks]

I can not seem reproduce this behaviour

[bkraul]

Are you using the docker container? As I said, this works OK on try.gitea (not sure about the environment it runs on there), the issue seems to be with the docker container provided at Docker Hub. I am not sure if you or your team are the maintainer of that or if I need to direct my support request somewhere else, my apologies if that does not apply to you.

[lafriks]

No, I did not use docker. try.gitea.io is running of latest docker hub image tho

[bkraul]

Not sure exactly what is going on, then. I use docker-compose as follows:

version: '2'

networks:
  gitea:
    external: false
    driver: bridge
  reverse-proxy:
    external:
      name: reverse-proxy

services:
  server:
    image: gitea/gitea:latest
    restart: always
    networks:
      - gitea
      - reverse-proxy
    volumes:
      - /mnt/nfs/docker/persist/gitea:/data
    environment:
      - VIRTUAL_HOST=gitea.mydomain.com
      - VIRTUAL_PORT=3000
    ports:
      - '22002:22'
    expose:
      - '3000'
    depends_on:
      - db
  db:
    image: mysql:5.7
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD=gitea
      - MYSQL_USER=gitea
      - MYSQL_PASSWORD=gitea
      - MYSQL_DATABASE=gitea
    networks:
      - gitea
    volumes:
      - /mnt/nfs/docker/persist/gitea/mysql:/var/lib/mysql

Everything else works perfectly fine. It is just that feature that does not seem to work properly.

[daviian]

@bkraul Did you try it with a clean gitea setup or always with the same database? Did you do a migration from gogs to gitea with this database?

[bkraul]

It was a clean gitea setup, no gogs. And as mentioned, I tried on 2 different docker environments, with the same results. I have been checking my ini to see if I am missing something, but I can't see anything that would affect something like that.

[daviian]

One thing that comes to my mind is that you use a nfs mount.
Maybe at the time of requesting the nfs mount was unreachable!?

[bkraul]

Unfortunately no, the nfs mount is fstab-based, and I run persist data for all my operations there without problems. Plus, the other docker instance where this problem also occurs does not have it's data on an nfs mount. The question I have is, isn't issue data stored on the database? so why would a 404 error happen unless there is an operation that redirects failed database lookups to a 404 error page, in which case, should I look at the database? It is obviously a user permissions error, because it only happens with users added to a group that is not the default owner group.

[daviian]

The 404 could be the result of a failed look up of the repository folder, that's why I was asking.
Maybe it could be of help if you describe how exactly you are creating the team and adding the members which have the problems. But currently I have no idea.

[bkraul]

Will work on setting up a video soon, host on my public cloud and post link here. Hopefully I can get to the bottom of this. Thank you for your responses and willingness to help.

[bkraul]

Not sure if github will allow this link but here it is. As you can see it is a very simple operation, and at the end I am making sure the path to the git files is live.

[bkraul]

I believe I have found the cause that triggers the issue: The repository is marked as private.

When I unmark it as private, then the test1 user who is a member of the Managers team can view the issue without problems. I am thinking this is the reason the behavior worked on try.gitea (test project was likely set as public).

This presents a problem, because I do indeed want the projects to remain private and not visible to all users who connect to the gitea instance. However, given that I have explicitly added the user to a team in the organization, the user should be able to see and work with issues for all projects in the organization like it works for organization owners, while respecting the privileges given to the team he/she is in.

Does that make sense?

[daviian]

Guess I figured out whats troubling you. You've to assign the repositories to the team as well.

The bug is that issues are shown despite this hasn't been done.

[bkraul]

I see your point. I did what you suggested and it worked as expected. I guess I inferred that if the Owners team sees every project in the organization, so should any other team with their own separate permissions. I see now that I actually have to add the repositories to the team, option being by the side of "Members".

Thank you so much for guiding me through this. I am glad at least I unintentionally assisted with finding a bug ;). I will let you close this as convenient for you (or keep it open in regards to the actual bug).

[daviian]

@bkraul Would you be so kind as to open a new issue describing the faulty behaviour (being able to see issues despite not having repository assigned to the team) and close this one?

[bkraul]

You got it man.

[bkraul]

Closed in lieu of #4029