Upgrade StorageWays to see date of deletion for entries in zotero, and suggestion for handling deleted duplicates
Hi there,
It's always bothering me when handling duplicates. when I merge some duplicates, the duplicates are automatically moved to the dustbin, which I may not clear right after. Then after some time, when I really want to clear the dustbin, I will see these duplicates, together with other deleted items. As a result, some entries seem to be still needed to me. However, I can't tell whether these entries are generated during merging duplicates, or they appear simply because I accidentally delete some of them during other normal operations. So I have to manually check whether the same entry is still in the library. To do this, I can press ctrl, then one of the collections will become yellow; however, I can't tell whether this means another copy of the entry is there, or the yellow only indicates that the deleted entry were in that collection before deletion. Both cases lead to the same effect. So I have to check it manually. This is very cumbersome.
I wonder if there is anyway to let us safely know if there is still a copy of the same entry in the library? the "ctrl" shortcut can't distinguish the case that the en see when an item is deleted in zotero? This will help me identify which are the ones that I deleted just now.
And is there any way to see the date of deletion, so that this gives me some hint of when they are deleted, which will help me to make the decision of whether they are really not needed any longer. Thanks.
It's always bothering me when handling duplicates. when I merge some duplicates, the duplicates are automatically moved to the dustbin, which I may not clear right after. Then after some time, when I really want to clear the dustbin, I will see these duplicates, together with other deleted items. As a result, some entries seem to be still needed to me. However, I can't tell whether these entries are generated during merging duplicates, or they appear simply because I accidentally delete some of them during other normal operations. So I have to manually check whether the same entry is still in the library. To do this, I can press ctrl, then one of the collections will become yellow; however, I can't tell whether this means another copy of the entry is there, or the yellow only indicates that the deleted entry were in that collection before deletion. Both cases lead to the same effect. So I have to check it manually. This is very cumbersome.
I wonder if there is anyway to let us safely know if there is still a copy of the same entry in the library? the "ctrl" shortcut can't distinguish the case that the en see when an item is deleted in zotero? This will help me identify which are the ones that I deleted just now.
And is there any way to see the date of deletion, so that this gives me some hint of when they are deleted, which will help me to make the decision of whether they are really not needed any longer. Thanks.
Could you describe exactly what you're doing and what you're observing?
Another issue during merging is that, since I can only choose one master document, the info in some fields of the other entries could be missing, (e.g., Loc in Archive, Call number, which I use to save some personal documents. I suppose this also happens to some other fields). I wonder if it is possible that, when merging, those info in the other documents is to be kept, if the corresponding field in the master document is empty?
a) definitely doesn't put anything in the trash and
b) let's you choose individual fields from any merged item where they differ between merged items, see https://www.zotero.org/support/duplicate_detection#merging_duplicates (the small red circle in the figure)
In this case, when I go to the trash, I will see items that I just merged, though they are mostly without attachments as far as I remember, likely to be because that they are populated to the primary documents.
I'm using 5.0.95.1 on windows 10.
Regarding the choosing individual fields, I can see that option; however, for the case that the field is empty in the chosen primary document, it would be better that the corresponding info in the other version (or in one of the others versions) will be recorded in the merged item.
Choosing individual fields manually is fine, but cumbersome in my opinion, especially for the case that the values in the said field has no conflicts, meaning that there is only one distinct value among all the records for that field.
If there is a reason that zotero wants to avoid this option by default, it would be good to offer an option for the users to choose. Thanks.
Despite whether it is a bug, I would suggest offering users options to choose whether they want to populate the info from other versions to the merged in case there is only one distinct value for the said field, (except empty, of course). Also, allowing us to see the date of deletion for items would also be beneficial, including the case mentioned here. Thanks.
I would sugget the following:
1. keep the current behavior of letting the "deleted duplicates" go into the trash.
2. adding the field of time of deletion for items in trash.
3. allowing the info from the slave versions to be populated into the merged version, if there is no conflict for the given fields.
4. if a deleted item was recongnized as a duplicate of another by the user ( which means that it comes from the merging behavior done by the user), then, after pressing the ctrl button, the corresponding collections originally having it to turn yellow, as zotero already does; moreover, if there is another version of the same reference in some of the collections, then these collections could turn to a different color, so that we know that it is a duplicates
5. otherwise, a tag could be added to those deleted items if they come from merging options, so that the user can filter them, and then delete these safely.
1. the references are mistakenly recorded as books by the source, such as Web of Science. In this case, even though the papers clearly have very different titles, they could be recongnizized as duplicates
2. one version is conference, and one is book section. In such a case, even if they have the same biblio info for most of the important fields, one still can't merge them; one has to change the type of one of them before merging them. I agree that this is a good idea for most of the time, but for this two types of items, this could happen relatively regularly, so it would be great if an exception could be made for this case.
Thanks.
Beyond that, I don't really see the problem here. The trash is just to provide a backup of deleted items, and items are purged automatically after 30 days by default. You're not really meant to spend time combing through it to see if there are things in it that shouldn't be there, or even emptying manually unless you're trying to clear space.
The behavior with highlight collections depends on what collections the deleted item was in, as with any other deleted item, and I don't think it merits special behavior beyond that.
1. adding the field of time of deletion for items in trash, so that one can easily identify those one just deleted.
2. otherwise, a tag could be added to those deleted items if they come from merging options, so that the user can filter them, and then delete these safely. However, I notice that, for the items in the trash, one can't see the details of it, only a menu saying sth like "deleting" or "restoring" pops up; not sure why it is implemented like that; in this case, option 2 here might not be useful.