Commit graph

8 commits

Author SHA1 Message Date
James Lopez
4c3ec579e5 added more specs 2016-12-21 13:29:27 +01:00
James Lopez
b82fdf6257 Fix error 500 renaming group. Also added specs and changelog. 2016-12-20 17:52:27 +01:00
Kamil Trzcinski
e8aab1cd15 This fixes a long running tests due to changed Sidekiq state 2016-08-15 23:26:40 +02:00
Stan Hu
cb8a425ba4 Fix bug where destroying a namespace would not always destroy projects
There is a race condition in DestroyGroupService now that projects are deleted asynchronously:

1. User attempts to delete group
2. DestroyGroupService iterates through all projects and schedules a Sidekiq job to delete each Project
3. DestroyGroupService destroys the Group, leaving all its projects without a namespace
4. Projects::DestroyService runs later but the can?(current_user,
   :remove_project) is `false` because the user no longer has permission to
   destroy projects with no namespace.
5. This leaves the project in pending_delete state with no namespace/group.

Projects without a namespace or group also adds another problem: it's not possible to destroy the container
registry tags, since container_registry_path_with_namespace is the wrong value.

The fix is to destroy the group asynchronously and to run execute directly on Projects::DestroyService.

Closes #17893
2016-08-11 15:36:35 -07:00
Z.J. van de Weg
91a7b9333b Incorportate feedback 2016-06-01 12:10:08 +02:00
Zeger-Jan van de Weg
3bdc57f0a7 Create table for award emoji 2016-05-06 10:47:11 +02:00
Douglas Barbosa Alexandre
100e3e7601 Fix sorting issues/mrs by votes on the groups page
The `non_archived` scope applied here
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/controllers/conc
erns/issues_action.rb#L5 overrides the previous `ORDER BY` applied
inside the IssuesFinder, with the default scope of the Project model,
resulting in SQL errors.
2016-03-21 17:01:38 -03:00
Robert Speicher
a7c4d0da8c Make the /groups route behave as expected
The route is supposed to redirect the Groups#index request based on
whether or not a user was logged in. If they are, we redirect them to
their groups dashboard; if they're not, we redirect them to the public
Explore page.

But due to overly aggressive `before_action`s that weren't excluding the
`index` action, the request always resulted in a 404, whether a user was
logged in or not.

Closes #12660
2016-01-23 16:10:13 -08:00