Share Dialog Problems repeating user list #18910

Closed
gig13 opened this Issue Sep 8, 2015 · 39 comments

Projects

None yet
@gig13
gig13 commented Sep 8, 2015

Steps to reproduce

  1. Try to add an individual to a share
  2. An error is thrown and the same group and individuals are listed over and over in the share dialog
    3.

Expected behaviour

You should be able to add a user to a share

Actual behaviour

An error occurs and the groups/individuals are listed over and over again
See additional info on s3 https://s3.owncloud.com/owncloud/index.php/apps/files?dir=%2FShared%2Fowncloud%2Fsupport%2Fgithub-issues%2Fcore%2F18910

Server configuration

Operating system: CentOS 6

Web server: Apache

Database: MySQL

PHP version: 5.5

ownCloud version: 7.0.8

Updated from an older ownCloud or fresh install: Updated

List of activated apps:

Are you using external storage, if yes which one: NO

Are you using encryption: NO

Are you using an external user-backend, if yes which one: AD

@MorrisJobke

@gig13 gig13 added the blue-ticket label Sep 8, 2015
@MorrisJobke MorrisJobke added the sharing label Sep 9, 2015
@MorrisJobke
Member

To make this easier to understand:

folder structure:
\main
\main\sub

users:
Alice

/main is shared with nobody. /main/sub is shared with Alice. Alice has access to /main/sub only. Now Alice gets also /main shared and has an additional share main that also contains sub.

This works fine, but is not really wanted, because the subshare should be merged with the parent share.

So the share dialog not handling this situation elegantly is one part of the problem. The bigger problem is that the re-share became invalid when Alice was added to the parent share. Either Alice need to not be allowed to be added to the parent share with a message explaining why, or they need to be removed from the all child shares with a message explaining what will happen after clicking ok.

This is server 7.0.8. The shares were made under 7.0.7. Perhaps this is handled better in OC 8.1. We are trying to get some things out of the way so we can upgrade in the coming weeks. In any case, the fix is to find the rows in oc_share related to the child re-share and remove them.

@schiesbn @MTRichards Is this something we want?

@MorrisJobke
Member

Maybe this also gets better with the simplified sharing? See #9058 which is planned for 9.0

@MTRichards
Contributor

This is one of those areas we have discussed, but punted on because the answer can depend on the scenario.

In your example, if /main/sub share is removed because /main replaces it, what happens when the user is removed from /main at a later date? Do they get added back to /main/sub, or is it all lost? Or if they get added to /main/sub after being in /main?

In my head, if you are added to a share for a parent folder, you should not also show the child folder - but the child should be remembered in case you are removed from the parent. For example, if you are removed from /main, and you are still shared with /main/sub, the user should then just see /main/sub again. In other words, the parent always overrules the child. This avoids duplicate disk space usage, and is what I would expect as a user. In a similar manner, if you are shared /main and later main/sub, main/sub does not show anything new. If you are removed from /main, you still see /main/sub.

If the sharing gets updated as above, re-sharing just adds users to sharing, so this is easier to manage.

@jancborchardt interested in your UX take on this.

@jancborchardt
Member

In my head, if you are added to a share for a parent folder, you should not also show the child folder - but the child should be remembered in case you are removed from the parent.

@MTRichards exactly what I was thinking.

@MTRichards
Contributor

Oh, but it gets harder actually. There is the issue of permissions now too.

SO, the permissions should be additive. So, if you are shared the /main/ as full control, and /main/sub as red only, you have full permissions on /main now as well as /main/sub.

If you get shared /main/sub as full control, but /main as read only, you still have /main as read only, and /main/sub as full control.

And now it gets all sorts of fun... 😄

@schiessle
Member

Oh, but it gets harder actually. There is the issue of permissions now too.
SO, the permissions should be additive.

We do this if we group shares. Let's say for example you share /main with the group "users" read only, and /main with "user1" (who is a member of the group "users") with full permissions, then "user1" will see the folder /main only once and will have full permissions.

But I don't think we can do this for independent shares because this will become to complex and time consuming. Basically we would have two options:

  • calculate the permissions when the file gets shared. But then we would have to re calculate them every time a share gets changed/added Which would mean walking the tree down beginning at the changed file and check/update all shares for the children (probably also the re-shares). -> way to expensive.
  • calculate the permissions when the share gets mounted. This would mean that we would need to walk the tree up every time a share gets mounted (every request) and also keep re-shares into account -> again way to expensive.

