Bug: Toggling a colored tag with number keys doesn't update Date Modified

In, toggling a colored tag with number keys doesn't update the Date Modified field. Manually editing a tag in the right pane does update Date Modified however.
  • I also noticed this issue about a year ago. Back then I thought this might be intentional, since numbered tags could be treated differently. But I agree with you that this is currently inconsistent, there probably shouldn't be a difference between using number keys and dragging to a colored tag. The Date Modified of items whose tags are changed should be updated in both cases, I think. One would also need to check the Shift+Drag operation for removing tags, which is similar to using a numbered tag twice.

    There's also this minor issue, which is somewhat related:
    (I haven't checked if this has been fixed in the meantime.)
  • Yes, this was intentional. I think my reasoning here was that 1) when sorting by Date Modified it would be annoying for items to jump to the top just because you pressed a number key (which is also fairly easy to do by mistake and then toggle off) and 2) colored tags are much more likely to be process tags (e.g., "to read"), so you're not really editing the item in such a way that the date has to be updated.

    I agree it should be consistent with dragging to a colored tag, though, and arguably with dragging to any tag. One option would obviously be not to update Date Modified for tag changes at all, but I suspect lots of people do want tag changes to update the date (particularly in groups where tagging is an important part of the workflow), so maybe it just needs to change in all cases…
  • edited June 22, 2021
    It would be best if it changed in all cases. Indeed, colored tags are often used for "process tags", and it is something that I and my workgroup rely on heavily that we can check the items that have been processed most recently using Date Modified. It would be much preferred if this could be consistent regardless of how the tags are edited.

    That editing tags updates the Date Modified was a great improvement in Zotero 5 over Zotero 4. Please don't revert that!
  • So just testing this here, this really does make it awkward to use the number keys while sorting by Date Modified, since the item jumps to the top of the list as soon as you toggle a tag. Not sure what the solution is here, but this is definitely the reason we didn't implement it this way to begin with.
  • edited June 22, 2021
    There's certainly an argument that this inherent UI side effect is less important than having the tag change update Date Modified. We just need to be clear that we're making that choice.

    And of course, any field change has the same side effect, so maybe the real point is just that you shouldn't sort by Date Modified while editing items unless you're OK with items jumping around…
  • edited June 22, 2021
    I really don’t think it’s awkward. That’s the expected effect—editing an item should make it jump to the top of the Date Modified list. I don’t see any difference here between editing a tag and editing a creator or title.
  • OK, I've made this change in the latest beta.
  • Thanks! That's awesome!
  • This change is now available in Zotero
Sign In or Register to comment.