Re: [commits] Horde branch master updated. e82250e4a2d28e0464ad26f3d6affb5ae51d80b2
Michael J Rubinsky <[email protected]>
| Newsgroups | gmane.comp.horde.devel |
|---|---|
| Message-ID | <20150624152938.Horde.4HhY7SkHM7sCJQuSI-HrZR9@h4.theupstairsroom.com> |
Quoting Michael J Rubinsky <[email protected]>: > Quoting Michael J Rubinsky <[email protected]>: > >> Quoting Michael J Rubinsky <[email protected]>: >> >>> Quoting Jan Schneider <[email protected]>: >>> >>>>> commit 6697c620ead20833d8ca077f64e4cc26ed1ad8d8 >>>>> Author: Michael J Rubinsky <[email protected]> >>>>> Date: Wed Jun 24 12:31:18 2015 -0400 >>>>> >>>>> Allow a string value of '0'. >>>>> >>>>> Part of fix for Bug: 14025 >>>>> >>>>> framework/Perms/lib/Horde/Perms/Permission.php | 5 +++-- >>>>> 1 files changed, 3 insertions(+), 2 deletions(-) >>>>> >>>>> http://github.com/horde/horde/commit/6697c620ead20833d8ca077f64e4cc26ed1ad8d8 >>>> >>>> How about checking for strlen() instead? >>> >>> I tried that, even when using strval() first, and it was still >>> taking it as an "empty" value. >> >> Though a quick test script shows that this should not be the case. >> I'll see if there was something else going on. > > Yeah, I think I tested that before changing the key values to be > strings in Horde :/ Updated in Git. This also takes an integer value of 0 and returns a length of 1, so this technically breaks previous behavior of allowing an integer value of 0 "clear" the permission. Not sure if that falls under the "previous behavior is broken, so it's ok" school of breaking BC or not.... -- mike The Horde Project http://www.horde.org https://www.facebook.com/hordeproject https://www.twitter.com/hordeproject -- dev mailing list Frequently Asked Questions: http://wiki.horde.org/FAQ To unsubscribe, mail: [email protected]
smime.p7s
(application/pkcs7-signature, 5.7 KB) - not displayed