As both folders (/main and main/sub) will show up as individual mounts I think it is OK to keep the different permissions.

Maybe in the long run we could group them and support that permissions could change for files/folders within a shared folder... @rullzer Maybe something we can think about as a feature after sharing 2.0, depending on complexity?

@gig13
gig13 commented Sep 24, 2015

@schiesbn @MTRichards @MorrisJobke @bboule
Any updates?
This is a fantastic discussion, but what do I communicate back?

@MTRichards
Contributor

This is currently not in for 9.0, so the earliest we can get to this - and this is pretty deep in core - is 9.1.

@bboule
bboule commented Sep 24, 2015

OK so we will communicate that info @cmonteroluque or @DeepDiver1975 would it be possible to add a 9.1 milestone for tracking purposes?

@MorrisJobke MorrisJobke added this to the 9.1-next-next milestone Sep 24, 2015
@MorrisJobke
Member

OK so we will communicate that info @cmonteroluque or @DeepDiver1975 would it be possible to add a 9.1 milestone for tracking purposes?

Done. But only added to core.

@cmonteroluque
Contributor

ok, will add across the board

@MorrisJobke
Member

ok, will add across the board

I would just keep it just in core to not confuse too much, or do we need it elsewhere too?

@MorrisJobke MorrisJobke was assigned by bboule Jan 5, 2016
@bboule bboule added the in progress label Jan 6, 2016
@MorrisJobke
Member

@gig13 Can I ask you about the status of this? Maybe the customer has upgraded and the issue is somehow fixed. If this is still an issue I would really like to see the corresponding oc_share entries for that share and all child entries (where ID of that share is set as parentID). Maybe that helps to identify the actual cause here.

@gig13
gig13 commented Jan 13, 2016

@MorrisJobke
I am checking if this is still an issue

@gig13
gig13 commented Jan 19, 2016

@MorrisJobke
Will re-open if its still an issue.

@MorrisJobke
Member

@MorrisJobke
Will re-open if its still an issue.

Okay.

@MorrisJobke MorrisJobke removed this from the 9.1-next milestone Jan 27, 2016
@DeepDiver1975 DeepDiver1975 added this to the 9.1-next milestone Jan 27, 2016
@MorrisJobke MorrisJobke removed this from the 9.1-next milestone Jan 29, 2016
@MorrisJobke MorrisJobke removed their assignment Jan 29, 2016
@gig13
gig13 commented Feb 2, 2016

Here is more information:
On s3 an excel spreadsheet in xml form for the following sql query:
SELECT * FROM owncloud.oc_share where (file_target like '%FieldGTS%' or file_target like '%GTS_Software%') and uid_owner = 'CEFB1C14-1C89-4BB7-97BE-A7F08962A631';

The uid_owner is our GTS (Global Technology Services) department account. There is a folder at the root of that account called FieldGTS that is shared with 4 people. There is a subfolder in that account called GTS_Software that is shared with a bunch of other people as individuals, not via group membership. When looking at the share dialog on GTS_Software the names of the 4 people from the parent FieldGTS folder appear over and over, 33 times to be exact. There are 32 other individuals listed on GTS_Software.

Something in the loop that generates that text and produces the names from the parent appears to be inside another loop that iterates through the recipients on sub folder share. You then end up with a massive string coming back to the browser through the ajax requests used for this dialog which it dutifully displays.

One thing that's very interesting is the file_target column for one row says /Shared With Me/GTS_Software instead of just /GTS_Software. There is no folder called Shared With Me in the account. The id numbers in item_source, item_target and file_source all match the other GTS_Software entries.

@gig13 gig13 reopened this Feb 2, 2016
@MorrisJobke
Member

All the user names are different. I think this is a problem at their LDAP setup (I suspect that this is a LDAP env). Could I ask you to get following information:

