Button to apply copy tags is always disabled on some systems

Bug #1720878 reported by Kathy Lussier
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Won't Fix
Undecided
Unassigned

Bug Description

Evergreen version: 3.0

I have two identical test systems loaded with clean master as of Friday afternoon that each heave at least one copy tag created. On one of those systems, the Copy Tags button in the volume/copy editor is always disabled, preventing me from being able to apply a copy tag from that interface. On the other test system, the copy tag button works fine. I have no explanation as to why it works on one and not the other since there is no difference between the two systems. However, I also found the problem with the disabled Copy Tag button on webby.

Revision history for this message
Kathy Lussier (klussier) wrote :

Now that demo.evergreencatalog.com has been updated, I tested with 3.0.0, I tested the copy tag button there. I found that that the button is disabled in Chrome, but works fine in Firefox. I'm curious if others are also getting a disabled button or if it's an issue with my browser.

Revision history for this message
Kathy Lussier (klussier) wrote :

OK, I've discovered what the problem is. I must have previously set defaults for the working copy tab on the systems where the copy tag button was disabled. At the time I set those defaults, there was not copy tag button for which to set a default. As a result, the copy tag button remain unselected in the working copy defaults interface.

I could close this bug, but I'm still concerned about this behavior. If there are systems that were piloting the 2.12 web client in production, they will encounter the same issue. Also, I think this will be a problem when we add the new copy alert feature for 3.1 (bug 1676608). When I previously tested this feature in my attempt to get it merged for 3.0, I encountered the same problem with a disabled copy alerts button. I'm guessing it was the cause of the problem was the same. We'll find that even more people are using the 3.0 web client in production, which means more people will see this problem with copy alerts when they upgrade to 3.1

Revision history for this message
Andrea Neiman (aneiman) wrote :

Given no additional reports of this, and item (copy) tags having been in production for 6 versions, I'm going to go ahead and close this.

Changed in evergreen:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.