Added X-GitLab-... headers to emails from CI and Email On Push services
Fixes#2098
This adds the 'X-GitLab-Project', 'X-GitLab-Project-Id' and
'X-GitLab-Project-Path' headers to emails from CI and Email On Push in a way
that it is done currently for merge requests and issues emails.
Additionally, CI emails will have 'X-GitLab-Build-Status' header with either
'fail' or 'success'.
Emails from Email On Push will include 'X-Gitlab-Author' header containing the
username of user who did the push.
See merge request !2159
some OAuth providers (kerberos for example) only provide a username and an email, but no name. Therefore
a signup fails because the name is empty. Best guess for the name is
probably the username, therefore use it as name.
This changes the format of metadata to handle paths, that may contain
whitespace characters, new line characters and non-UTF-8 characters.
Now those paths along with metadata in JSON format are stored as
length-prefixed strings (uint32 prefix).
Metadata file has a custom format:
1. First string field is metadata version field (string)
2. Second string field is metadata errors field (JSON strong)
3. All subsequent fields is pair of path (string) and path metadata
in JSON format.
Path's metadata contains all fields that where possible to extract from
ZIP archive like date of modification, CRC, compressed size,
uncompressed size and comment.
`StringPath` class is something similar to Ruby's `Pathname` class,
but does not involve any IO operations. `StringPath` objects require
passing string representation of path, and array of paths that
represents universe to constructor to be intantiated.
LDAP Sync blocked user edgecases
Allow GitLab admins to block otherwise valid GitLab LDAP users
(https://gitlab.com/gitlab-org/gitlab-ce/issues/3462)
Based on the discussion on the original issue, we are going to differentiate "normal" block operations to the ldap automatic ones in order to make some decisions when its one or the other.
Expected behavior:
- [x] "ldap_blocked" users respond to both `blocked?` and `ldap_blocked?`
- [x] "ldap_blocked" users can't be unblocked by the Admin UI
- [x] "ldap_blocked" users can't be unblocked by the API
- [x] Block operations that are originated from LDAP synchronization will flag user as "ldap_blocked"
- [x] Only "ldap_blocked" users will be automatically unblocked by LDAP synchronization
- [x] When LDAP identity is removed, we should convert `ldap_blocked` into `blocked`
Mockup for the Admin UI with both "ldap_blocked" and normal "blocked" users:
There will be another MR for the EE version.
See merge request !2242
Robert SpeicherandRobert Speicher
Douglas Barbosa AlexandreandRobert Speicher
Douwe MaanandRobert Speicher
Steffen Köhler
Grzegorz Bizon