SELECT * FROM oc_ldap_user_mapping WHERE owncloud_name IN ("0643E83D-F9F1-44F1-82C1-482DF3C16A48", "18DAA821-5081-4ADD-B330-28343F5A32B9", "2302BA31-35C3-4C25-BFA6-82CEB6D3FB70", "2606A3D7-0449-428C-8BEB-874F255B2380", "271120A6-C420-45ED-9F84-67803DB9ED5E", "3649BDA1-F18F-4E5B-AD9B-1A05AA36BDF8", "3729D1EB-E5AC-4EF4-B0C5-9E4FE88C5BA5", "3B0D6D76-B2F5-45A9-B692-E03F508315EF", "425CE690-EEF4-4915-A35B-2E6B01B80EBD", "538FB331-371F-4DFB-96C2-6863E19FF466", "79532ED1-E60B-45BB-A337-AB418F14B6A1", "7C450114-8614-4F17-B7C7-97941C1762C8", "7D191601-D6A0-4412-9CB1-D9C90022C788", "874B35EF-C4A9-4D5F-ADFB-57AB69AD95EA", "8F5503CF-E56C-4CEF-937B-A7D937AE6CD6", "99B710EA-4BC6-4C58-87D6-104D2906E8BB", "A3720321-D2F5-446E-8DDA-5AFFF9A50E0A", "A5E829A6-1048-4E34-8751-7CE1F7098CF8", "A70374A6-CA9E-4B80-B469-000667C2F4B8", "AA39EC6B-0B22-4113-867F-D7426D70B42C", "B56C8DB6-2119-43AB-B953-E1CEF92C3B44", "C5995D88-8E42-42A7-9A28-4C5C1F5D1865", "CD724CE8-630C-4DA9-BCF2-BFA33C8246CE", "D22D74C9-47E8-4A65-97CC-644187726A34", "D77CEC4B-3E1D-4709-9FED-C0AAEC8D66D7", "D8605443-5233-45D3-8DAC-73944306C032", "E5EA7043-F625-43B2-95E7-F66730AB9FAA", "E677EFFA-BA39-46BA-AD1F-9967369687F0", "E7F61639-D0CB-4D02-8413-C956ADF45A21", "EB79DBA6-C5BF-488F-953E-1C94B2A8FC23", "ECBBD880-516F-4B48-9472-05A6827EED70", "FA8B8489-5BBE-4D22-8EAA-5129062C1F9A");
@gig13
gig13 commented Feb 3, 2016

Results on s3 in users.xml

@MorrisJobke
Member

I just checked the output and those are 32 different users (at least they have different CNs). I guess those are the ones that are intentionally there. (you wrote at least this)

What are the 4 people that are listed more than once? And it's kind of weird that the count of duplication (32 duplicate entries + 1 original share) is exactly the count of other share recipients (32 other shares).

Could I ask you to request the share information for the parent folder (FieldGTS) too?

@MorrisJobke
Member

@gig13 Or maybe it's better to arrange a screen sharing with them.

@gig13
gig13 commented Feb 4, 2016

@MorrisJobke Agreed, I already proposed a "system review" for upgrading to OC8.2.2, so we will likely have a screen share next week.

@gig13
gig13 commented Feb 24, 2016

@MorrisJobke -- Trying to coordinate a screen share for Friday -- can also review setup/system

@MorrisJobke
Member

@MorrisJobke Ajax response on s3

The request against the share.php had following attributes:

bildschirmfoto 2016-02-29 um 15 20 14

The response already contained the duplicated entries in the share list of the ajax response. This means those entries are coming in via https://github.com/owncloud/core/blob/0f2010d8c3eff24aca5b761612ba423e5cdc06ad/core/ajax/share.php#L227-L233

The database only contained one entry per user for the parent folder.

Folder structure: A/B/C

A was shared to user1, user2, user3. C was shared to user4, user5, user6, user7, user8, user9. When opening the share dialog for C there is a sentence like this:

bildschirmfoto 2016-02-29 um 18 09 45

But on this instance the sentence was "Shared in A with user1, user2, user3, user1, user2, user3, user1, user2, user3, user1, user2, user3, user1, user2, user3, user1, user2, user3". They are repeated as often as this subfolder has shares (6 in this example - user4 to user9).

@rullzer @schiesbn Do you have any idea how this could happen? Should we add a deduplication step into the getItems() method? I thought @nickvergessen added something like this for 8.2 but I couldn't find it anymore.

@rullzer As we moved to OCS API I think this is not possible with the share 2.0 anymore, right?

@gig13
gig13 commented Feb 29, 2016

@MorrisJobke Cust response --

"I've been using the newer $userManager->listen style with a callable as in https://doc.owncloud.com/server/8.1/developer_manual/app/hooks.html.

