tsgrp / HPI

OpenContent Management Suite (OCMS)
http://www.tsgrp.com/products
17 stars 5 forks source link

View All Documents: Property display needs to be more dynamic #829

Open cmlewis opened 8 years ago

cmlewis commented 8 years ago

Currently View All Docs grabs the config for the type of the first doc found and displays only those columns. Entire lines get blanked out if properties don't match. We need to be able to mix and match types and display blank columns if the property doesn't exist on the object. It's up to the client to configure 100 columns if they want to, not for us to decide.

@zkeller and I will come up with estimate, our client may fix.

gsteimer commented 8 years ago

@cmlewis, not sure if it's feasible or not for your project, but doing this update along with #360 would be awesome.

zkeller commented 8 years ago

Would it be useful to separate our docs by type? Each type can show its own attributes, nothing gets blanked out, and we avoid the lots of blank columns issue. The main down side to how view all docs works now is that we currently sort by modified date by default, so docs are in order by the most recently modified, and if we split the docs by type, we lose that to an extent.

cmlewis commented 8 years ago

I would think our client would want them all together, but we can ask them. Since they will likely be paying for it, it's probably whichever they want. I see pros and cons of both.

gsteimer commented 8 years ago

Just to be sure, #360 isn't a change to the interface. All it's saying is that you should be able to configure objects at the supertype level, and subtypes would still work. So for example, you could configure the root doctype (dm_document or cm:content) and as long as you only configure attributes like object name, modified date, etc. all subtypes would display in the table properly.

With the way View All Docs currently works, if you were to try to do that, I believe the whole table doesn't show. Every possible doctype in the table must be configured in the admin - if something unexpected shows up, it blows up.

gsteimer commented 8 years ago

Bumping this to 2.5 - we should make sure that if multiple types are in the table, we're displaying all possible attributes vs. only the common attributes.

Basically, the code should iterate over the types in the table, pull out all attributes and include all columns (obviously not duplicating the common attrs), and then display the table and leave columns blank if the column doesn't make sense for the row's type.

For example - in the screenshot below, I have both Underwriting Document and HPI Email Message in the table, but the table is only displaying the common attributes:

image

Here's the admin config:

image

image