increase the maximum number of columns when creating a new filter view for the list view

In times of big monitors, we can easily have more than 12 columns per list view. I just increased the value in layouts/vlayout/modules/CustomView/resources/CustomView.js to 15. But soon this can be even more. Let me know if I should just create a merge request for the changed value or if you want this to be added through the config, somewhat more sustainable and adjustable for each installation.

On a User interface perspective we have restricted the count to 12.Can you please explain the Business Scenario for this request.

Not sure I understand what you mean by business scenario...

We would like to see more columns than 12. 15 at least. In a few years maybe even more. Because screen sizes are getting bigger and bigger, resolution gets bigger and bigger, more and more information fit on one screen. I would also like to decide myself how many columns is enough or too much. Vtiger should not decide this for me. But it's impossible without hacking vtiger core files, so I would like to make this more configurable. That's out scenario? ;)

Added suggestion label

Thanks for the explanation.We will check the dependencies and get back to you

I'm happy to read you are looking into this. I would love to help, but have no clue where to start and which approach to take. I have adjusted the value in layouts/vlayout/modules/CustomView/resources/CustomView.js, but this does not seem very sustainable to me... Anything I can help out with?

@preexo You can send an ajax request to the back-end files to get the configuration value , and use this value in the CustomView.js to update the no of columns.

Hi Manu,

thanks for the direction hint, I started implementing but facing two questions. I'm basically lacking general vtiger architecture understanding, so I don't know where to put shit...

• Where should I store the configurable key/value? In a table, if yes which one? In the config file?
• I'm currently extending the class CustomView_EditAjax_View so that it can handle two requests, one for the template(already exists) and one for the column-count value. So should CustomView_Record_Model get another method to return the URL which for the ajax request to get the column-count? Or can I hard code the URL for the request in the CustomView.js file?

Hi @preexo

You can save this value as a new variable in the config.inc.php file .

Add a new entry to the getEditableFields() api in the ConfigModule.php file to make the new config field a editable. Now from the CustomView.js send a app request call to get the value of this global variable.

You can write a new api in the CustomView_Record_Model class which get the global variable information from config.inc.php file and return the value back to the customview.js file.

Hi Manu, cool, thanks a lot! The whole ConfigModule.php configuration is pretty straight forward, I got that part done, will file a WIP-merge-request later.

I don't fully understand what you mean by "API in the CustomView_Record_Model". As far as I can see, the model class only provides methods which can be used in tpl files - I can't see any other API interface for XHR requests. Is the model really the correct place for this? I would have placed it closer to the View class maybe... But you will know better! Anywhere else in vtiger where something like this is being done and could serve as an example? I could also think of a hidden input which is added to the tpl file and filled from the model, then the JS takes the value of that hidden input.

Sorry for bothering you so much, it was supposed to save you work, not to create work for you. But thanks so much for your help!

@preexo When we are sending some data back to js ,action part is the best place to return the value. As view is used to render the UI its not recommendable.

I realized that the same thing applies for reports, we need to do reports with more than 25 columns. I will include the reports in the same branch. Anywhere else a hard coded limitation of customizing a view which could be solved right now?

Added cleanup and removed suggestion labels

I was stuck here, maybe @manu.k can have a look at what I'm struggling with and give me a hint? http://code.vtiger.com/preexo/vtigercrm/commit/3e2f60960c3d0de260869a20262da748b6ffaf5b

My biggest problem in that commit was: Where should that AJAX call in the JS file know the URL from (I hardcoded one, but that seems wrong) and where does it get the record ID from?

Then I had trouble with accessing the information in the config file through vtiger. I haven't fully understood how they are accessible for me vtiger wide. Here I added the variables to the configuration: http://code.vtiger.com/preexo/vtigercrm/commit/20b20c7994b66b79663aa5a4a0e03d0cb7fd019c

I think I'm just lacking knowledge about how things are done in vtiger, I am trying to find other examples and compare, but it seems to be done different all the time too, so hard to tell what way I should go with this.

Maybe some one can mentor me a bit through this?

@prasad - I asked @manu.k for a little guidance on this 4 months ago, but haven't heard back from him. Can you pick up for him and give me a hint on my previous questions 4 months ago?

The questions are:

• How can the JS file layouts/vlayout/modules/CustomView/resources/CustomView.js know where to send the AJAX request? Should I hard code a URL, what's the vtiger best practice to get URLs for AJAX requests?
• How can I access configuration values made in config.template.php/config.inc.php in vtiger? I just couldn't find how to access those variables properly.

Thanks for helping in advance, I would love to finish this

@preexo - we might need a better design here than just increasing the limit. Having all columns on the list-view also doesn't look usable and could breakdown at higher order.

@prasad - sure, another design approach might be better. Any suggestions? But the problem persists: We need to be able to show 15 columns now. With increasing screen sizes, users will soon probably ask for even more columns. Hard coding 15 has not had impact on performance for us, but I don't like hard coding the value and would prefer a vtiger solution for this. Looking forward to suggestions how to deal with this. Thanks!

@preexo - 15 columns would be too much on 11" screen and may be too less on much wider screen. So the issue will still persist isn't?

@prasad - I understand you concerns, thanks for giving this your attention. But I look at this like that: Someone with a 11" screen can create a view which fits perfectly on the 11" screen, I guess that would be around 4-6 columns, depending on the data being displayed. Us, with our 4k screens can create a view with maximum 12 columns. But we still have free space and would like to fill it up with another 3 columns.

The use case you are describing is already possible, there is no issue, it can be solved by creating a view with less columns.

The use case I am describing is not possible yet, this is my issue, it can only be solved if vtiger allows more than 12 columns.

Maybe you could explain how you came up with this magic number of 12, because to me it seems like a really random number and I come along with another random number (15). So why not make this configurable for the administrator to decide?

edit: I always look at suggestions like this and think if it takes anything away or breaks anything existing or makes anything less usable. It does not, it would only add. Not take away anything of what was there before, so I really don't get where the resistance comes from.

@preexo - 12 was the best fit on our screens! We will review next - don't worry.

We had increased the column selection to (Max 15). We had to set hard-limit on this to avoid usability and performance suffer (when selected columns are spread over or of text type).