I can't find the docs referring to using the Util::connectHook method. From what I can see in the code they don't overlap at all, one is not a wrapper for the other. So it looks like I need to provide a function name to connectHook as a string rather than a variable holding a closure style function. Is that correct?

I'm guessing this is what Morris was referring to when he said this is fixed in 8.2. If the newer style works fine in 8.2 I'll wait until then rather than implementing the older style.

I'd not specified any type in my info.xml so that would have been part of my problem too. Even with that set to logging or prelogin it doesn't work with the listen style of connecting to hooks.

@MorrisJobke
Member

@gig13 I created a separate ticket for the hooks issue: #22743

@gig13
gig13 commented Mar 9, 2016

@MorrisJobke More information that I may have missed... or was discussed on the call

In addition to repeating the names of the people on the parent share over and over, it repeats their objectGUIDs (the owncloud internal username for an AD backed deployment) in the ajax request for searches. Normally that request includes the users who are already recipients of the share as well as those who are recipients of and parent folders to avoid double sharing. But the loop that causing the cosmetic repetition of the names in the browser is also looping over their guids and adding them to the GET request when searching for a user.

On one of our shares it's resulting in a GET request exceeding 4.5KB. Our F5 device is blocking the request but it works when directly connected to the web servers which is how I found the problem. The F5 is preventing the request from getting to the web server entirely. I've asked that the limit be raised because there are legitimate reasons why the request could grow (many individual users in a share and on parent folders) but this bug doesn't help.

would it be better for the ajax request to not include the users already on the share but for the server to ping the database to determine that information. There is a limit on the maximum size of a GET request and that limits the total number of people who can be recipients on an item and any parent items which isn't what users would expect.

Here's a sample of this particular GET request. The earlier guids are the recipients of the share itself. The looping over the same guids appears a little way down and that matches the recipients of the parent folder.

