Project

General

Profile

Actions

bug #9688

closed

Make disabled fields copyable

Added by Katja Luther about 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
New
Assignee:
Category:
taxeditor
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Severity:
normal
Found in Version:

Description

from #9287:

There is only one final issue which is valid for all disabled fields. Is it possible to generally make disabled fields copyable? Currently they only show the text but it is not possble to copy it. At some places this is already implemented. We probably should move this issue to a new ticket.


Related issues

Has duplicate EDIT - bug #8277: Username (and other fields) should allow c&pDuplicateKatja Luther

Actions
Copied from EDIT - feature request #9287: Show term details in details view of term tree editorClosedKatja Luther

Actions
Actions #1

Updated by Katja Luther about 1 year ago

  • Subject changed from make disabled fields copyable to Make disabled fields copyable
Actions #2

Updated by Katja Luther about 1 year ago

  • Status changed from New to Resolved
  • Assignee changed from Katja Luther to Andreas Müller
  • Target version changed from Unassigned CDM tickets to Release 5.25

please review.

Actions #3

Updated by Andreas Müller about 1 year ago

Actions #4

Updated by Andreas Müller about 1 year ago

  • Status changed from Resolved to Feedback
  • Assignee changed from Andreas Müller to Katja Luther
  • % Done changed from 0 to 30

Copy from #9287:

AM:

For toggleable they still set the dirty flag (tested on Person details view with bulk editor). This is unwanted.

I do not yet fully understand why it is not possible to use the same technique as for ordinary text fields in toggleable fields.

KL:

The same technique is used for text fields and toggleable text fields but maybe I need to have a look on the event handling of the toggleable text field.

Actions #5

Updated by Katja Luther about 1 year ago

Andreas Müller wrote:

Copy from #9287:

AM:

For toggleable they still set the dirty flag (tested on Person details view with bulk editor). This is unwanted.

I do not yet fully understand why it is not possible to use the same technique as for ordinary text fields in toggleable fields.

KL:

The same technique is used for text fields and toggleable text fields but maybe I need to have a look on the event handling of the toggleable text field.

The toggleable text field has additional modifyListener and keyListener, maybe this is the cause of the different behaviour.

Actions #6

Updated by Katja Luther about 1 year ago

  • Status changed from Feedback to Resolved
  • % Done changed from 30 to 50
Actions #7

Updated by Katja Luther about 1 year ago

  • Assignee changed from Katja Luther to Andreas Müller
  • % Done changed from 50 to 30

This is fixed, please review.

Actions #8

Updated by Andreas Müller about 1 year ago

  • Status changed from Resolved to Feedback
  • Assignee changed from Andreas Müller to Katja Luther

Now an unprotected toggleable field can be edited. I tested with unprotected collector title of a team. But same result for e.g. name cache.

Actions #9

Updated by Katja Luther about 1 year ago

  • Status changed from Feedback to Resolved
  • % Done changed from 30 to 50
Actions #10

Updated by Andreas Müller about 1 year ago

  • Assignee changed from Katja Luther to Andreas Müller

I guess this is for review.

Actions #11

Updated by Andreas Müller about 1 year ago

  • Status changed from Resolved to Closed
  • Assignee changed from Andreas Müller to Katja Luther
  • % Done changed from 50 to 100

works as expected now.

Actions #12

Updated by Andreas Müller about 1 year ago

  • Has duplicate bug #8277: Username (and other fields) should allow c&p added
Actions #13

Updated by Andreas Müller about 1 year ago

  • Status changed from Closed to Feedback
  • % Done changed from 100 to 80

I have to reopen this as now the Username and Group.name fields are editable again, but shouldn't. See also #8277.

Changing the username must not be possible. What is the reason why these fields are now editable again? Is it possible that there are other fields influenced in the same way that are now editable but they shouldn't? If yes, this is critical and needs to be fixed as soon as possible.

Actions #14

Updated by Katja Luther about 1 year ago

Fixed it for the Userdetails but the group name never was disabled. I can do this as well, but maybe this is a little bit more difficult because it should be editable as long as it is not used anywhere?

Actions #15

Updated by Andreas Müller about 1 year ago

  • Status changed from Feedback to Resolved
  • Assignee changed from Katja Luther to Andreas Müller
  • % Done changed from 80 to 90

Katja Luther wrote:

Fixed it for the Userdetails but the group name never was disabled. I can do this as well, but maybe this is a little bit more difficult because it should be editable as long as it is not used anywhere?

Yes, for groupnames it is not so obvious. But both fields are marked as unique so the easiest way to guarantee this is to make the field not editable. On the other hand a groupname should have a semantic meaning so sometimes an admin may want to change the name to a better one.
So, yes, probably we should leave it editable. It is not a serious issue anyway.

I will check the username implementation and close the ticket then.

Actions #16

Updated by Andreas Müller about 1 year ago

  • Status changed from Resolved to Closed
  • Assignee changed from Andreas Müller to Katja Luther
  • % Done changed from 90 to 100

For usernames it works as expected.

Actions

Also available in: Atom PDF