CobaltBlueDW {"ops":[{"insert":"Problem: Because of the way cards get added to the collections, there are lots of opportunities for the same card to have multiple records in the collection. \n\n"},{"attributes":{"bold":true},"insert":"e.g."},{"insert":"\n1 Lay Bare\n1 Lay Bare\n"},{"attributes":{"bold":true},"insert":"instead of..."},{"insert":"\n2 Lay Bare\n\nThere are good reasons to allow this to occur, but it's often not necessary, and can cause problems like \"I don't trust when it says I only have 1 Lay Bare in my collection, because there might be another record for it on a later report page. How many Lay Bare's do I actually have?\"\n\nIt would be handy if there was a feature (perhaps in the active selection menu), that would find duplicate records and collapse them down to singular records.\n\nIn my estimation, this is a fairly low priority feature request, but I thought I'd still outline it. I love Archidekt BTW, you guys are doing a great job.\n"}]}
0
{"ops":[{"insert":"I've talked about this a few times, but this is actually a pretty complicated issue from both a user management & technical perspective. \n\nFrom a technical perspective, it's challenging because if someone runs this on a 50k record collection, that raises a good amount of complications. Not to mention in order to do the merge at all, we need to load a user's entire collection at once. Which can be kinda a lot.\n\nFrom a user management perspective, it might even be more challenging. In your example above with just card names, it's pretty obvious how to merge those records, but that's the simplest case. If you start adding other modifiers like foiling, edition, language, condition, purchase price, etc, this problem becomes a lot more complicated -- solvable, but complicated. The largest reason that it's so complex is because we have a philosophy for archidekt that users cannot edit data they cannot see. We don't "},{"attributes":{"italic":true},"insert":"always "},{"insert":"do that, but that's the general rule of thumb. So the question becomes, how on earth do we allow users to see, and resolve thousands of merges? Which field(s) to we merge on? etc. \n\nAgain nothing is insurmountable, just complex. And that kind of complexity I suspect will put people off from using a feature like that. \n\nWe still consider doing something like this, there's just a lot that'll go into it. And I suspect even if we do our jobs 100% perfectly, that a tool like this would still result in some users borking their collection data because they don't configure which fields they want to match on correctly.\n"}]}
1