GET /index.php/core/ajax/share.php?fetch=getShareWith&search=lute&limit=200&itemShares%5B0%5D%5B%5D=79532ED1-E60B-45BB-A337-AB418F14B6A1&itemShares%5B0%5D%5B%5D=7752DD35-C09C-4D38-9E68-56A9944A8422&itemShares%5B0%5D%5B%5D=AA39EC6B-0B22-4113-867F-D7426D70B42C&itemShares%5B0%5D%5B%5D=271120A6-C420-45ED-9F84-67803DB9ED5E&itemShares%5B0%5D%5B%5D=A70374A6-CA9E-4B80-B469-000667C2F4B8&itemShares%5B0%5D%5B%5D=FA8B8489-5BBE-4D22-8EAA-5129062C1F9A&itemShares%5B0%5D%5B%5D=3649BDA1-F18F-4E5B-AD9B-1A05AA36BDF8&itemShares%5B0%5D%5B%5D=99B710EA-4BC6-4C58-87D6-104D2906E8BB&itemShares%5B0%5D%5B%5D=E7F61639-D0CB-4D02-8413-C956ADF45A21&itemShares%5B0%5D%5B%5D=D22D74C9-47E8-4A65-97CC-644187726A34&itemShares%5B0%5D%5B%5D=D77CEC4B-3E1D-4709-9FED-C0AAEC8D66D7&itemShares%5B0%5D%5B%5D=E5EA7043-F625-43B2-95E7-F66730AB9FAA&itemShares%5B0%5D%5B%5D=8FE000C6-30DB-4BBA-82CA-BA88E272CC68&itemShares%5B0%5D%5B%5D=5C72DA39-F69C-4E53-A9F7-3C57B70CB40D&itemShares%5B0%5D%5B%5D=2E097ABD-564D-4DCE-BD79-D7B856E43122&itemShares%5B0%5D%5B%5D=19875988-1856-477B-AD61-63F8BE78C199&itemShares%5B0%5D%5B%5D=4C97800D-3B75-43B0-A142-6DAFF18C4BE4&itemShares%5B0%5D%5B%5D=8FE000C6-30DB-4BBA-82CA-BA88E272CC68&itemShares%5B0%5D%5B%5D=5C72DA39-F69C-4E53-A9F7-3C57B70CB40D&itemShares%5B0%5D%5B%5D=2E097ABD-564D-4DCE-BD79-D7B856E43122&itemShares%5B0%5D%5B%5D=19875988-1856-477B-AD61-63F8BE78C199&itemShares%5B0%5D%5B%5D=4C97800D-3B75-43B0-A142-6DAFF18C4BE4&itemShares%5B0%5D%5B%5D=8FE000C6-30DB-4BBA-82CA-BA88E272CC68&itemShares%5B0%5D%5B%5D=5C72DA39-F69C-4E53-A9F7-3C57B70CB40D&itemShares%5B0%5D%5B%5D=2E097ABD-564D-4DCE-BD79-D7B856E43122&itemShares%5B0%5D%5B%5D=19875988-1856-477B-AD61-63F8BE78C199&itemShares%5B0%5D%5B%5D=4C97800D-3B75-43B0-A142-6DAFF18C4BE4&itemShares%5B0%5D%5B%5D=8FE000C6-30DB-4BBA-82CA-BA88E272CC68&itemShares%5B0%5D%5B%5D=5C72DA39-F69C-4E53-A9F7-3C57B70CB40D&itemShares%5B0%5D%5B%5D=2E097ABD-564D-4DCE-BD79-D7B856E43122&itemShares%5B0%5D%5B%5D=19875988-1856-477B-AD61-63F8BE78C199&itemShares%5B0%5D%5B%5D=4C97800D-3B75-43B0-A142-6DAFF18C4BE4&itemShares%5B0%5D%5B%5D=8FE000C6-30DB-4BBA-82CA-BA88E272CC68&itemShares%5B0%5D%5B%5D=5C72DA39-F69C-4E53-A9F7-3C57B70CB40D&itemShares%5B0%5D%5B%5D=2E097ABD-564D-4DCE-BD79-D7B856E43122&itemShares%5B0%5D%5B%5D=19875988-1856-477B-AD61-63F8BE78C199&itemShares%5B0%5D%5B%5D=4C97800D-3B75-43B0-A142-6DAFF18C4BE4&itemShares%5B0%5D%5B%5D=8FE000C6-30DB-4BBA-82CA-BA88E272CC68&itemShares%5B0%5D%5B%5D=5C72DA39-F69C-4E53-A9F7-3C57B70CB40D&itemShares%5B0%5D%5B%5D=2E097ABD-564D-4DCE-BD79-D7B856E43122&itemShares%5B0%5D%5B%5D=19875988-1856-477B-AD61-63F8BE78C199&itemShares%5B0%5D%5B%5D=4C97800D-3B75-43B0-A142-6DAFF18C4BE4&itemShares%5B0%5D%5B%5D=8FE000C6-30DB-4BBA-82CA-BA88E272CC68&itemShares%5B0%5D%5B%5D=5C72DA39-F69C-4E53-A9F7-3C57B70CB40D&itemShares%5B0%5D%5B%5D=2E097ABD-564D-4DCE-BD79-D7B856E43122&itemShares%5B0%5D%5B%5D=19875988-1856-477B-AD61-63F8BE78C199&itemShares%5B0%5D%5B%5D=4C97800D-3B75-43B0-A142-6DAFF18C4BE4&itemShares%5B0%5D%5B%5D=8FE000C6-30DB-4BBA-82CA-BA88E272CC68&itemShares%5B0%5D%5B%5D=5C72DA39-F69C-4E53-A9F7-3C57B70CB40D&itemShares%5B0%5D%5B%5D=2E097ABD-564D-4DCE-BD79-D7B856E43122&itemShares%5B0%5D%5B%5D=19875988-1856-477B-AD61-63F8BE78C199&itemShares%5B0%5D%5B%5D=4C97800D-3B75-43B0-A142-6DAFF18C4BE4&itemShares%5B0%5D%5B%5D=8FE000C6-30DB-4BBA-82CA-BA88E272CC68&itemShares%5B0%5D%5B%5D=5C72DA39-F69C-4E53-A9F7-3C57B70CB40D&itemShares%5B0%5D%5B%5D=2E097ABD-564D-4DCE-BD79-D7B856E43122&itemShares%5B0%5D%5B%5D=19875988-1856-477B-AD61-63F8BE78C199&itemShares%5B0%5D%5B%5D=4C97800D-3B75-43B0-A142-6DAFF18C4BE4&itemShares%5B0%5D%5B%5D=8FE000C6-30DB-4BBA-82CA-BA88E272CC68&itemShares%5B0%5D%5B%5D=5C72DA39-F69C-4E53-A9F7-3C57B70CB40D&itemShares%5B0%5D%5B%5D=2E097ABD-564D-4DCE-BD79-D7B856E43122&itemShares%5B0%5D%5B%5D=19875988-1856-477B-AD61-63F8BE78C199&itemShares%5B0%5D%5B%5D=4C97800D-3B75-43B0-A142-6DAFF18C4BE4&itemShares%5B0%5D%5B%5D=8FE000C6-30DB-4BBA-82CA-BA88E272CC68&itemShares%5B0%5D%5B%5D=5C72DA39-F69C-4E53-A9F7-3C57B70CB40D&itemShares%5B0%5D%5B%5D=2E097ABD-564D-4DCE-BD79-D7B856E43122&itemShares%5B0%5D%5B%5D=19875988-1856-477B-AD61-63F8BE78C199&itemShares%5B0%5D%5B%5D=4C97800D-3B75-43B0-A142-6DAFF18C4BE4&itemShares%5B0%5D%5B%5D=8FE000C6-30DB-4BBA-82CA-BA88E272CC68&itemShares%5B0%5D%5B%5D=5C72DA39-F69C-4E53-A9F7-3C57B70CB40D&itemShares%5B0%5D%5B%5D=2E097ABD-564D-4DCE-BD79-D7B856E43122&itemShares%5B0%5D%5B%5D=19875988-1856-477B-AD61-63F8BE78C199&itemShares%5B0%5D%5B%5D=4C97800D-3B75-43B0-A142-6DAFF18C4BE4&itemType=folder HTTP/1.1
@MorrisJobke
Member

