Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roadmap #2

Closed
mileo opened this issue Jun 8, 2020 · 9 comments
Closed

Roadmap #2

mileo opened this issue Jun 8, 2020 · 9 comments
Labels
stale PR/Issue without recent activity, it'll be soon closed automatically.

Comments

@mileo
Copy link
Member

mileo commented Jun 8, 2020

Hi,

I would like to help with the migration. Do we have any plans for this?

Could I migrate the module https://github.com/muk-it/muk_dms/tree/12.0/muk_dms_attachment ?

Thanks in advance

@pedrobaeza
Copy link
Member

pedrobaeza commented Jun 8, 2020

In fact I would consider this as a must in core module. I think there's not too much sense in embedding the file contents in DB, but putting it as attachment=True, and no need to add all of these burden, having automatically the benefits of attachments:

  • No duplicated content
  • No DB size increase

What do you think, @etobella @keshrath ?

@etobella
Copy link
Member

etobella commented Jun 8, 2020

Well, Right now it is contempled on the original dms module. When you define the type of the dms.storage you can choose:

  • Database: files are embedded on the database
  • Filestore: files are managed as attachments, so I think it is not necessary to continue on this.

However, I think it would be interesting to check the version system in order to proceed that way

@pedrobaeza
Copy link
Member

I was thinking that filestore was for importing an existing server path and parse its contents... but if it's already attachments, I think the other type (database), it's not interesting to be kept.

@mileo
Copy link
Member Author

mileo commented Jun 9, 2020

MuK Documents is a module to create, manage and view files directly within Odoo. MuK Documents Attachment allows to store Odoo Attachments inside the Document Management System. Attachments stored in the document management system are still available as attachments in Odoo. As with all other files, the storage type can be set via the setttings.

I believe that we can have a configuration where the user specifies which models he wants his attachments to become documents in the DMS module.

In addition, the possibility to classify them with tags in a simple way.

Document data in DMS should be easy to search, for example by model (model_id and rec_name).

With the document data well structured we can for example create customizations:

a - Documents attached to the product category, tagged with MRP;
b - Documents attached to the product, tagged with MRP;
c - Documents attached to the Bill of Material, tagged with MRP;

  1. Attachments for items a, b, c are automatically displayed in a production order;
  2. If you search in DMS by a production order you get the same a,b,c documents;

@pedrobaeza
Copy link
Member

OK, if the idea is that any attachment in the system in a configurable way - not by default -, becomes a DMS document, I support that idea. Is that what muk_dms_attachment does? If so, go ahead with dms_attachment!

@keshrath
Copy link
Member

keshrath commented Jun 9, 2020

MuK DMS Attachment uses the DMS to store Odoo Attachments. The basic idea behind that is that you can have all the Odoo Attachment in a structured way.

@pedrobaeza
Copy link
Member

I would prefer some kind of synchronization between ir.attachment and dms.document if possible instead of a "replacement". Why? For avoiding glue modules with other modules that modifies one of the involved models.

@keshrath
Copy link
Member

keshrath commented Jun 9, 2020

Yes that might be true. Currently the module adds a store option documents like filestore or database for attachments.

@github-actions
Copy link

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.

@github-actions github-actions bot added the stale PR/Issue without recent activity, it'll be soon closed automatically. label Oct 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale PR/Issue without recent activity, it'll be soon closed automatically.
Projects
None yet
Development

No branches or pull requests

4 participants