Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Organization-wide projects bugs #23318

Closed
8 of 10 tasks
delvh opened this issue Mar 5, 2023 · 24 comments · Fixed by #24097
Closed
8 of 10 tasks

Organization-wide projects bugs #23318

delvh opened this issue Mar 5, 2023 · 24 comments · Fixed by #24097
Labels
topic/ui Change the appearance of the Gitea UI type/bug type/summary This issue aggregates a bunch of other issues

Comments

@delvh
Copy link
Member

delvh commented Mar 5, 2023

Description

At the moment, organization-wide projects are riddled with bugs, based on preliminary user feedback from 1.19.0-rc1:
They are

  • no one (not even the site admin) can edit/delete org projects, see screenshots 1 and 3
  • repo projects allow to set the card preview type during creation. Organization projects don't, see screenshots 5 and 6
  • Org projects ignore the column color, see screenshots 1 and 2, the right column should have the color #ff0000.

These issues can be fixed by sharing the code of repo projects with the organization projects.

Furthermore, the following issues are present:

  • The organization Projects tab misses quite a few tabs as well as the organization settings, see screenshots 1, 3, and 5.
  • When creating an org project, and adding a second column
  • If a repo disables projects, its issues cannot be assigned to org-wide projects either. While the current logic for that is clear (if isPackagesEnabled <list available projects> end), this would probably still be useful to implement.
  • Both organization and repo projects cannot edit the column color anymore
  • If you click on the PR that closed an issue inside an org-wide project, you get redirected to $URL/pull/$ID instead of $URL/$USER/$REPO/pull/$ID

Screenshots

Screenshot 1: Org project appearance

image

Screenshot 2: Repo project appearance

image

Screenshot 3: org repo projects list

image

Screenshot 4: Repo projects list

image

Screenshot 5: New org project

image

Screenshot 6: New repo project

image

Gitea Version

1.20.0+dev-90-gea7f0d6fc

Can you reproduce the bug on the Gitea demo site?

Yes

Operating System

Linux

Browser Version

Firefox 110.0

@delvh delvh added type/bug topic/ui Change the appearance of the Gitea UI labels Mar 5, 2023
@yp05327
Copy link
Contributor

yp05327 commented Mar 7, 2023

@yp05327
Copy link
Contributor

yp05327 commented Mar 10, 2023

@delvh

Org projects ignore the column color, see screenshots 1 and 2, the right column should have the color #ff0000.

I notice that we can not edit the column color in both repo and org/user projects in current main branch.
In 1.18.5, I can edit the column color in both repo projects.
It seems that the link is incorrect. I will fix this later.
Can you confirm this problem, and add to the task list?
Thanks.


Fix: #23400

Maybe we need a test to avoid this again.

@yp05327
Copy link
Contributor

yp05327 commented Mar 10, 2023

repo projects allow to set the card preview type during creation. Organization projects don't, see screenshots 5 and 6

The select box will display nothing even if one is selected.

@6543

This comment was marked as duplicate.

@delvh

This comment was marked as duplicate.

@6543 6543 added the type/summary This issue aggregates a bunch of other issues label Apr 2, 2023
silverwind pushed a commit that referenced this issue Apr 11, 2023
…4043)

Part of #23318

The way to fix the missing cardtype for user/org level projects in this
PR is to port the cardtype related part from #22112 to org/user level
projects' template and router functions.

Before:
<img width="1135" alt="截屏2023-04-11 13 55 49"
src="https://user-images.githubusercontent.com/17645053/231069068-ba897129-ae90-4aa0-9b0f-468bf5c65375.png">

<img width="1131" alt="截屏2023-04-11 13 55 59"
src="https://user-images.githubusercontent.com/17645053/231069084-279f6681-5a10-42da-b5a8-2b0ba47c7078.png">


After:
Create
<img width="835" alt="截屏2023-04-11 13 27 16"
src="https://user-images.githubusercontent.com/17645053/231064445-0d6e12bd-5725-48db-a102-80e7472757c2.png">

Edit
<img width="852" alt="截屏2023-04-11 13 27 05"
src="https://user-images.githubusercontent.com/17645053/231064503-c70525cd-1038-43ec-8d93-8b8d95d183d4.png">

View
<img width="1329" alt="截屏2023-04-11 13 26 56"
src="https://user-images.githubusercontent.com/17645053/231064529-26023c85-698b-4b2e-af02-45f9820c77ec.png">

