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

No Workareas Found in CC Standard

mike_s

We are using TeamSite 6.5 on Solaris.
We recently installed SP1, although this was only to get the latest version of iwfsck installed I believe. The problem described below occurred before SP1 was applied but has not been fixed by the application of SP1)

Using CC Pro allows access to workareas, everything seems to be accessible.
However, when using the same user id & role CC Std the 'My Workareas' portlet shows only the message '- No Workareas Found -'. The 'New Forms' portlet shows the message '- No Forms Found -'

The workareas are definitely there and my user id has permission to edit the files both via the CC Pro UI and the command line.

We have been using r-synch to copy updates from our live server (running 5.5.2) to this 6.5 server, using iwfreeze beforehand on both source and target servers.

There have been some minor UI tweaks but I'm doubtful that any would have broken CC std in this way.

My suspicion lies with the backing store (despite the fact the CC pro does not seem to have any problem accessing it).

Does anyone have any suggestions?

Digging around at the command line I've noticed that /iwserver does not mirror the branch structure in the way that it does on our 5.5.2 server. Could this have anything to do with it?

Find more posts tagged with

Comments

Adam Stoller

I'm not sure - but I think the My Workareas portlet only shows workareas that the user *owns* - not those they have access to via group-for-sharing.
Try creating a workarea (within CCPro) owned by the user - then login to CCStd as that user and see if it shows up.

Not sure about the templating thing - frankly I almost never use CCStd so I can't offer too much advice on this issue.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

smenon

You might also want to check if you have turned on the following configuration to enable the "Edit My Workareas" functionality in the "My Workareas" portlet. This customization is made in application_custom.xml and you might want to look for

<param id="iw.common.my_workareas.configurable.property" value="true">

If you have turned this on and you haven't selected any workareas, then that list will be empty. By default this configuration is turned off. I believe that the other CCStd portlets are also displaying the list of workareas based on this selection which might explain why your Forms portlet is also empty.

This is just a hunch. If this is not the case, then you might want to log a case with Tech Support for a deeper investigation.

thanks

--Sunil Menon
Sr. Product Manager
Interwoven, Inc.

mike_s

Thanks for the post. The 'My Workareas' is not event showing workareas I own. We have another installation which displays both the workareas I own and ones which I have access via the group owner.

Any thoughts on the iw_server situation? This does look a bit odd to me but as I don't know what iwserver is used for it might be a red herring.

We currently have a support call out for this but the only suggestion so far is to run iwfsck which we are doing. The only trouble is that this is taking a long time to run (over 9 hours on last attempt).

I'm trying to come up with other solutions in the mean time.

Many thanks

mike_s

Thanks for the suggestion.

However, I've reverted the application_custom.xml to the default empty file and rebuilt the webapps and nothing has changed.

Also, I created a new content store (stop TeamSite, change path in /etc/defaultiwstore, start TeamSite) and created a new workarea. This new workarea is visible via the CC std interface. A corrupt backing store seems the likely culpret at the moment.

Unfortunately, running iwfsk took over 20 hours and produced no output (another indicator of corrupt content store perhaps?), so we are going to take a fresh copy of the live content store and see whether that fixes things. I'll try to remember to update this post with the outcome.

mike_s

It turns out that the solution has been to take a fresh backup of the content store and replace what must have been a corrupted content store.

We suspect that the corruption was caused by rsync.

We do want to use rsync to synchronise the content stores between two servers and so I would appreciate any comments on the proposed method of performing this task on a daily basis, which is as follows:

1. Stop target TS server completely – I’m not confident that an iwfreeze will be good enough when overwriting the backing store
2. Take copy the backing store on target TS server to enable backout of possible corruption caused by rsync
3. Freeze source TS server
4. Run the rsync process
5. Unfreeze source TS server
6. Restart target TS server

Thanks in advance

bugreport.rptdesign

Adam Stoller

While not directly involved with the process at one of my former customer's site - I believe their process went something like this (nightly process):
[on-server backup]

http://www.quotient-inc.com