Existe alguma forma de deixar alguns dados além dos Metadados privados? Como Miniatura, Documentos e Anexos?
No momento gostaria de colocar a miniatura no item, mas só posso publicar a miniatura depois de alguns dias, além de fotos em documentos que eu gostaria de deixar a frente de uma obra publica, mas seu verso privado. Há essa possibilidade?
Olá @Lucas_Marques_Bezerra , tudo bem?
Infelizmente não, a visibilidade do Documento e dos Anexos estão amarradas à visibilidade do item. Esta é a na verdade a principal razão pela qual temos esta issue aberta, algo que pretendemos trabalhar ainda este ano:
abertos 02:15PM - 07 Feb 22 UTC
[Effort] Level 5 🤯
[Module] Admin
[Project] Gestão de Acervos
[Project] Iberê
## Why this feature is needed?
Currently, attachments and the "main document" a… re bound directly to the item. This has two negative downsides:
- The attachment privacy status will always be the same of the item (due to the folders disposal inside `wp-content/tainacan-items/:collection-id/:item-id`);
- There is no way of creating separate groups of attachments (say you want images of the object and images of an exposition in the same item).
If we create an attachment metadata type, we'll be a able to have these groups and a new criteria (the metadata id) to define privacy status. This will also bring more feature parity to [what ACF offers](https://www.advancedcustomfields.com/resources/gallery/), for example.
## What is expected?
### The basics:
- A metadata type "attachment", that would contain basic metadata functionality such as: privacy status, multiplicity, being required or not, etc;
- Allow uploading of files as metadata values, that would be stored in a folder structure that can be safe in terms of access based on the metadata, item and collection status;
- Some basic implementation of visualization of this files in the items list and item single page;
- A way to import via CSV the metadata values similar to how we do with attachments;
### The desired (possibly deserve separate issues):
- A visualization that could use our current [media gallery](https://github.com/tainacan/tainacan/blob/fdaf1cf9a32ae4d0296b2be41d0b68999337ca50/src/classes/theme-helper/template-tags.php#L309) (the one that displays the attachments) and its several visualization options (carousel, main slider, zoom, download link, etc);
- Options to limit the type of allowed files per metadata;
- Registering filters to filter by type of attachment, number of attachments, size of attachments;
- Implement advanced search logic to do the same kind of filtering;
## Initial steps
- [Register](https://github.com/tainacan/tainacan/blob/fdaf1cf9a32ae4d0296b2be41d0b68999337ca50/src/views/admin/components/metadata-types/metadata-type-helper/class-tainacan-metadata-type-helper.php#L46) the metadata and create its folder in the [metadata types folder](https://github.com/tainacan/tainacan/blob/fdaf1cf9a32ae4d0296b2be41d0b68999337ca50/src/views/admin/components/metadata-types/);
- In the folder, create the `class-tainacan-attachment.php`, implement its methods such as, `get_value_as_html`, `validade`, etc;
- The content here will depend a lot on the options implemented and on some decisions related to how things will be stored (see discussion bellow);
- Two references for this file are the [Relationship](https://github.com/tainacan/tainacan/blob/develop/src/views/admin/components/metadata-types/relationship/class-tainacan-relationship.php) and [Taxonomy](https://github.com/tainacan/tainacan/blob/develop/src/views/admin/components/metadata-types/taxonomy/class-tainacan-taxonomy.php) type classes;
- The logic here may use or require changes in Tainacan [Media](https://github.com/tainacan/tainacan/blob/develop/src/classes/class-tainacan-media.php) and [Private Files](https://github.com/tainacan/tainacan/blob/develop/src/classes/class-tainacan-private-files.php) classes, already used by attachments.
- In the folder, create the `TainacanAttachment.vue` component, which should hold the visual component that will appear in the item edition form and perform the API requests for updating the metadata value. This component may be heavily inspired by the existing [Item Attachments Edition Form](https://github.com/tainacan/tainacan/blob/develop/src/views/admin/components/edition/item-attachments-edition-form.vue), which lists attachments and communicates with the [WordPress Media Library](https://github.com/tainacan/tainacan/blob/fdaf1cf9a32ae4d0296b2be41d0b68999337ca50/src/views/admin/js/wp-media-frames.js#L3) instances [created in the Item Edition Form component](https://github.com/tainacan/tainacan/blob/fdaf1cf9a32ae4d0296b2be41d0b68999337ca50/src/views/admin/components/edition/item-edition-form.vue#L1581). We might want to implement other features such as direct drag and drop support or even debate if the WordPress Media Library should still be used here... but let's see. This component must be define [here](https://github.com/tainacan/tainacan/blob/fdaf1cf9a32ae4d0296b2be41d0b68999337ca50/src/views/admin/components/metadata-types/tainacan-form-item.vue#L185).
- In the folder, create the `FormAttachment.vue` component to hold the options form for this metadata type. This will only be required if we end up implementing some of the desired options mentioned above. This component must be imported [here](https://github.com/tainacan/tainacan/blob/fdaf1cf9a32ae4d0296b2be41d0b68999337ca50/src/views/admin/components/edition/metadatum-edition-form.vue#L411);
## Discussion
There are some topics open to discussion and decisions that have to be made for implementing this:
- **What will be stored in the metadata value?** Which is the actual [`primitive type`](https://github.com/tainacan/tainacan/blob/fdaf1cf9a32ae4d0296b2be41d0b68999337ca50/src/views/admin/components/metadata-types/metadata-type/class-tainacan-metadata-type.php#L24) of this metadata?
- The most obvious solution is possibly the attachment ID. This way we can still reference the attachment to a [WP Media object](**url**) just like we do with the existing item attachments.
- The downside of this is that we would not be able to perform search in fields such as the title, description and caption of the media. We would end up facing limitations similar to the ones we have with the Relationship metadata;
- Looking further, there will be possibly a desire to search PDF contents as well. However, storing a serialized version of this data can be complicated...
- If we are going to use the WP Media, to which post will be the attachment attached?
- Item attachments are bound to the item because we set the item id as the `post` field of the media object. But in this situation, the bounding should really be to the item metadata... which is not an entity, but a relationship between the item and the metadata. This decision impacts on using the WordPress media library because [it loads its content based on query logic](https://github.com/tainacan/tainacan/blob/fdaf1cf9a32ae4d0296b2be41d0b68999337ca50/src/views/admin/js/wp-media-frames.js#L61) that would have to be aware of this scope;
- How are we going to enable its component in the Item Submission Block?
- The WordPress Media Library cannot be loaded in the context of a public page such as happens when we use the Item Submission Block. There we ended up making a simplified file upload form to send the item attachments and documents... maybe it will be the case for this metadata as well, but a single solution would be better...
- If an item is sent to trash or permanently deleted, what will happen to its attachments?
- Are we going to allow sorting attachments as we do in the item attachments?
- It may be feasible, but may cause some confusion as [we need to allow this for other metadata type](https://github.com/tainacan/tainacan/issues/421) as well... If using the WP Media API, we can use the `menu_order` param to store this information. But if in the end we only store an array of IDs, couldn't this be achieved by rearranging it?
- It might be a good moment to think of a way for offering more than one "view_as_html" option for metadata values. Attachment, alongside GeoCoordinate, Relationship and URL are information that may be displayed in very different ways inside view modes like Table and Records or in single item pages.
O caminho que algumas pessoas seguem para contornar o caso dos anexos é criar um metadado de relacionamento com uma espécie de coleção de mídias. Mas isso tem desvantagens, nem sempre a visualização sai do jeito desejado.
Obrigado pela resposta, mas isso é uma feature que deveria ser pensada, pois algo como por exemplo um quadro tem a foto frente e verso, a frente pode ir a publico, mas o verso deve ficar privado. Seria muito bacana algo assim. De qualquer forma, ótimo trabalho.