Defect #6521

Tooltip/label for user "search-refinment" field on group/project member list

Added by Frank Helk about 7 years ago. Updated about 7 years ago.

Status:ClosedStart date:2010-09-28
Priority:NormalDue date:
Assignee:Jean-Baptiste Barth% Done:

100%

Category:UI
Target version:1.0.3
Resolution:Fixed Affected version:1.0.2

Description

When editing a user group, in the "Users" tab, the list of users doesn't contain all available users.

There are users missing that are both

  • not already in the group, and
  • not blocked anyhow.

The users can be added i.e. from the "Edit user" form, Tab "Groups", without problems.


Related issues

Duplicated by Redmine - Defect #6869: Cannot find/select some members in the Project->Settings-... Closed 2010-11-11

Associated revisions

Revision 4312
Added by Jean-Baptiste Barth about 7 years ago

Add a label for user and group search fields. #6521

Contributed by Felix Schäfer

History

#1 Updated by Felix Schäfer about 7 years ago

  • Status changed from New to Closed
  • Resolution set to Invalid

You probably have more than 100 users. The user list only shows 100 users, you can refine the list with the text field above it.

#2 Updated by Frank Helk about 7 years ago

I've read in another ticket that the limit of 100 is kind of sacred (well reasoned, anyhow) - maybe there could be a hint included that some entries are missing in case there are hidden users ?

Not much - a line

(...)

with a tooltip like "more entries available ... use filter field" or such would do perfectly well.

#3 Updated by Felix Schäfer about 7 years ago

  • Subject changed from User Group Edit -> Users -> User list not complete to Tooltip/label for user "search-refinment" field on group/project member list
  • Category changed from Administration to UI
  • Status changed from Closed to Reopened
  • Assignee set to Felix Schäfer
  • Resolution deleted (Invalid)

Yes, I've thought about that too for some time, but never really got to doing anything meaningful about it. Changing the title so that it reflects the request better, I'll have a look maybe this WE if I can come up with something :-)

#4 Updated by Felix Schäfer about 7 years ago

  • Status changed from Reopened to 7
  • Assignee changed from Felix Schäfer to Jean-Baptiste Barth
  • Target version set to 1.0.3

Ok, I just added a label to the field, but that should be enough of a hint to understand what the field is there for.

See http://github.com/thegcat/redmine/commit/76729f10183bd3db3809bc916f28644f94028604

JB: could you commit this please? Thanks.

#5 Updated by Frank Helk about 7 years ago

That would help anyway, but is no exactly what I've been thinking of.

That 100 user limit is not obvious, neither is it mentioned anywhere - and there's no hint that users are missing from the list. That might confuse ...

I would suggest to add a hint stating that there are more users, if the 100+ cut-off is in effect. BTW: I think that users and groups should be clearly marked (icons in front ? list headings ?) and the two parts of the list should be separated by at least a little bit of space.

#6 Updated by Jean-Baptiste Barth about 7 years ago

Felix: maybe this patch answers to another problem (the fact that "groups" appear in a "search for user" box).

I agree with Frank, groups should be marked or displayed differently. Or maybe splitted into a different box ?

I'll apply this patch if we decide not to address these other questions for the moment. Let me know what you think.

#7 Updated by Felix Schäfer about 7 years ago

Jean-Baptiste Barth wrote:

I'll apply this patch if we decide not to address these other questions for the moment. Let me know what you think.

I'd say apply the patch as a "quick fix", and open a new issue for the user/group list, it does feel a little awkward at times, but I think it needs a bit more work than just separating users and groups and things like that (think 2 tabs, one for users and one for groups, and maybe other things).

#8 Updated by Jean-Baptiste Barth about 7 years ago

OK. Do we keep it for 1.0.3 ? Not sure we should, it will introduce dozens of incorrect translations in a stable release.. Any idea (maybe from the release team) ?

Side-question for Felix: how did you update the translations ? Automatic cherry-picking failed, so I tried to apply a truncated patch by hand then run rake locales:update, but new keys are added at the end of the locale files, whereas you managed to add them at the correct place.

#9 Updated by Jean-Baptiste Barth about 7 years ago

Jean-Baptiste Barth wrote:

Side-question for Felix: [...]

Argl, forget it. Yours are also at the end of the files, it just seems a bit more messy now that we have other translations added. I should go back to bed, will see it tomorrow.

#10 Updated by Jean-Baptiste Barth about 7 years ago

  • Status changed from 7 to Resolved
  • Target version changed from 1.0.3 to Unplanned
  • % Done changed from 0 to 100
  • Affected version (unused) changed from 1.0.1 to 1.0.2
  • Resolution set to Fixed
  • Affected version changed from 1.0.1 to 1.0.2

Applied in r4312. But as I said before, I don't think it's ready for 1.0.3 regarding locales updates.

#11 Updated by Eric Davis about 7 years ago

  • Target version changed from Unplanned to 1.0.3

Jean-Baptiste Barth wrote:

Applied in r4312. But as I said before, I don't think it's ready for 1.0.3 regarding locales updates.

I think this is fine for 1.0.3. Getting all the locales updated always takes a bit of time. As long as the English versions are in, it's easier for translators to find what's missing for the next release (i.e. translate missing strings in 1.0.3 for 1.0.4).

I need to make sure this merges into 1.0-stable but I'm tagging it 1.0.3 for now.

#12 Updated by Eric Davis about 7 years ago

  • Status changed from Resolved to Closed

Merged into 1.0-stable for release in 1.0.3

Also available in: Atom PDF