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; } } }

UI file list breaks after 6.7.2 SP2 UG

miletwo

Hoping someone else has noticed similar issues and has a resolution. I'm pretty sure there is a setting related to this in the iw-webd (apache) instance but I can't for the life of me find it/fix it.

What's happening is that if you click on a folder in professional that has more than a hundred or so items, the page in that frame fails to load completely truncating the HTML with incomplete tags and breaking the interface. If you set it to paginate the results to fewer, when you click on next, there is nothing displayed at all.

See attachment.

Solaris 9, TeamSite 6.7.2 SP2. Upgraded to 6.7.2, then 6.7.2 SP2.
We have confirmed that this behavior does not exist in our other (6.7.1 SP1) enviros.

Find more posts tagged with

Comments

CRB

that is strange. try rebuilding the webapp after the install... and watch for any compiler errors.

miletwo

Hey Chris, thanks for the reply.

I did rebuild the webapp, even going so far as to remove the existing customer.war file so that it would force rebuild. I also tried commenting compress.conf from the iwwebd.conf.template as well as removing fastcgi from httpd.conf/iw.webd.conf (templates of course) to see if that was the culprit. No dice.

Still in no mans land.

miletwo

Update: It also does not happen in every area, but consistenly occurs in this area. We have another folder in another branch with 12,000 files and it displays fine (100 at a time, of course)

CRB

are you testing from different machines with different browsers? does this happen from anywhere you access the folder it? could it be some broken js code which you could resolve by cleaning the browser cache? do you see in js errors?

12000 files in a single file is way too much for teamsite. even if it is working for you, i would suggest you break it down into subfolders if possible.

sometimes deleting iw-home/httpd/webapps/content_center and iw-home/servletd/work/Catalina folder and restarting teamsite helps after rebuilding.

it will be hard to reproduce this kind of issue so i dont have 12000 files Smiley Happy

Bar_Chart2(1).rptdesign

saurabh4984

Hoping someone else has noticed similar issues and has a resolution. I'm pretty sure there is a setting related to this in the iw-webd (apache) instance but I can't for the life of me find it/fix it.

What's happening is that if you click on a folder in professional that has more than a hundred or so items, the page in that frame fails to load completely truncating the HTML with incomplete tags and breaking the interface. If you set it to paginate the results to fewer, when you click on next, there is nothing displayed at all.

See attachment.

Solaris 9, TeamSite 6.7.2 SP2. Upgraded to 6.7.2, then 6.7.2 SP2.
We have confirmed that this behavior does not exist in our other (6.7.1 SP1) enviros.

I have faced this issue... and I have reported it to IWOV. They have provided a temporary work around. Here it goes...
1. Take a back up of the folder
2. Rename the folder
3. Delete the old folder
4. again rename the old folder back to its original name.

This should solve your problem

mart2001

You can whip up a quick perl script that can create 12,000 files quickly....

are you testing from different machines with different browsers? does this happen from anywhere you access the folder it? could it be some broken js code which you could resolve by cleaning the browser cache? do you see in js errors?

12000 files in a single file is way too much for teamsite. even if it is working for you, i would suggest you break it down into subfolders if possible.

sometimes deleting iw-home/httpd/webapps/content_center and iw-home/servletd/work/Catalina folder and restarting teamsite helps after rebuilding.

it will be hard to reproduce this kind of issue so i dont have 12000 files .

Adam Stoller

...
12000 files in a single file is way too much for teamsite. ...

TeamSite (iwserver) actually handles this without any problem. As I pointed out in another thread, the problem with so many files in a single directory (within TeamSite) comes into play when trying to traverse through those directories using the file system interface within a custom script, or when displaying the contents of those directories within the GUI having selected "Show All".

Yes - it is best to have less than 500 files (and immediate subdirectories) within any given directory, but it's not "way too much for eamite"

vpatel

