Ability to add metadata (and types) to cabinets

Requests for new functionality or improvements in existing functionality. Please provide clear descriptions of your request, an example or if possible a real life scenario.
Post Reply
asbasb
Posts: 2
Joined: Fri Oct 18, 2019 7:32 pm

Ability to add metadata (and types) to cabinets

Post by asbasb » Fri Oct 18, 2019 7:43 pm

Current: Metadata can only be added to documents.
Request: I would like to be able to define metadata for and add to a cabinet.

Use case: I would like to define a cabinet for each customer and not only associate a name, but also a customer ID with a cabinet. Each customer/cabinet may have multiple documents but the customer/cabinet is the centralized grouping point.

Example illustration:
Define Cabinet name: (example: 'customerName')
Define Cabinet metadata type: (example: customerNumberType)
Define Customer metadata type value: (example: 10001)

This provides the ability to more tightly couple and integrate with other preexisting business applications and grouping schemes.

User avatar
lantonov
Posts: 5
Joined: Sun Oct 13, 2019 7:49 pm

Re: Ability to add metadata (and types) to cabinets

Post by lantonov » Sat Oct 19, 2019 6:10 am

This request relates to the more general aspect of creating objects other than Documents. In many general-purpose EDMS like M-Files, SharePoint, Documentum, objects are the central categories around which the whole custom models revolve. Documents are the mandatory object and the other objects are defined additionally by the user depending on his field. A company would have Customers, Contractors, Suppliers, etc., a government medicines agency can have Medicines, MAHs (Marketing Authorization Holders), Manufacturers, etc. The ability to group around relevant objects make the classification easier to search and maintain. I have not come down to the details of the Mayan EDMS ORM but if Cabinets is just another name for custom-made objects then the ability to attach meta-data and subcategorize them goes a long way towards Mayan versatility.

asbasb
Posts: 2
Joined: Fri Oct 18, 2019 7:32 pm

Re: Ability to add metadata (and types) to cabinets

Post by asbasb » Sun Oct 20, 2019 2:26 pm

lantonov wrote:
Sat Oct 19, 2019 6:10 am
The ability to group around relevant objects make the classification easier to search and maintain. I have not come down to the details of the Mayan EDMS ORM but if Cabinets is just another name for custom-made objects then the ability to attach meta-data and subcategorize them goes a long way towards Mayan versatility.
I agree with this 100% and to add some additional perspective and thoughts (from a data management standpoint)...

1 - Obviously Mayan will not be (nor should it be) a data master other than document master. In addition, while Mayan maintains its own keys, those should be local to the platform and the platform should be able to leverage the enterprise's primary keys where and as available.
2 - The names that are captured or relevant for the EDMS at any point and time may change. People can change names (e.g., after marriage), Companies may change names, products may change names, etc. In larger organizations the responsibility and accountability for maintaining that information is centralized in a single group and repository (hopefully). Even if siloed and local to various lines of business, the ownership of this information almost certainly wouldn't be with the team (person) managingt documents, contracts, etc.
3 - Keys can be alphanumeric and not only numbers (national IDs, guids, license plate numbers, etc.)
4 - From a database standpoint, it looks you can leverage the data model and scheme which you use for the metadata_matadatatype, and metadata_documentmetadata. Something similar for the cabinets (or other object) level would be perfect (I think). I guess this might require the following changes to the data model:
- Create cabinet_metadatatype (to define the types/categorizations/etc.)
- Create cabinet_cabinetmetadata (to define the type values)
- OR... If a type is just an attribute of an object (whatever the object), you may also be able to make the case that you can have a single type table for all types of objects (documents or cabinets), and then a single table to link objects with attributes (i.e., types)

Thank you again for this great tool. I started to dive into the tool last month and am not only very impressed, but trying to propose some problem solutions for my team (and I purchased the book!)

Post Reply