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

TeamPortal: Missing Base Functionality

System

Recently, I've had the pleasure of integrating TeamPortal. We found that there were a number of short-comings. Here are the most obvious that we found:
1) Each user can only be assigned to one branch and one workarea. You don't have the option of switching workareas.
2) Group tasks will not work within TeamPortal because there is no mechanism to take ownership. However, user tasks do work.
3) CGI tasks will not work within TeamPortal without a great deal of customization to the TeamPortal code. This includes the MetaTagger CGI task.

The workarounds for these short-comings are kloodgey. The workaround for #2 is to create a set of parallel user tasks which will act as the "Take Ownership" tasks. Then have an external task which determines which user task did the transition and who owns that task. Then it changes the ownership and activates the group task.

Anyone else had similar experiences with TeamPortal? Any helpful solutions?

- Jason

Find more posts tagged with

Comments

Migrateduser

jmeyer,
It is possible to get around the first limitation by implementing your own workarea mapper. See the documentation for details on how to plug in your own workarea mapper into the portal; the gist of it is write a class that implements the interface, change an entry in tsPortletSystemConfig.xml and then restart the TeamPortal server (not sure which implementation you're using - if it's IBM, restart the portal server, if it's Plumtree, restart the gadget server, if it's jetspeed, restart the container).
What you need to do is write a database or flat-file implementation of the workarea mapper that has an additional method: setDefaultWorkarea(). Couple this with getDefaultWorkarea() to allow a user to change workareas.

Basically, TeamPortal will use the value returned by getDefaultWorkarea() as the workarea being used. If you build a UI to manipulate this value, you can effectively switch workareas, however, only one workarea can be active at a time.

HTH,
Navneet

Migrateduser

Thanks for the reply. Are you saying that we can dynamically change the workarea, but it changes it for ALL users? If that is what you're saying, that still doesn't seem like an acceptable solution. Also, I'm sure that you can agree with me that it should be built-in functionality.

- Jason

Migrateduser

jmeyer,
Typo in my message: the method is called getDefaultWorkareaForUser() and is, as the name suggests, per user.
Re. whether it should be built in functionality, I can't comment on that; it was a product decision driven by a goal of ease of use for naive users who didnt want to really know what a workarea is - having to select one would violate that principle. I will pass on your feedback to the relevant product manager, though.

Migrateduser

Thanks for the clarification. I can definately understand users not understanding what a workare is, but the administrator should at least have the option/ability to assign different workareas to different users and different docroots for different users. The only workaround that I can find is to create a separate portlet for each workarea in each branch. Very time-consuming and not very user-friendly.

- Jason