TeamSite (iwserver) actually handles this without any problem. As I pointed out in another thread, the problem with so many files in a single directory (within TeamSite) comes into play when trying to traverse through those directories using the file system interface within a custom script, or when displaying the contents of those directories within the GUI having selected "Show All".

Yes - it is best to have less than 500 files (and immediate subdirectories) within any given directory, but it's not "way too much for eamite"

In addition to what Adam said, just for a moment forget what the tool can / can't do and take a step back and think why you are using such a tool to begin with? For *content management*. If there are 12,000 files in a single (free for all) directory then there isn't much of management/organization, is there? It probably makes sense to break them down further logically into directories / sub-directories. This will also provide a better user experience and probably a lot more flexibility down the road if things are a bit more organized :-)!

My $0.02!

mdang

The OP's problem is an known issue. Upgrading to the latest patch or asking specifically for the black patch will solve this. This is due to a CSSDK / user id issue.

As far as the number of items in a single directory threshold, I would recommend <1000. Performance tests showed that TeamSite could stand up pretty well for <1000 directory listing.

As someone already mentioned, a 1000+ item list, besides performance issue, it gives bad user experience. What could you do with a 1000+ item list anyway. It is a waste of CPU power and network bandwidth. Smiley Happy

mvusthipalli

Yes, this is a known issue. We have been experiencing the same issue.

Support asked us to send the exact TeamSite build information and then they sent the black patch to update teamsite.tk.war and cssdkiface.jar files. So I would recommend you to open a case and get these files specific to your build and apply the patch.

CRB

or when displaying the contents of those directories within the GUI having selected "Show All".

that is the reason behind my answer, "Show All" is usually the user's favorite view since they can run browser search (for a word in file name) and don't have to guess the page number. it works great till it hits a folder with the 1000s of files. then the user has to switch to pagination to get around it. it also makes sense to use pagination because i wouldn't want a list of 12000 files even if teamsite was able to render it fast enough.

the annoying part is having to manually switch between the 2 views, and having to remind some users that teamsite is not slow and they need to switch the view. it would be nice to have a configuration to automatically switch between pagination and show all based on the number of files in a folder.

pann0204

Hoping someone else has noticed similar issues and has a resolution. I'm pretty sure there is a setting related to this in the iw-webd (apache) instance but I can't for the life of me find it/fix it.

What's happening is that if you click on a folder in professional that has more than a hundred or so items, the page in that frame fails to load completely truncating the HTML with incomplete tags and breaking the interface. If you set it to paginate the results to fewer, when you click on next, there is nothing displayed at all.

See attachment.

Solaris 9, TeamSite 6.7.2 SP2. Upgraded to 6.7.2, then 6.7.2 SP2.
We have confirmed that this behavior does not exist in our other (6.7.1 SP1) enviros.

OOOh, so this is repeated in 672 SP2 as well, I have faced similar issue, after some simple investigation found that this happened because of some files on the name of deleted non-os users. You can resolve this issue with a simple script by setting access and setting groups for the files and folders in the workarea and later submit them all to staging .....
Magic !!!! u'll not see these html snippets in ur workarea Smiley Happy

Regards,
Pawan

pann0204

Yes, this is a known issue. We have been experiencing the same issue.

Support asked us to send the exact TeamSite build information and then they sent the black patch to update teamsite.tk.war and cssdkiface.jar files. So I would recommend you to open a case and get these files specific to your build and apply the patch.

Did it work for you???

Regards,
Pawan

mvusthipalli

yes, it does Pawan. They said it also fixes other issues related to the same kind.

miletwo

Hey everyone. The issue has been resolved by KB 49980 and 58602. Essentially it breaks on invalid non-existent users. Workaround is:

=================================================================================
RUN: (to export users)
iwidmap -u -x ~/usermap.xml /default
=================================================================================

Search in file for:

Replace with:

=================================================================================
REIMPORT:
iwidmap -u -a -i ~/usermap_new.xml /default
=================================================================================

