Step 3 is left

Hi Mykhaylo, your progress sounds great. Looking forward to seeing this work.

Once your changes are done, I'd be curious to find out what you thought about the framework and code. The code was started around 1999 and there wasn't much in the sort of frameworks to leverage. The first version of TE was all done in JSPs and then moved to an MVC architecture before Struts/Hiberate/DAO became commonplace.

Anyhow, congrats on the progress!

Hi Matt,

We need some help. We need to know the current user id in WikiUtils parsLine method to determine permission to see the link.

How to get it? Or there we can see an example?
I guess somehow its possible to pass the id from .jsp into that class.

And is there builtin way to check user acess rights to a wiki page?
Except of direct SQL request

I'll research and reply later today with solutions. Not sure without diving into the code.

I've looked through several areas and came up with the following possible solution...

In Search.java, when a user performs a search for a given term, the user's permissions are queried across every project and across each tab type. This gives access to every permission that the user has.

Refactoring the buildProjectList method in Search.java into the ProjectUtils class could allow for search and other areas, like Wiki to use this... eventually with a cache.

So each time a Wiki page is viewed, if the user's PermissionList is queried and included in the request, then the links can be determined, otherwise the link defaults to a non-hyperlink. During the parsing, if the projectId and permission are found for the link type, then the link can be drawn.

Similar to the imageList, the JSP could pass the permissionList:

<%= WikiUtils.getHTML(wiki, imageList, permissionList) %>

Thoughts...

Over time, the more projects a user has, the more time it takes to add the PermissionList in every request. It would be nice for both the Search and Wiki to access a cache, possibly in the User's session object. The cache would get updated when the user gains access to a new project, or when the project's permissions change. Storing the PermissionList in the user's session would be the biggest gain.

Also, if a wiki doesn't have any project links, then there is no point in building the PermissionList. When saving a wiki, the parser could store the projectIds and the tabTypes so that processing knows if the wiki should query the projects -- and which projects to check.

In the meantime review the database indexes and make sure the queries are efficient. The search times appear to be negligible for hundreds of projects.

If you want the project's name, then those are already being cached and can be used to build tool-tips or display information similar to ProjectNameHandler.java

Hello Matt,

Unfortunately our developer who was working with TE is no more working in our company and currently we have no time to continue the work.
Can I send to somebodyy our snapshot with changes description to evaluate the code and merge it to the product if the solution is ok. The solution passed initial testing and evaluation locally, but we have not tested it extensively.

Thanks.