User Groups / User Management

[pediehl]

If a user belongs to diffrent groups, there are only listboxes with all groups and no drop-down-boxes anymore. since 5.0.11 it is not possible anymore to manage the groups of a owncloud-user.

[salva86]

same here please help!

[Mathi0r]

same here after update from 5.0.10 to 5.0.11

oc is running on

Win2k8R2
IIS 7.5
MySQL

[hanibal8]

Hi there, I'm having the same problem.
It is not possible to manage Users at all!

This is what I encountered so far:

• none of the mouse-over-controls work: set Display Name, set Passwd, delete user
• you cannot tell which group the users belong to (it's not marked in the listbox control)
• not possible to assign a group either
• I can't even create a user

Has anyone tested this before it was released?

[hanibal8]

There is a second point I want to make regarding this issue:
From my point-of-view you have done a major change in the interface by replacing controls and changing the way how this feature works. Such a change should definitely result into another version of ownCloud, e.g. "OC 5.1".
With only having little knoweldge of what's inside the version (by reading the release notes) I would consider a change from 5.0.10 to 5.0.11 rather being a bug-fixing version. But this is definitely more. And it results into major problems.

And it is not the first time. Another example is this: #4323

This also was a major change. And it was packed into a little version step somewhere between 5.0.7 and 5.0.9.

From my perspective you should really discuss the way you make version steps. Big changes especially in the interface and changes inside workflows should not be labelled like a bug-fixing release.

[kiranos]

@hanibal8 I agree about there should be a way to differ pure maintenance updates/ bugs etc and feature updates.

as you suggest 5.1 when adding features
and 5.0.* when adding bug fixes etc.

But its another issue, can you please post a new issue for this? owncloud 6 is soon to be in alpha and it would be great to have someting like this sorted for when its released.

[motey]

same bug(?) here. Cant manage users after upgrade from 5.0.10 ti 5.0.11.
MySQL
Apache/2.2.22 (Ubuntu)
Userbackend: openldap-2.4.31

[hanibal8]

@kiranos
Absolutely. That's another discussion. I opened a new Issue --> see above.

[karlitschek]

@blizzz @raghunayyar Can you have a look please? This is urgent.

[blizzz]

Those who are experiencing it, which browsers are you using?

[salva86]

Chrome Version 29.0.1547.66 m
and IE 9

[Mathi0r]

Firefox 23.0.1
IE 10

[blizzz]

@pediehl thank you for your bug report. Unfortunately it is lacking important information. Please extend your report using the issue template (which is linked from "guidelines for contributing" which is always displayed when opening a new bug report). Only with meaningful reports we are able to inspect the issue.

[blizzz]

@salva86 @Mathi0r I have no problems with FF 23. Could you try to clear your browser cache and check again, please?

[blizzz]

cc @ringmaster

[Mathi0r]

@blizzz clearing cache didnt take any effect, the issues are still there

[salva86]

@blizzz tried a new installed client - still the same

[pediehl]

clearing of the cache didnt take any effect.
Tested by the
Chrome, Firefox und Opera on Mac newest Version
Chrome, Firefox Linux

[blizzz]

Do you see any JS errors in the browser? Any entries in the data/owncloud.log? Any entries in the web servers error log?

[motey]

chrome 29.0.1547.66 m (with clearing cache)
Firefox 23.0.1 (with clearing cache)
Same bug

Chrome JSConsole:
Uncaught TypeError: Object # has no method 'indexOf' multiselect.js?v=b28d7c6b6aec04f5525b453411ff4336:39
(anonymous function) multiselect.js?v=b28d7c6b6aec04f5525b453411ff4336:39
e.extend.each core.js?v=b28d7c6b6aec04f5525b453411ff4336:12
$.fn.multiSelect multiselect.js?v=b28d7c6b6aec04f5525b453411ff4336:32
UserList.applyMultiplySelect users.js?v=b28d7c6b6aec04f5525b453411ff4336:279
(anonymous function) users.js?v=b28d7c6b6aec04f5525b453411ff4336:338
e.extend.each core.js?v=b28d7c6b6aec04f5525b453411ff4336:12
e.fn.e.each core.js?v=b28d7c6b6aec04f5525b453411ff4336:9
(anonymous function) users.js?v=b28d7c6b6aec04f5525b453411ff4336:337
o core.js?v=b28d7c6b6aec04f5525b453411ff4336:15
p.fireWith core.js?v=b28d7c6b6aec04f5525b453411ff4336:16
e.extend.ready core.js?v=b28d7c6b6aec04f5525b453411ff4336:10
c.addEventListener.B

[Mathi0r]

there are no entrys in the logfiles but a js error:

TypeError: settings.checked.indexOf is not a function

...if(settings.checked.indexOf($(option).val()) !== -1 && !$(option).attr('selected...

multis...1ff4336 (Zeile 39)

else if(settings.checked.indexOf($(option).val()) !== -1 &amp;&amp; !$(option).attr('selected')) { << row 39 in multiselect.js

e.g. if i want to add a user, there normally appears a yellow button on the top. This button doesnt appear...

[salva86]

my owncloud.log has no entries. when i manually add a user to the sql database i can administrate that specific user. all others i cant. everything else works normal and no error what so ever... ldap or manually added users

[blizzz]

@salva86 does the other entries in the DB look somehow different compared to you manually added user?

[pediehl]

i have no logs in the owncloud.log but the error laso occurs in the Demo-System under http://demo.owncloud.org/
Fist add some groups fo example 3 and add them to the user.
Goto to e.g. Files than reopen the User-Management and than you will see the Bug

[blizzz]

OK, on demo I see it as well.

[blizzz]

It throws a JS error on loading:

Timestamp: 12.09.2013 12:02:03
Error: TypeError: settings.checked.indexOf is not a function
Source File: http://demo.owncloud.org/core/js/multiselect.js?v=b28d7c6b6aec04f5525b453411ff4336
Line: 39

[blizzz]

Okay, it only seems to happen when at least one group name is a pure number. Can you confirm?

[blizzz]

A one-digit number to be more precisely, works with 666 e.g.

[pediehl]

No the Bug also happens in the Community Version 5.0.11 of the OwnCloud with groups with "normal" Names e.g.. "planning group", etc.

[blizzz]

@pediehl no, that seems to work on demo. What i mean is of at least one group exists which name is just one digit.

[blizzz]

Could you try whether this fixes it for you? e19076d

[salva86]

@blizz i cant see any diffrence in the database under oc_users

[pediehl]

@pediehl no, that seems to work on demo. What i mean is of at least one group exists which name is just one digit.
I added a third group "normal somehting" and than the Bug happens. IF a user belongs to three or more groups than the bug happens.

[blizzz]

@pediehl you're right. Anyway, can you check whether the change e19076d solves it for you?

[blizzz]

@salva86 you may try it too, of course, as well as others :)

[salva86]

@blizzz zz seems to do the job - thx

[pediehl]

seems to do the job - but not all groups of the existing users are shown and you can not delete a user. The Icon for this is not shown up.

[blizzz]

@salva86 please spell my nick correctly (3 z), otherwise you notify a different user.

[salva86]

@pediehl i can delete users. all groups are shown also - just users that arent in any group the field is blank! @blizzz sorry :-)

[blizzz]

@pediehl it may be the groups are not shown when you added them to users before you applied the fix. those were not stored at all.

[blizzz]

@salva86 @pediehl thank you for testing

[pediehl]

@blizz sorry, it worked, i just overseen this.

[blizzz]

thx, np

[salva86]

@pediehl are u able to change groups and group administrator? i can check the box but nothing happens

[salva86]

@blizzz cc

[pediehl]

@blizz @salva86 i am also able to change groups and group administrator. i can check the box but nothing happens. no changes are stored.

[blizzz]

I see. Another JS problem.

[13:50:58.034] TypeError: settings.checked.push is not a function @ http://zara.owncloud.bzoc/stable5/core/js/multiselect.js?v=b28d7c6b6aec04f5525b453411ff4336:136

[ringmaster]

It seems like sometimes the call to OC_Group::getUserGroups() returns the array of groups for a user in a reversed order. I have not yet determined why/how this happens. As a result, when the "groups" array element is passed to json_encode(), PHP interprets the out-of-order indices as an associative array, thus converting the array into a javascript object, which causes the "settings.checked.push is not a function" error downstream, since settings.checked is an object rather than the intended array.

I added var_dump($users) to settings/users.php to debug the data. Here is partial output from that, which shows data that causes the error:

...
2 => 
    array (size=6)
      'name' => string 'bob' (length=3)
      'displayName' => string 'bob' (length=3)
      'groups' => 
        array (size=2)
          1 => string 'apple' (length=5)
          0 => string 'banana' (length=6)
      'quota' => string 'default' (length=7)
      'isQuotaUserDefined' => boolean false
      'subadmin' => 
        array (size=1)
          0 => string 'apple' (length=5)

Note the reversed order of the "groups" array element. This array will be converted into a javascript object instead of an array.

By changing line 62 to include an array_values, forcing a reindexing, the output becomes:

...
  2 => 
    array (size=6)
      'name' => string 'bob' (length=3)
      'displayName' => string 'bob' (length=3)
      'groups' => 
        array (size=2)
          0 => string 'apple' (length=5)
          1 => string 'banana' (length=6)
      'quota' => string 'default' (length=7)
      'isQuotaUserDefined' => boolean false
      'subadmin' => 
        array (size=1)
          0 => string 'apple' (length=5)

The change is ridiculously subtle, but makes a huge difference in how PHP's json_encode() converts the value.

It may be worthwhile to track down why these values occasionally get reordered. Maybe something being cached oddly? It's also worth noting that it took a bit of fiddling to get this to happen on my system in the first place, but when it finally did, it was easily reproduced on each page reload.

A fix is easy (described above), but I think we should take some time to investigate the underlying cause.

There seems to be a separate issue related to using numbers as group names. I have not finalized investigating this.

[ringmaster]

And here's the answer to why the indexes get munged in OC_Group::getUserGroups(): The PHP asort() function retains the indices in the sorted array.

Note that the code in getUserGroups() is rather different in master, and in fact, already includes an array_values() deeper in its execution.

[ringmaster]

Fixed with the merge of #4821.

[GirardT]

I really believe it has something to do with the sorting. I went in and sorted the table group_users by gid then uid (manual edit), then it fixed the problem.