(of course this is specific to Solaris -- revise accordingly for Windoze)

mvusthipalli

But you can not run iwidmap every time some user has been deleted from the domain or OS since every iwidmap command run requires TeamSite recycle not even reset.

miletwo

But you can not run iwidmap every time some user has been deleted from the domain or OS since every iwidmap command run requires TeamSite recycle not even reset.

This is true. This is still a FAIL in the product IMO. The UI should not take a dump every time a user disappears. I'm going to "expect" that AIW will fix this in a future release. Until then, I have a workaround. Albeit a very CRAPPY one since applying it requires a reboot. This is NOT windows... I shouldn't have to restart to make it work.

That said, I could probably stop all IW services, umount and mount the IWFS and be back in business, but... really... c'mon kids. How about just the UI doesn't barf on invalid users/chars?

ListBoxParameterInReport.rptdesign

mvusthipalli

They do have a fix for it, that's why I said, open a case so that you will get the updated war file, which is going to fix the issue permanently and you will not need to do this work around always...

Adam Stoller

Just fixing formatting for those who might want to read the information as it was intended.

Hey everyone. The issue has been resolved by KB 49980 and 58602. Essentially it breaks on invalid non-existent users. Workaround is:

=================================================================================
RUN: (to export users)
iwidmap -u -x ~/usermap.xml <iw-store>/default
=================================================================================

Search in file for:
<NAME data="\d+"

Replace with:
<NAME data="iwts" (or some other valid user)

=================================================================================
REIMPORT:
iwidmap -u -a -i ~/usermap_new.xml <iw-store>/default
=================================================================================

(of course this is specific to Solaris -- revise accordingly for Windoze)

miletwo

They do have a fix for it, that's why I said, open a case so that you will get the updated war file, which is going to fix the issue permanently and you will not need to do this work around always...

Funny... I did exactly that. The tech that responded gave me the info about mapping UIDs. I would have much preferred they gave me a war file that fixed it permanently. I will have to reopen my ticket.

Thanks for the info.

mvusthipalli

It's really tough to work with some guys there Smiley Happy

.

It might be useful to tell the support engineer to talk to the support guy that helped me out with this case. He is John Reinhard. He has already dealt this issue and fixed it for 7 customers.

nipper

..... He is John Reinhard.....

I am glad to hear John is still around, he is top notch. I have not had him on a case for a while (my cases are answered out of India - probably because I submit via the web instead of calling it in).

mvusthipalli

I heard that they have lot of freshers being recruited now a days Smiley Happy

mdang

that is the reason behind my answer, "Show All" is usually the user's favorite view since they can run browser search (for a word in file name) and don't have to guess the page number. it works great till it hits a folder with the 1000s of files. then the user has to switch to pagination to get around it. it also makes sense to use pagination because i wouldn't want a list of 12000 files even if teamsite was able to render it fast enough.

the annoying part is having to manually switch between the 2 views, and having to remind some users that teamsite is not slow and they need to switch the view. it would be nice to have a configuration to automatically switch between pagination and show all based on the number of files in a folder.

There are 2 better solutions.

1. Organize the directory with huge number of files into sub-dir tree so user won't need to look at a large list and do browser search. This even applies for files in a plain OS filesystem. A few thousand files under a single folder wouldn't be so user friendly even viewing from Windows explorer.

2. Use TeamSite search rather than browser search.

--Michael

kresko

(Newbie. First time poster. Glad to see my problem has a current thread.)

Running TeamSite 6.7.2:
I ran into this problem for a directory containing 27 files. Therefore, that is not the issue. My problem happened when I copied iw-store from one machine to another. Not knowing the posted iwidmap solution, I thought the problem may be related to missing or inconsistent uid/gid data between the two machines. I therefore made sure all of this was consistent and the problem was resolved.

However, I agree that the iwidmap solution is not sustainable. Anytime an account gets removed, one shouldn't need to run a manual patch. I await an official update.