ŁukaszBachman

I have been actively developing and using Connect using Windows 10 since it was offered as a free upgrade from Win 8.1. The upgrade itself went smoothly and I haven't noticed any upgrade-specific issues since.

Indeed that would be good. I'll put this on the roadmap, but until then it's best for you to stay committed to your current workflow. Perhaps some simple batch script could help you out with automating things too.

Can you make one of those fields required? For example: Relevant yes no requires supervisor's attention That could help. If I'm not mistaken it could even help to properly recompute existing batches (the ones which haven't been finished yet) if you then code one shared item inside them. This is just my evaluation by looking at the code, so please do not attempt this unless you have a backup or using a test case.

Pleasure is mine Adam. Glad I could help.

Hi Adam! Isn't it better to use Coding Layouts to reflect the stage of a review? For instance "Initial review" could easily be the name of the Coding Layout. Then you can sort "All batches" view by the Coding Layout column and you will have everything grouped nicely together.

That's very useful Adam, thank you!

Ok, so below some longer explanation. For compatibility reasons, we decided to distinguish between two kinds of Coding Layouts: Containing required fields Not containing required fields There were several reasons why we did that, but the most important one is this: we always urge users to create batches out of TAGGED items. That helps to have a good workflow and can be a savior if one has to troubleshoot his coding process. Therefore, since each item in batch should already have at least one tag applied when batch is created, some follow up restrictions arose. Batches, depending on the type of Coding Layout assigned to them, can be updated when those events happen: Batch is created (for CLs containing required fields) Item in batch has been coded (for both kinds of CLs) As you can see initial batch progress is set only for batches that have some required fields in associated Coding Layout. Why is that? Imagine we would update batch's progress regardless of which fields are required. If then user creates batches from items which already were tagged (remember the rule that I mentioned before) then all batches would automatically be completed! That's why we make this distinction for batches without required fields. In your case common items were present in existing batches when you were coding items (rule 2.) so batches were updated accordingly. When you then created more batches, then the rule 1. was not applied because your coding layout did not specify any required fields. Hope that's useful.

Hi Adam! Yes, there is one explanation for this. You were probably using a Coding Layout without any Required Fields. Is that true? If so, I have a longer explanation but let's confirm this first.

Jason, I think a quick patch won't be possible here as that is how we designed Coding Layouts to work and as a result such changes will have a vast impact on the tool. I understand your claim and I'll think about a better solution to tackle this, however it won't be a quick fix.

Ok jcoyne, I that made it a bit more clear. I think I'll add this feature request to our list.

I agree with fuzed - it would be good to scout for those hits in other Previewer Tabs too. Should be easy to tell if item contains hits in them, as in such cases labels associated with tabs are highlighted in bold.

Thanks for an update fuzed. I'm glad you were able to figure it out.

Hi jcoyne! Thank you for bringing this up! Indeed, one has to make sure that any potential attachments are added to the set before it's split into batches. At first sight this might seem like a limitation, but if one thinks about it - preparing the set of items for a review is much more than just adding attachments. One has to consider how to treat conversations, duplicates, etc. I can only assume that each company has some sort of rules that govern this process (probably validated years of experience and many hours spent on improving Quality Assurance). That being said, we were considering adding some "intelligent warnings" when batches are about to be created but we detect that something relevant might be missing. An example of such warning would be to notify user that not all entire conversations have been included in the set. But it's more about making user aware, rather than doing things automatically. What do you think about this? Also - please note that in each batch items are sorted by Family Date. This means that if you will have an email with two attachments, then those files will immediately follow the parent email. This makes review much easier, as reviewers can stay focus on a context of particular item. That should be exactly what you need. As a final comment - the "Preview" button is grayed out only when given item does not support Native Preview. In such cases just looking at Contents should be enough.

Hi jcoyne! Indeed one has to have a special permission in order to create Review Batches. However, it should be enough to assign this permission to a specified Role and then refresh the browser window to see those changes being reflected. If that didn't work for you, then I'd be surprised and it could require further investigation.

Hi Adam! I must admit that this would've been included in 1.9.1 already, but we simply didn't have the time to squeeze it in this release. For me that's very handy feature too, and I'm planning to add this in 1.9.2, if time allows (I'm rather confident it will).

We didn't allow that to be done on purpose, as one mistake could then affect all redacted documents. Some sort of "live preview" would be nice to have, though.

Adam, good observation. Thanks! I'll make a note about this.

Adam, I suggest you look into configuring a non-standard Redaction Profile, where you skip item metadata. That way you will see the contents of the document for redactions at the very first page. It's a very similar idea to PDF rendering options that you are probably more familiar with.

Hi Adam, are those results coming from the native Preview tab or from TIFF exports? I understand that those PDFs are created out of images (ie. scanned invoices) as otherwise I wouldn't see why one would need to OCR them, but can you verify this too?

Hi Adam, we outsource PDF rendering to a third party component which is probably the one to blame for this particular glitch. Dealing with PDFs is a complex topic which requires tremendous amount of code to be written, so those happen sometimes but are very rare in my opinion. In 1.9.1 we upgraded this library to the newest version which fixed a plethora of such issues and we will probably keep updating this component with each and every release. If you spot such quirks, please use other browser or download the native file for a review.

Hi Adam! Sorry for a slow reply, but I'm now in the process of processing Community feedback so I wanted to further comment on this. Initially it sounded like a nice feature to be added, but immediately I asked myself: what about fuzzy, proximity or complex boolean searches? That would immediately make this mechanism not function correctly. Now in Review tab (when reviewing a Batch) one can have multiple keywords/keywords-lists selected to highlight relevant terms. We could add something similar to standard Previewer. Wouldn't that be better?

Hi Dale, sorry for the slow response. One thing you could try is to use Items Table to find those items. Search for "Features > All items", then add "Primary Date" column to the table and sort your results using it. You should have items without any date grouped together. Of course this is a manual process (so Saved Searches won't help to automate this), but perhaps it could get the job done for you?

Happy to hear that!

No problem, there have been plenty of new features included in this release so it's easy to miss one button. Happy I could help.

I think that this is more about the fact that autotagging creates a lot of tags instantly, rather than batches being an issue here. Wouldn't you agree? Perhaps a better solution would be to use hierarchical tags while autotagging? This is already possible, just specify a full tag path as the tag name, for instance: auto/look, auto/see, auto/find. This will create one parent tag "auto" with three children.