nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Hide or Should not give access to Click on Folder

PD007

Hi,

I have one datatype as "website", Inside website->data there are 80,000 DCR's. TS 6.7.1

Our Problem is -: by any change, if any user clicks on website->data folder. Its hikes CPU utilization. that i want to avoid.

For other data types(product,sales), whenever we generate these other datatypes i have also creating one DCR in website->data folder. therefore its count is now 80,000
I cant set permission in templating.cfg because of each and every user require access to generate his common file in website->data..

I just want to hide or not giving access to click data folder under website data type.

Any customization will help here? or any temsite fanda help me in that to hide data folder? version TS 6.7.1
Please help.....

Find more posts tagged with

Comments

Adam Stoller

I have one datatype as "website", Inside website->data there are 80,000 DCR's. TS 6.7.1
...
Please help.....

This issue has come up many times in these forums and the last time was not that long ago:

You are at that last point - you need to think, plan, and implement a better directory structure for managing your DCRs - which may involve having to add FormAPI code, perhaps add fields to the DCTs (preferably without changing the structure of the DCT), and will definitely involve creating sub-directories and relocating the 80,000 DCRs into those various sub-directories.Your goal: break things up so that no single directory contains more than 500 entries (that includes both files and sub-directories). So you're looking to create somewhere on the order of 160 sub-, sub-sub-, sub-sub-sub-directories (etc.).

PD007

Thanks for your reply Adam,
I have have also proposed that solution but its require overall design change and same portal implementation. i have already scope in future development.
but thinking about current situation i have to give something that reduce my CPU spikes. and this issues is exist on production. therefore i am searching any quick solution to resolve my production box problem.

Your goal: break things up so that no single directory contains more than 500 entries (that includes both files and sub-directories). So you're looking to create somewhere on the order of 160 sub-, sub-sub-, sub-sub-sub-directories (etc.).

Adam Stoller

Thanks for your reply Adam,
I have have also proposed that solution but its require overall design change and same portal implementation. i have already scope in future development.
but thinking about current situation i have to give something that reduce my CPU spikes. and this issues is exist on production. therefore i am searching any quick solution to resolve my production box problem.

There is no "quick" solution - the implementation is/was flawed, the solution is to fix the implementation - period.
The problem you have now will manifest itself both when viewing the contents of that folder, or when trying to create a new DCR within that folder as the entire contents will need to be gone through to determine that there isn't a file naming conflict.

nipper

You are screwed. There is no way around it. You must break that folder up into at least 200 folders. That will be a significant effort. There is no way around it.

Tell you manager to bite the bullet and get it taken care of. No tool will be able to handle that, because the underlying OS won't handle it. If whoever originally designed it is still around, they should be fired, anyone with knowledge of this should have been reasing a red flag since it got over 1000.