Search based on when an issue or pull request was created, closed, merged or last updated

Description

It would be great if we can search using dates to search states like created, closed and updated.

Proposal

What I'm proposing is some similar to this: author:@mdbs99 closed:2017-03-1..2017-03-10

In that example the system will search the state closed between 2017-03-1 and 2017-03-10

Links / references

See Github's article about searching here.

@mdbs99 Thanks for the proposal

@victorwu @cperessini Are these filters in the plans?

added ~874211 feature proposal ~14281 ~13921 labels

These sound like great additions, but I think our backend may not be ready to support them yet. Are we prioritizing other types of filter work first @victorwu?

Guys, today I can get that closed issues list by another way?

Perhaps using API (I have plans to use it)?

My team needs to know how many tickets we've closed in a weeek, month, etc.

I think @ClemMakesApps created a similar issue before.

@mdbs99 : Could you chat about how you would use something that has pretty refined search criteria like this? Thanks!

Yeah @victorwu of course.

So, one of the companies where I work, is trying to migrate their Issues to GitLab.

Today we use a software made in home. In this software we generate some spreadsheets and reports:

• how many issues were closed?
• how many issues per department? — we're using use labels
• how many issues per developer? and so on.

Many times we need to search who said something (but GitLab already has that).

But take a look in [this] (https://help.github.com/articles/searching-issues/#search-by-the-number-of-comments-an-issue-or-pull-request-has) for example: state:closed comments:>100 — Matches closed issues with more than 100 comments.

Pretty cool, hã?

Sometimes we search by title or body — maybe a syntax like state:closed title:blablabla

But more important to us is all about dates (closed and updated).

@mdbs99 It is currently possible to gather this information via the API, but you will have to combine the data you retrieve from the issues and events APIs.

• The issues API will give you the overview of the issue (status, assignee, etc)
• The events API will let you tie back the events associated with the issue
• Timestamp of Closure event

@markglenfletcher you mean this events?

Maybe only The issues API will be enough... but I will take a look about events too, thanks.

I created something like this issue but it was closed and I didn't have time to follow up and re-open it. I think that there should be something in the UI to allow users to search issues or MRs based on date ranges because this isn't that advanced of a feature imo

@ClemMakesApps thanks for the feedback. So would something like this be more feasible sooner than say the Boolean logic (which requires BE work)?

@cperessini : In your estimation, is there something UX wise we could that wouldn't make this too complicated to use? If we start having weird date picker interactions, it could get messy really fast.

I think so, but it's almost all backend work @victorwu. So I'll defer to @smcgivern for estimates

@victorwu we could offer suggestions for formatting and/or date values in a list style. That way you can still perform this type of query with your mouse and it doesn't get overly complicated. Think the iOS date picker:

I am definitely not suggesting we make something like this, though. I think since you would still be able to type in a date it'd be a different type of situation.

@victorwu @ClemMakesApps the backend is actually pretty easy for this, if we decide exactly what params we want.

I tried to see how it would go if I searched for all issues I could see that were created in 2016 (so as if I did this search on the dashboard, with no other filters): https://explain.depesz.com/s/5zYd

It performed a sequence scan to get rid of those issues, but compared to the awfulness in the rest of the query, that actually looked relatively efficient by comparison. It also looks like it reduced the row count for the other painful parts, which might be a trade-off worth taking.

@yorickpeterse wdyt? I don't want to add a filter that's going to hurt us, but this actually seems much better behaved than some of the other filters, like labels Having said that, 'not the worst' doesn't necessarily mean it's good.

this actually seems much better behaved than some of the other filters, like labels

@smcgivern, just a side question: Why labels are not a good choice to search?

@smcgivern We first really need to get that query under control size wise before we add any extra filters, even if it's just so we can actually understand what the hell the query does.

@mdbs99 see https://gitlab.com/gitlab-org/gitlab-ce/snippets/1654799

@yorickpeterse fair point. I think I understand it, but I'm probably wrong. There is a lot of repetition.

@victorwu I've rewritten the description of https://gitlab.com/gitlab-org/gitlab-ce/issues/25504 with some options here.

@smcgivern WTf... https://gitlab.com/gitlab-org/gitlab-ce/snippets/1654799 that's insane!!

moved to gitlab#8748

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue