Problems with List of Values and Groups in 3.3

[aman]

Hi.  I've been knocking my head against this for a while now, because I can't bring myself to believe that something so fundamental could be broken (especially given no one else has raised it), so there must be something I'm doing wrong!  However the time has come to air this…

Here's the problem (I'm using 3.3CE on Windows, but I've confirmed the same problem in 3.3g and 3.3EE.  IN all cases, it an "out of the box" installation using the Windows full installation EXE)…

I want to use Custom Metadata - specifically Lists of Values (LOV).  When you defined a LOV you have to add "Access" to it.  It says something like:
"Click Add to add access for a User or Group".  When I do so, there is no problem adding users, but adding groups is impossible - the search/selector doesn't find or return any.  What this means is that no one except those individual users who are listed by name can apply this LOV metadata to the record the LOV is assigned to!

I've logged this as a bug, however the response fromt he developer said "This should be logged as an impovement"!!  I'm hoping he has misunderstood the bug request, as I can't see how this is meant to work otherwise - it basically means LOV metadata is unusable.  This raises the question in my mind - IS anyone actually using this?!  If so, how?  By listing individual users??

[Unhelpful/mistaken mention of not seeing groups in the User Rights Reports removed - Aman 13/7/2010]

Any help would be much appreciated.
Thanks,
Aman.

[carlos_miguens]

I think you may be experiencing a weirdness in the search behaviour. When you do a search in the box for groups it searches only the internal group identifier not the display name.

So for example if you had setup a group identifier of "documentation" with a display name of "Technical Publications", you would not be able to search for "publication" or "technical", or rather you would but it would return nothing.

However if you search for "doc" it will return your group. Internally it will create an authority called GROUP_documentation and it is the authorities that it is searching.

The improvement request would be to have it search both properties.

[aman]

Hi Carlos.  Thanks for the reply.

However unfortunately what you suggest is not the case.  I know that what you suggest is what the various open bugs in JIRA say, but I can assure you that the problem is more profound than that - in no case, no matter what I search for, can I get ANY group returned!

To be explicit - searching for "doc" will not return anything, even if I have a group called "doc" (or "documentation", or even "GROUP_doc", as created by LDAP) with description "doc" or "documentation").

I'd really appreciate it is someone could confirm that this isn't in fact totally broken in 3.3 by doing a quick test to confirm it….  

Many thanks,
Aman

[carlos_miguens]

My test was against 3.2, I've not had time to build a 3.3 environment for Records Managment yet. Did you have it working with 3.2 or did you start with 3.3?

[aman]

I started with 3.3.  I've never installed 3.2.
FYI, the link to the issue: http://issues.alfresco.com/jira/browse/ALF-3794

Thanks,
Aman

[carlos_miguens]

Hi Aman

Since you appear to be a supported customer (you mention 3.3EE) you should log this issue directly with support. You will get a fast response andf they should be the ones helping to nail this rather than me having to build a 3.3 environment. I will get to this but not in the very near term.

[aman]

HI Carlos - just FYI - we're not (yet) a supported customer - I only mentioned 3.3EE because I checked to see if the problem also existed in that version - which it did.  I'm working on 3.3CE.  Thanks.

[aman]

Just for the forum record, this problem is resolved in 3.4.