6.0.0-git
2021-01-18

[#14025] ActiveSync AlphanumericDevicePasswordRequired permission not saved
Summary ActiveSync AlphanumericDevicePasswordRequired permission not saved
Queue Horde Groupware Webmail Edition
Queue Version 5.2.3
Type Bug
State Resolved
Priority 1. Low
Owners mrubinsk (at) horde (dot) org
Requester marc.cheptea (at) spamina (dot) com
Created 2015-06-24 (2035 days ago)
Due
Updated 2015-06-24 (2035 days ago)
Assigned 2015-06-24 (2035 days ago)
Resolved 2015-06-24 (2035 days ago)
Milestone
Patch No

History
2015-06-24 17:34:47 Michael Rubinsky State ⇒ Resolved
 
2015-06-24 17:12:12 Michael Rubinsky Comment #6 Reply to this comment
This should still work. The change from false to '' as the array key 
was only needed for the UI to work correctly. The code in Horde_Perms 
that performs the actual permissions assignment still checks with 
empty() so this will still work. The change in Horde_Perms was to 
allow a string '0' to be accepted as a non-empty value.

2015-06-24 16:52:46 marc (dot) cheptea (at) spamina (dot) com Comment #5 Reply to this comment
In my API implementation I'm passing these values as 'false' when I 
want them disabled. This change will probably break my implementation 
unless the empty string '' is automatically evaluated as 'false'.

I think this will have negative effects for any custom module. It 
would be good have some sort of backwards compatibility.

Please correct me if I'm wrong.

Regards,
Mark

[Show Quoted Text - 14 lines]
2015-06-24 16:43:31 Git Commit Comment #4 Reply to this comment
Changes have been made in Git (FRAMEWORK_5_2):

commit faa0b5a7b431e2c282f5aa667cd033711ff631cf
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date:   Wed Jun 24 12:31:54 2015 -0400

     Use string array keys.

     Remaining fix for Bug: 14025

  horde/lib/Application.php |   22 +++++++++++-----------
  1 files changed, 11 insertions(+), 11 deletions(-)

http://github.com/horde/horde/commit/faa0b5a7b431e2c282f5aa667cd033711ff631cf
2015-06-24 16:32:36 Git Commit Comment #3 Reply to this comment
Changes have been made in Git (master):

commit e82250e4a2d28e0464ad26f3d6affb5ae51d80b2
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date:   Wed Jun 24 12:31:54 2015 -0400

     Use string array keys.

     Remaining fix for Bug: 14025

  horde/lib/Application.php |   22 +++++++++++-----------
  1 files changed, 11 insertions(+), 11 deletions(-)

http://github.com/horde/horde/commit/e82250e4a2d28e0464ad26f3d6affb5ae51d80b2
2015-06-24 16:32:31 Git Commit Comment #2 Reply to this comment
Changes have been made in Git (master):

commit 6697c620ead20833d8ca077f64e4cc26ed1ad8d8
Author: Michael J Rubinsky <mrubinsk@horde.org>
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
2015-06-24 14:48:20 Michael Rubinsky State ⇒ Assigned
 
2015-06-24 14:48:06 Michael Rubinsky Assigned to Michael Rubinsky
 
2015-06-24 08:14:54 marc (dot) cheptea (at) spamina (dot) com Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Summary ⇒ ActiveSync AlphanumericDevicePasswordRequired permission not saved
Queue ⇒ Horde Groupware Webmail Edition
Milestone ⇒
Patch ⇒ No
Reply to this comment
The "horde:activesync:provisioning:AlphanumericDevicePasswordRequired" 
permission allows 3 possible values [0,1,2].

When saving a group or user with the option [0] the group/user is not 
saved. The other options [1,2] are saved properly.

I was able to reproduce this bug on the 'horde/admin/perms/' view and 
trough an API I am currently building for Horde. For the API I am 
using the Horde_Perms class to handle/persist the permissions.

I tested this issue in Horde 5.2.3. However after looking at the 
source code for on GitHub 
(https://github.com/horde/horde/blob/3aff0b0dfcfb190e307b3dc01edfa87d4baaacc9/horde/lib/Application.php#L241) I think this problem still exists in the latest 
version.

The problem I think is caused by the zero [0], which is treated by the 
permission class as false/null. Which in turn determines the 
group/user not to be persisted in the permission.

Saved Queries