A customer noted that the 'invite' email is not styled at all, and provides very little information. We should improve the style, similar to what we've done with the confirmation email. There may be other email templates that would benefit from the same treatment.
@awhildy Does this need UX input? We recently restyled some other emails so maybe we can re-use that design? We need to improve the copy here, for sure.
This is for an important customer, so please let me know what work will be required of UX. After that, I can talk with developers to see how much work it will be to implement. Thanks for your help.
@dblessing: I believe @dimitrieh and @hazelyang helped out with the new CI emails (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6019). I suspect we can base the design on a similar template (in terms of style, header, footer), and then make the message more visual and compelling by adding meta information to who invited you (avatar), the group they are inviting you to (avatar of group, group description, maybe # of people in group, or other information we show here: https://gitlab.com/dashboard/groups), and make the call to action of Accept/decline more obvious. @dimitrieh: does that make sense to you? Thoughts?
Looks really nice @dimitrieh! However, it doesn't really provide any additional information. But maybe that is ok? Maybe just being styled more like our other emails makes it feel more trustworthy? Definitely is a good first step. Perhaps we implement this, and see if additional confusion comes up, and if so, look into if there is other information to provide as suggested from the customer.
@awhildy Even though there's not a lot more information, the styling helps to identify that it's GitLab that we're emailing about. Also, the URL at the bottom helps to identify the specific instance. Maybe there are other things we can add, too, though.
@dblessing What did you think about the manage subscriptions link, should that even be in this url (i copied it over from the other templates)
I think keeping things simple is nice and should be our focus, still
Other things we could potentially add are:
administrator/invitee avatar?
group avatar?
group description to give more information what that group is?
public/private group?
if your invite is temp (include this info?)
We have project invites as well of course.. so what about:
project avatar
project description
public/private etc
if your invite is temp (include this info?)
As a sidenote to this, perhaps we could vouch for an additional feature to be able to include a personal message when inviting someone. (Like on linked in etc)
First of all, thank you for raising an issue to help improve the GitLab product. This issue was labelled as a ~"feature proposal" in the past. In order to maintain order in the issue tracker, we are starting to close off old, unpopular feature proposals that have not gained many votes since opening.
This issue will be marked for closure, as it meets the following criteria:
Created over 1 year ago
Labelled as a ~"feature proposal"
Unscheduled (not associated with a milestone)
Less than 10 upvotes
Thanks for your help and please raise any new feature proposals as a new issue.
Sure, go ahead and assign me this issue, @victorwu ! If I have any problems/questions before I get started I'll ask them here. As per your comment on #46836 (closed) I'm assuming we will have separate issues for each email Gitlab sends, or shall they all be grouped into one?
That sounds great @edstub207 ! Thanks for getting started here.
Let's work on each email in separate issues and merge requests, so that we can make sure your work is merged in quickly one by one, and everyone in the GitLab community and GitLab users will be able to enjoy your updates sooner. I'll be sure to work with the team here at GitLab to get those issues scoped out as soon as possible.
That's how I'm understanding it currently but wanted to double check first.
I did create a branch but I've ended up getting lost, is anyone able to give some pointers on what needs to be done? I am new to contributing with Gitlab and this is my first major task. I have done bug fixes in the past, mainly on the about.gitlab.com side of things.
@edstub207 If you've got the GDK set up and running so you can log in to your dev instance you can check the emails that have been sent by navigating to:
I sent off a couple of project invites by inviting random email addresses to a test project on the GDK instance and they show up here. I checked that the invite email wasn't looking as good as the pipeline emails as you noticed.
I then changed the Emails::Members#member_invited_email method as follows to use the same layout as the pipeline email and restarted the server.
defmember_invited_email(member_source_type,member_id,token)@member_source_type=member_source_type@member_id=member_id@token=tokenmail(to: member.invite_email,subject: subject("Invitation to join the #{member_source.human_name}#{member_source.model_name.singular}"))do|format|format.html{renderlayout: 'mailer'}format.text{renderlayout: 'mailer'}endend
Now the emails are starting to look better:
Hopefully that should be enough to get you started. Please feel free to reach out with more questions.
How can I gracefully quit Gitlab/Restart? I'm using the Ubuntu Windows Subsystem. At the moment I quit out via the exit on Windows and then can't restart because processes are still running on the port (At least that's how I understand the error) then restarting Ubuntu doesn't kill those process.
It looks like you've already created the branch in your fork, so you can checkout the branch in your working directory (gitlab-development-kit/gitlab):
Thanks for that @markglenfletcher. Is there a way for branches to be auto deployed to a specific environment for testing? My PC struggles running the server so if I worked on the branch and it deployed to a testing environment (Even on my own URL for example) that might work. You can do something similar with about.gitlab.com - https://gitlab.com/gitlab-com/www-gitlab-com#review-apps
Are you aware of a configuration that could do this?
@markglenfletcher Any idea if an open issue exists for that? Would be interested in following progress made.
As for this specific issue, I am getting currently debugging my environment setup so I can get everything working correctly.
At the moment, whenever I sync using GDK/My Fork it's fine. But once the whole process has been shut down after first use (even without code changes), I get build errors and have to reset my whole install again. I have verified that no tasks are left running in the background from the old instance/tried using the reconfigure command. At the moment this is blocking me from doing any work on this task. Any advice?
I don't think I had made any local changes or on the branch. Should the GDK Update and recongfigure commands force sync latest? I shall investigate further this evening, I wonder if it's something to do with using the Windows Linux Subsystem and opening files locally on my Windows PC. @markglenfletcher
Okay, so there is something funky happening when syncing with the Linux Subsystem. I deleted the file and re-synced using the guide here - https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/update-gdk.md and the members.rb file never returned but the instance launches fine now. I shall create an Ubuntu partition or VM and try that way for the time being. Thanks for your help with this @markglenfletcher
I have a VM Setup however, when running the `gdk install gitlab_repo=https://gitlab.com/edstub207/gitlab-ce.git' command I have a bunch of gem file errors. I followed the pre-requisite guide. Hopefully, once these issues are fixed I'll be able to get started. Any ideas what this problem is @markglenfletcher ? I've tried also running the commands in the errors separate with no luck.
Update (8th June): I tried updating/installing ruby gems manually and still have the same problem .
I think it might be better to move this onto someone else that has experience in ruby and gitlab's systems @markglenfletcher. I don't have much spare time to troubleshoot issues and don't understand all the systems/languages either ;(
Thanks @edstub207. Though I think we should try to get you up and running because contributing to the project is fun and there's loads of good stuff to work on.
Hey! I've just made some upgrades on my PC which should make this easier to do. I've been caught up with loads of stuff at work. But plan on attacking this during my week off towards the end of the month. Is that okay? @markglenfletcher
Hey @markglenfletcher I've tried taking a look at this again over the past few days! I've ended up having to go back to square one as all of my GDK environments stopped working/where deleted. I'm still having a bunch of issues getting things running. I think this should be re-assigned to someone else who knows what they are doing, I don't think I'll be able to get things working/complete this week. I'm then not going to have time for a few months to look into it as work is in a busy period.
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.
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?
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?