Add documents to projects
dottorer opened this issue · comments
Similar to #307 (see spec here), we need to allow documents on projects.
I am going to begin working on this
Should the projects page have a tab for documents, identical to the list of documents a user sees if they click into the Documents page from the dashboard?
Since documents are going to live on many different objects now, the dashboard view should have lists for all the different objects with documents (circles, working groups, projects, etc.) and each object's dashboard should have a list that is relevant to them.
Thoughts?
Hi @jprokay Thanks for your start on this. I think on the projects level, it would be great to do this with a tab as you outline. This is essentially following the approach we have on work groups.
Ideally we could connect with @NolanChan and see if we could get the tiled layout for this tab worked on as well as this changes the appearance of documents system wide.
Lastly, you have a good point on the 'document repository' view that there are now many more documents to be had. However, it makes little sense to me to expose documents that are attached to tasks, supplies or projects on the repository. We should stick there with circle level docs and work group level docs as described in the spec.
Thank you for the feedback @dottorer! Should the Documents tab have a count of the documents next to it, similar to Tasks & Supplies?
Yep, on projects that would be helpful...good idea.
Great! I will finish up this first iteration and wait for guidance on the tile view.
@phillipoertel Regarding translations: since files are now part of projects, which are a part of circles...should I copy the translations for files in each of the .yml files to circles.projects.files.list, or move them? Or should I use the existing translations under files, i.e.: t('files.list.new-file').
I am not sure the best way to do translation management!
@jprokay as always, it's best not to duplicate lots of stuff, so unless you need to actually translate the messages differently, I wouldn't do that. I'd use the existing i18n keys from the new views. You'll have to use absolute keys to access them, so t('files.list.confirm_delete_file') rather than t('.confirm_delete_file').
To be very clear you could rename/move the keys to a more general namespace so they make sense in both views.
@phillipoertel Thank you for the information! I typically assume that duplication is something we wish to avoid, but the structure of the .yml made me think otherwise. I might move them into 'circle.files.list' since now so many Circle-related objects (projects & tasks) will leverage them.