Co-authored-by: Giteabot <teabot@gitea.io>
silverwind added a commit that referenced this issue Apr 12, 2023
…4043) (#24066)

Backport #24043 

Part of #23318

The way to fix the missing cardtype for user/org level projects in this
PR is to port the cardtype related part from #22112 to org/user level
projects' template and router functions.

Before:
<img width="1135" alt="截屏2023-04-11 13 55 49"
src="https://user-images.githubusercontent.com/17645053/231069068-ba897129-ae90-4aa0-9b0f-468bf5c65375.png">

<img width="1131" alt="截屏2023-04-11 13 55 59"
src="https://user-images.githubusercontent.com/17645053/231069084-279f6681-5a10-42da-b5a8-2b0ba47c7078.png">


After:
Create
<img width="835" alt="截屏2023-04-11 13 27 16"
src="https://user-images.githubusercontent.com/17645053/231064445-0d6e12bd-5725-48db-a102-80e7472757c2.png">

Edit
<img width="852" alt="截屏2023-04-11 13 27 05"
src="https://user-images.githubusercontent.com/17645053/231064503-c70525cd-1038-43ec-8d93-8b8d95d183d4.png">

View
<img width="1329" alt="截屏2023-04-11 13 26 56"
src="https://user-images.githubusercontent.com/17645053/231064529-26023c85-698b-4b2e-af02-45f9820c77ec.png">

---------

Co-authored-by: silverwind <me@silverwind.io>
@HesterG
Copy link
Contributor

HesterG commented Apr 13, 2023

Find another issue, Buttons used on "set defualt" and "delete column" are not proper, so cancel will disappear on hover. And this occurs on both repo and org level projects:

default.mov

IMO It is a good idea to use delete_modal_actions.tmpl here both to fix this issue and keep ui consistency as suggested by TODO here
I will open a PR to solve this.

@yp05327
Copy link
Contributor

yp05327 commented Apr 13, 2023

Maybe this problem is caused by css?
The button will not disappear in dark mode.

If I open devtools in chrome, the button works well in dark mode.
But if I close DevTools, the button will have no changes when mouse move across the button.

Open devtools:
mouse not on the button:
image
mouse on the button:
image

Close devtools (always same as mouse on the button):
image
Tested in gitea.com

@HesterG
Copy link
Contributor

HesterG commented Apr 13, 2023

Maybe this problem is caused by css? The button will not disappear in dark mode.

If I open devtools in chrome, the button works well in dark mode. But if I close DevTools, the button will have no changes when mouse move across the button.

Open devtools: mouse not on the button: image mouse on the button: image

Close devtools (always same as mouse on the button): image Tested in gitea.com

Yes it is caused by css, the reason why arc-green theme looks good is because the color for the text on cancel button on hover is different from gitea theme. And here it might be more suitable to use delete_modal_actions.tmpl also for consistency, like some other places with the similar modal ui:

e.g. Delete Project UI:

截屏2023-04-13 13 58 36

@silverwind
Copy link
Member

Looks like some bug in the button colors. I'd argue the modal buttons should be full red/green, with no inner grey border, on both themes.

@HesterG
Copy link
Contributor

HesterG commented Apr 18, 2023

Looks like some bug in the button colors. I'd argue the modal buttons should be full red/green, with no inner grey border, on both themes.

Do you mean like this?

default.mov

@silverwind
Copy link
Member

Do you mean like this?

I envisioned with border, but your style looks even better, let's do it.

@HesterG
Copy link
Contributor

HesterG commented Apr 20, 2023

Do you mean like this?

I envisioned with border, but your style looks even better, let's do it.

add a commit 1df04ee to do this style

lunny pushed a commit that referenced this issue Apr 23, 2023
…related actions (#24097)

Co-Author: @wxiaoguang 

This PR is to fix
#23318 (comment) .
The way to fix this in this PR is to use `delete_modal_actions.tmpl`
here both to fix this issue and keep ui consistency (as suggested by
[TODO
here](https://github.com/go-gitea/gitea/blob/4299c3b7db61f8741eca0ba3d663bb65745a4acc/templates/projects/view.tmpl#L161))

And this PR also refactors `delete_modal_actions.tmpl` and its related
styles, and use the template for more modal actions:

1. Added template attributes:
* locale
* ModalButtonStyle: "yes" (default) or "confirm"
* ModalButtonCancelText
* ModalButtonOkText

2. Rename `delete_modal_actions.tmpl` template to
`modal_actions_confirm.tmpl` because it is not only used for action
modals deletion now.

3. Refactored css related to modals into `web_src/css/modules/modal.css`
and improved the styles.

4. Also use the template for PR deletion modal and remove issue
dependency modal.

5. Some modals should also use the template, but not sure how to open
them, so mark these modal actions by `{{/* TODO: Convert to
base/modal_actions_confirm */}}`

After (Also tested on arc green):

Hovering on the left buttons

<img width="711" alt="Screen Shot 2023-04-23 at 15 17 12"
src="https://user-images.githubusercontent.com/17645053/233825650-76307e65-9255-44bb-80e8-7062f58ead1b.png">

<img width="786" alt="Screen Shot 2023-04-23 at 15 17 21"
src="https://user-images.githubusercontent.com/17645053/233825652-4dc6f7d1-a180-49fb-a468-d60950eaee0d.png">

Test for functionalities:

https://user-images.githubusercontent.com/17645053/233826857-76376fda-022c-42d0-b0f3-339c17ca4e59.mov

---------

Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
@delvh
Copy link
Member Author

delvh commented Apr 23, 2023

Closed accidentally.

@delvh
Copy link
Member Author

delvh commented Jun 28, 2023

Found another one: If you click on the PR that closed an issue inside an org-wide project, you get redirected to $URL/pull/$ID instead of $URL/$USER/$REPO/pull/$ID

@brenthuisman
Copy link

Found another one: If you click on the PR that closed an issue inside an org-wide project, you get redirected to $URL/pull/$ID instead of $URL/$USER/$REPO/pull/$ID

Just got bit by this one (during a demo of Gitea). Tracking issues on a org board or third repo board are broken.

lafriks pushed a commit that referenced this issue Jan 15, 2024
GiteaBot pushed a commit to GiteaBot/gitea that referenced this issue Jan 15, 2024
lunny pushed a commit that referenced this issue Jan 16, 2024
Backport #28806 by @denyskon

Fixes_
#23318 (comment)

Co-authored-by: Denys Konovalov <kontakt@denyskon.de>
fuxiaohei pushed a commit to fuxiaohei/gitea that referenced this issue Jan 17, 2024
henrygoodman pushed a commit to henrygoodman/gitea that referenced this issue Jan 31, 2024
silverwind pushed a commit to silverwind/gitea that referenced this issue Feb 20, 2024
6543 pushed a commit that referenced this issue Mar 4, 2024
Part of #23318 

Add menu in repo settings to allow for repo admin to decide not just if
projects are enabled or disabled per repo, but also which kind of
projects (repo-level/owner-level) are enabled. If repo projects
disabled, don't show the projects tab.


![grafik](https://github.com/go-gitea/gitea/assets/47871822/b9b43fb4-824b-47f9-b8e2-12004313647c)

---------

Co-authored-by: delvh <dev.lh@web.de>
@denyskon
Copy link
Member

Confirmed that the last remaining issues were resolved by #28805 and #28806

@delvh
Copy link
Member Author

delvh commented Mar 17, 2024

I think

When creating an org project, and adding a second column only the second column can be edited, the first one can't.
See screenshot 1 and 2. Happens both for repo- and org-projects

is still present.
But apart from that, yes, agreed, we slowly seem to have gotten rid of the project bugs. Finally 😌

@denyskon
Copy link
Member

@delvh Why should the default column be edited? If you don't like it, create a new one and set it as default. I think it is expected behaviour.

@delvh
Copy link
Member Author

delvh commented Mar 17, 2024

grafik

Why do we need such a workaround for these things?

@denyskon
Copy link
Member

Well maybe it's because I always considered it to be a feature, not a bug, I don't understand where the problem is, but for me the default column always was something that is there for empty projects still to be able to contain issues, and if you need more you create a new column. We can change it of course.

@delvh
Copy link
Member Author

delvh commented Mar 17, 2024

That's not what I mean.
What I mean is:
Why can't I rename or recolor the default board but everything else?
However, if I change the default board, I suddenly can?

@denyskon
Copy link
Member

Because thats how it is!!!!!!!!!11!1!1!1

Maybe modern-day technology just educates us to accept issues as if they were intended?

Anyways, I'll check if it can be adapted easily....

@denyskon
Copy link
Member

denyskon commented Mar 17, 2024

@delvh Currently, this non-adaptable board is generated dynamically when getting a project from DB which doesn't contain a board. It could theoretically be fixed by simply creating a default board when creating an empty project.

@denyskon denyskon reopened this Mar 17, 2024
@denyskon denyskon self-assigned this Mar 17, 2024
@delvh
Copy link
Member Author

delvh commented Mar 17, 2024

Instead of misusing this issue for it, let's move the discussion to another one.

@delvh delvh closed this as completed Mar 17, 2024
@denyskon denyskon removed their assignment Mar 17, 2024
@go-gitea go-gitea locked as resolved and limited conversation to collaborators Jun 16, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
topic/ui Change the appearance of the Gitea UI type/bug type/summary This issue aggregates a bunch of other issues
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants