Show expiring date in addtion to countdown date for Expiration date on Memberships feature
Description
Once an expiration date is assigned to an individual or group member, clarity as to the actual date of expiration is lost when only showing a relative duration. This makes it difficult to compare the "countdown timer" in GitLab vs a specified expiration date such as it would be specified in a license agreement or contract.
In my org's use-case, we are performing several thousand group-project shares that require an expiration. Seeing only the remaining relative time obscures the contract specified dates.
Proposal
On the Share project with other groups page, immediately after where the countdown time is for each individual / group share, show the actual date of expiration.
The current one doesn't look like clickable. Change the "remove" button to look like a button.
| Current | Proposed |
|---|---|
 |
 |
Links / references
Activity
mentioned in issue #21619 (closed)
Added feature proposal user management labels
-
Can we get an update on this? A customer reached out to us voicing their frustration that this hasn't received feedback. /cc @DouweM @mydigitalself
Edited by Cindy Pallares 🦉 I think it makes sense to show "expires on March 10, 2017" instead of "Expires in one day".
/cc @mydigitalself
@DouweM not a ~Frontend issue?
@mydigitalself You're right, I guess it is!
added frontend label
@tauriedavis @sarahod : There must be many usability arguments / studies that talk about showing absolute timestamps versus relative ones in different contexts. Usually it's timestamps that happened in the past. This one is looking forward into future. Can you give us some guidance here? Show both? Show one or the other? Show one or the other upon some UX interaction? Also an opportunity to establish some GitLab app-wide design guidance if it hasn't already been done.
Edited by Victor Wu@victorwu (cc @tauriedavis) The problem with a relative timestamp is that it forces a user to manually calculate when the membership actually expires. From the research studies I've done so far, there have been a lot of people who use GitLab with third party contractors, customers, etc. I'd imagine most projects have an estimated completion date and subsequently, you'd potentially want to expire the memberships of contractors, customers, etc around the same date. Therefore, the ability to set and view the actual date you want the membership to expire makes complete sense.
However, it's always good to have additional visual cues as to when something is expiring. Some UX examples: a credit card on file is due to expire, the last date for ordering an item is fast approaching, a sale is ending and so on. The thing they all have in common is urgency/immediacy - they're all happening in the next few days. If you show a visual cue too far in advance it becomes redundant and doesn't prompt any action.
I'd propose showing the actual date and as the date approaches, introduce a countdown/absolute timestamp. For example, 'Expires in 7 days'. We don't necessarily know whether a user will need to take action and amend the expiry date of the membership, however, a reminder doesn't hurt.
Edited by Sarah O'DonnellThanks @sarahod . That's a really good explanation. @tauriedavis : If we get a simple design here, I think we can make this an Accepting Merge Requests feature.
Cc @hazelyang I think this is a quick one to take a look at
Edited by Taurie Davischanged milestone to %Next 2-3 months
added Platform label
moved to gitlab#6030
Hey!
GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current
gitlab-cerepository will become a read-only mirror, without any proprietary code. All development is moved to the currentgitlab-eerepository, which we will rename to justgitlabin the coming weeks. As part of this migration, issues will be moved to the currentgitlab-eeproject.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/13855You 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/13855What 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 theee/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/13304Will 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.
