This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Show Document classes

Working on a design where we are looking to pull a document package apart into the various documents that feed it.
That works alright, however, we need a centralized object, the Work Order to bring all these together.

What we have is a WO Package that will have a WO number and any of the files would reference it.
The issue is that this is a brick of a document, 18+ classes and some will have upwards of 20-200+ documents inside them.

What I'd like is for the Documents (2) to instead be displaying their class.

Is there a way to do that? Or to change up this binder of documents? As it stands, this binder is passed around from department to department who add their things to it and you could imagine how inefficient that is. Just having the documents all situated under a WO for perusal would be ideal, but having everything lumped into "Documents" just returns us to the binder format. We could have other views for departments.



The only other way I can think is to have hidden multi-selects and to have the objects when checked in to be added to the WO Package, thus possibly allowing this rollup / reverse lookup.

Any other solutions for dealing with what I can only refer as to a 'document binder'

Parents
  • I think the general idea you have is good, i.e. using the separate Work Order object to bind together the different documents. This is how it's often done in M-Files, another example could be a contract that consists of multiple documents in different classes and possibly with different access rights and you would use a separate Contract object to bind those together.

    You can't change how the Documents group is displayed, those relationships are always shown by the object type so you cannot get it to show them by class instead. They are all documents after all, similar to how the Customer group shows Customer objects.

    What you could perhaps do is to use automatic naming for the documents so that the class would be reflected in the title. So the document names would be something like "Order - Cover Sheet.pdf" and "Order - Parts List.pdf", if Order is the name of the class. You can use the built-in simple concatenation for this or the auto-calculation feature in the Managed Properties module.

    Another thing you might want to consider is to access the work orders via views and use the class as a grouping level. Then users could first drill down to the work order they are interested in and then to the specific class of documents related to that work order. The view filter could be set so that it only shows for instance active work orders so that the number of objects in the view doesn't grow too large.

    Example grouping with Project and class:

Reply
  • I think the general idea you have is good, i.e. using the separate Work Order object to bind together the different documents. This is how it's often done in M-Files, another example could be a contract that consists of multiple documents in different classes and possibly with different access rights and you would use a separate Contract object to bind those together.

    You can't change how the Documents group is displayed, those relationships are always shown by the object type so you cannot get it to show them by class instead. They are all documents after all, similar to how the Customer group shows Customer objects.

    What you could perhaps do is to use automatic naming for the documents so that the class would be reflected in the title. So the document names would be something like "Order - Cover Sheet.pdf" and "Order - Parts List.pdf", if Order is the name of the class. You can use the built-in simple concatenation for this or the auto-calculation feature in the Managed Properties module.

    Another thing you might want to consider is to access the work orders via views and use the class as a grouping level. Then users could first drill down to the work order they are interested in and then to the specific class of documents related to that work order. The view filter could be set so that it only shows for instance active work orders so that the number of objects in the view doesn't grow too large.

    Example grouping with Project and class:

Children
No Data