CMDBuild Forum

Filter Behavior in Version 2.1.5 vs 2.1.4

I need to clarify the behavior of the filter in grid view..

When I apply filter and work on a subset of the data, I would assume that I would stay in the same filtered set instead of being thrown back into the whole data with the filter removed after each save to a record. It seems that when I saved a record changing the field that is being filtered, CMDBuild will follow the record and reset the filter. I would want Instead, CMDBuild to stay on the same filter and hide the record from the filtered set if the data no longer satisfy the filter.

I am working on a whole set of 12000+ records. When new data inserted by my assistants, I would default an attribute (called verified) to false. After I verify the information is correct, I would set the value to true. So, When I filter with "verified = false", to just focus on the newly added records I would loose my filter every time i save a record and have to reapply the filter. Which is time consuming and defeat the reason why I created the workflow in the first place which is to make verification faster.

I believe this behavior that I observed has changed from previous version 2.1.4. Can you please clarify and if this is true, will this be the intended behavior or would you change it back (stay with the filter and hide the record).

I would like to add that filters created with multiple attributes doesn’t give any result.

 
I wonder if this is a bug.
Please let me add to the statement - It is when the Filter is set to have Input parameter..
 
Previously Zahri wrote:
I would like to add that filters created with multiple attributes doesn't give any result.
 
I wonder if this is a bug.

 

We confirm to you that this is the intended behavior.

If you change the filtered field, CMDBuild will follow the card and reset the filter.

CMDBuild Team

Thanks for the answer.. But would the team consider changing this behavior. I am not sure if you already know this but the behavior is also persistence to the Views. 
 
I have a class called Documents. In the class, I created an attribute called Maturity with possible lookup values of Draft, Approved, and Obsolete. I define a view in Administrator called Approved Documents and set the filter to Maturity equals Approved. When my users use the view they would check for documents that are obsolete and then change the Maturity to Obsolete. When they save the card, the filter is gone. Now they are presented with the entire recordset. The only way to get back the filter is to navigate to other view and comeback to the same view. The view is then reset and the user have to restart his checking from row 1 page 1. I found this to be an ineffective use of views and time consuming.
 
It would be nice if the View and the filter would stay filtered and stay on the same page of the recordset with the unmatched records removed. This would be a more natural way to work with views and filter.
 
Previously Tecnoteca wrote:

We confirm to you that this is the intended behavior.

If you change the filtered field, CMDBuild will follow the card and reset the filter.

CMDBuild Team

 

Thank you for your suggestion, we have added it in the list of things to do.
Unfortunately, we can not say at the moment when it will be implemented.
There are many new features that we would like to develop, and we must proceed according to the priorities of the project.
CMDBuild Team

 

 

This is a great news.. I will tell my users that the issue is currently being look at and a solution will come. They just have to be patient with the current situation. We are planning to use CMDBuild for the next 10 years in our Shipbuilding Project. We are using it as our Main Configuration Database. We are very happy with the system. Thank again.
 
Previously Tecnoteca wrote:
Thank you for your suggestion, we have added it in the list of things to do.
Unfortunately, we can not say at the moment when it will be implemented.
There are many new features that we would like to develop, and we must proceed according to the priorities of the project.
CMDBuild Team

 

 

 

We thank you for your positive considerations about CMDBuild.
If you think that your experience will be useful to tell to other users you can send us a small case study to be published in the specific section of the  CMDBuild website.
CMDBuild Team

 

 

 

Dear Tecnoteca Team,
 
We have deploy CMDB as the management frame tool for our shipbuilding program. The details of the program is classified but we can share how we use cmdb. It may take sometime for me to write the white paper. But sure, it has been a good experience for me. I am also looking forward to see how OpenMaint is deployed. This would be a good reference for me too. I will keep on supporting the tool and this forum. My two thumbs up for you guys.
 
Previously Tecnoteca wrote:
We thank you for your positive considerations about CMDBuild.
If you think that your experience will be useful to tell to other users you can send us a small case study to be published in the specific section of the  CMDBuild website.
CMDBuild Team

 

 

 

 

I have decided to go and see if I can change the behavior myself. I guess what I found out. By changing a Boolean from tru to false the behavior change and it stay with the filter. This is very helpful with views. I have created a few views to cater for different group of people to filter the records by row. A user have found out a way to circumvent the filter by changing a value of the data and once the row got out of the view the whole view become exposed. "The filter is gone". CMDBuild will follow the record just went out of filter by remmoving the filter. This is not good for me.
 
If you want to change the filter behavior to stay on the filter and not follow the record open the the file below and make the change as shown.
 
Edit file: ./cmdbuild/controller/management/common/CMCardGridController.js 
Goto: Line 202
Change line to: var retryIfTheCardIsNotInFilter = false; 
 
Previously Zahri wrote:
This is a great news.. I will tell my users that the issue is currently being look at and a solution will come. They just have to be patient with the current situation. We are planning to use CMDBuild for the next 10 years in our Shipbuilding Project. We are using it as our Main Configuration Database. We are very happy with the system. Thank again.
 
Previously Tecnoteca wrote:
Thank you for your suggestion, we have added it in the list of things to do.
Unfortunately, we can not say at the moment when it will be implemented.
There are many new features that we would like to develop, and we must proceed according to the priorities of the project.
CMDBuild Team