would it be better for the ajax request to not include the users already on the share but for the server to ping the database to determine that information. There is a limit on the maximum size of a GET request and that limits the total number of people who can be recipients on an item and any parent items which isn't what users would expect.

This is the case in 9.0+ - or am I wrong @rullzer

@MorrisJobke
Member

Could we get some help from sharing people - @schiesbn @rullzer

@rullzer
Contributor
rullzer commented Mar 10, 2016

The server pinging the database is awefull for performance and does not properly scale.

However what happens in 9.0 is that we just request matching sharees from the Sharee API endpoint. Then we filter out the people we already shared with client side.

In the future we want to make this even more responsive by using #22438

@MorrisJobke
Member

But on this instance the sentence was "Shared in A with user1, user2, user3, user1, user2, user3, user1, user2, user3, user1, user2, user3, user1, user2, user3, user1, user2, user3". They are repeated as often as this subfolder has shares (6 in this example - user4 to user9).

@rullzer @schiesbn Do you have any idea how this could happen? Should we add a deduplication step into the getItems() method? I thought @nickvergessen added something like this for 8.2 but I couldn't find it anymore.

I could reproduce this on stable8.2 from today:

  • create a folder A
  • share A with user1, user2 and user3
  • create a folder A/B
  • share A/B with user4 ("Shared in A with user1, user2, user3" appears in the sidebar below the share input field)
  • share A/B with user5 (the text is expanded with ", user1, user2, user3")

Tested in IE11 and Firefox. Also after a reload it's the same.

After an upgrade to stable9 the text is completely gone.

@rullzer Could you see this too?

@cdamken
Contributor
cdamken commented Mar 15, 2016

after our remote session The customer asked the user to verify this issue with other browsers

The user tested IE10, IE11, Firefox 44 and Chrome 49 and could not add additional users to the share.

@butonic
Member
butonic commented Apr 13, 2016

@rullzor can you have a look please?

@butonic butonic added green-ticket and removed blue-ticket labels Apr 13, 2016
@MorrisJobke
Member

@rullzor can you have a look please?

@rullzer

@rullzer
Contributor
rullzer commented Apr 14, 2016

Yes I can reproduce on 8.2 lets see this dark magic in action

@rullzer
Contributor
rullzer commented Apr 14, 2016

OK, I have a quick fix. I really do not want to dive into share.php (you already made me look at the ajax code!!!). Basically the ajax/share.php now fitlters the list to unique shares.

@rullzer
Contributor
rullzer commented Apr 14, 2016

PR in #24008 please test and review

@rullzer
Contributor
rullzer commented Apr 19, 2016

PR is merged. closing this.

@rullzer rullzer closed this Apr 19, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment