Nice to have an indication in tree view if there are attachments or not

Feature Ideas
1

It would sure be nice to have an indication whether there are attachments or not on lines in a tree view where attachments are possible (purchase orders/receptions/invoices/et cetera)…

Something like in email where the paperclip icon is indicated in the attachments (paperclip) column, which doesn’t take up much space either.

Currently one needs to select line by line and click attachments to see if there are any, which is horribly tedious with potentially a large number of records.

Cheers

2

Probably you need a functional Boolean functional field (with a searcher) for those modules to be able to directly search the ones that do not have any attachment.

For me this is something that should be done as customization as it’s only needed depending on the company workflow (some companies may use attachments, others not) but that should not be part of base modules.

3

Maybe it could make sense to have a Mixin that adds the field or even an icon that later can be attached to the name or rec_name fields.

4

This mixin can be added on a custom module and added to all Models using register_mixin.

5

It will be very hard to write such method to be efficient on large set of records. It will be similar to display a One2Many on a list.

For me, the requirement is not clear. In which case the attachment presence is the primary key for selecting a record? The attachment is a complementary information not a primary.

6

Every place where the invoice/reception/PO is missing its attachment!
(actually only since 01/01/19 as a business process requirement)

I’m not specifically asking for filters, but just the visual information such that using standard filters we can identify records are missing attachments.
Then we can simply select each record needing to have them added.
(granted, sorting the resulting tree view by the attachments column would be nice, but not strictly necessary to begin with)

This is why I used the email attachment paradigm…

It is indeed odd that there can be attachments but one has absolutely no clue that they’re there!

7

Which business requirement are you talking about? Where is it defined? What is it?

8

Our internal procedures, naturally. Since accounts of 2018 are already audited, we have no requirement to retroactively add the attachments prior to 1 jan 2019.

9

I think the best solution would be to store a counter on the record which will be increased/decreased when attachment are created for it. This counter then can be displayed, searched or the base of other Function fields and still be efficient.
I think we can have a standard implementation by creating a Mixin that defines the counter and having ir.attachment to increase/decrease the counter if the resource is a subclass of the Mixin.

1 Like
10

I don’t understand where you see the difficulty on making this method efficient. We have much more costly function methods in Tryton (such as invoice amounts or product quantities).

Here, we just need:

SELECT resource, count(*) FROM ir_attachment GROUP BY resource

and it just takes 75ms on a database with 137.000 attachments in my laptop. The filter version of which:

SELECT resource, count() FROM ir_attachment WHERE resource like ‘model,%’ GROUP BY resource HAVING count() > 3;

takes about 30 ms.

In this case, Postgres is using a sequential scan, probably because the table is just 24 MB but with a larger database I think we can expect Postgres to use an Index Only Scan on resource’s index, so it should scale extremely well.

11

For me, 75ms is already quiet an expensive addition.
This is not the queries that will be run because they are missing the filter for a set of ids. And you know that counting is expensive: Counters & performance

12

Well, 75ms is the time taken without filter which means computing the group by for all 137.000 records.

The query that we can expect for the getter function looks more like this one:

SELECT resource, count(*) from ir_attachment WHERE resource IN ('account.statement,10151', 'account.statement,10160', 'account.statement,1017', 'account.statement,1018', 'account.statement,102', 'account.statement,10213', 'account.statement,10253', 'account.statement,10255', 'account.statement,10259', 'account.statement,10276', 'account.statement,1082', 'account.statement,10847', 'account.statement,10855', 'account.statement,10856', 'account.statement,1089', 'account.statement,10897', 'account.statement,11019', 'account.statement,11046', 'account.statement,11062', 'account.statement,11088', 'account.statement,11095', 'account.statement,11112', 'account.statement,11251', 'account.statement,11263', 'account.statement,11305', 'account.statement,11547', 'account.statement,11557', 'account.statement,11702', 'account.statement,11724', 'account.statement,11857', 'account.statement,11952', 'account.statement,12075', 'account.statement,12076', 'account.statement,12078', 'account.statement,12297', 'account.statement,12388', 'account.statement,12391', 'account.statement,12428', 'account.statement,12440', 'account.statement,99999999') GROUP BY resource ;

and this takes between 1ms and 3ms on several execution runs.

13

The IN clause does not scale very well (we can not use the reduce_ids).
But also the searcher will be very fast neither because it will be used in an IN clause which will contain almost all the records.

I still think that it will scale better to have a computed sum on the record which will be index-able.