Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeOur CommunityOur CommunityCommunity Membe...Community Membe...Download the new Open-DocumentLibrary v2.0 BetaDownload the new Open-DocumentLibrary v2.0 Beta
Previous
 
Next
New Post
6/8/2007 12:43 PM
 

Search capabilities are in the works.

The module's documents can be indexed using Open-SearcEngine v2.0's direct directory indexing capabilities.  However, the process is not intuitive and requires some configuration.

We will most likely be including a fully integrated search in the next release.  The search will respect access permissions and count with all the powerful features of Open-SearchEngine, thus allowing to search on the actual data stored in the .doc, .pds. .xls etc... files.

Best Regards,

Andreas

 
New Post
6/8/2007 1:30 PM
 

There's no error and nothing weird in the log. The (O-DL) log makes no mention of the new folders. There are no access errors in the DNN event viewer.

Why would permissions matter? It correctly grabbed stuff the first time. Plus, I gave the Everyone group full control prior to installing the module. The problem comes in when you add new content directly via the filesystem.

This definitely seems like a bug, as its happened to me on 2 machines. Unless there is something I'm overlooking...

 
New Post
6/13/2007 2:02 PM
 

It is a strange behaviour that we could not reproduce,

in the process of testing however, we did find out a pattern: if you synchronize large folders, and click on any button that will cause the page to post-back, the synchronization would stop.

Maybe that's what happened in your case.  As a result,  in this couple of days, we have revamped the whole synchronization process, and made it Asynchronous.  Now you can click on Synchronize, and go back to the O-DL main UI, and you will be >http://www.opendnn.net/Downloads/tabid/95/Default.aspx?xsfid=42

Keep the feedback coming.

Best Regards,

Andreas

 

 

 
New Post
6/14/2007 9:53 AM
 

Great news! The latest beta appears to fix the problem I had. However, two problems have popped up.

The first may be by design. How are you supposed to link to files in the document module from another tab? I'm trying to let registered users download files directly from the document module. I tried copying the url used to download, but that doesn't work. I copied a link from your opendnn.net site in the same way, and it did work (in another browser). What did you guys do differently?

Second is a UI issue. The green checkmark next to the root folder text box doesn't make much sense. Green checkmark has never meant both "allow edit" and "disallow edit". If anything, it should be a lock icon when it's not changeable, and an open lock when it is. Use lock.png and lock_open.png from the silk icons pack you're using.

Thanks for updating the beta.

Edit:

I just thought of what the problem might be for the first issue. Are the documents on your site stored in the portal directory or on a UNC share (these: here ). Mine are in a UNC folder. Perhaps there is no way to directly download from a UNC folder? What about if I had it set as secure download? Maybe that will change it. I will try it now.

Edit 2:

Bad news. Checking the secure download option caused the synchronization to go into a seemingly endless loop. Most of my files ended up with .a__.resx.a__.resx.a__.resx. I can't remember the one extension, that's why there are underscores. Unchecking the secure file option reverted my directory back to normal, but it still thought it was sychronizing. After viewing the log a couple times, the module crashed aspnet_wp.exe.

Big problem, to say the least.

I can't reboot right now to reproduce the problem as I have tons of other work up and open. Later in the day I might try to reproduce.

Hope this feedback helps.

 
New Post
6/14/2007 10:34 AM
 

Hi dnn, Let's see if I can clarify some of the issues:

 

Issue 1 and edit 1:
In order to access the files outside of the interface, you need to be able to access them through a web browser.  If the files are not in a virtual directory, then you will not be able to do it.  That is standard security: a web server does not allow direct access to unc shares.
The setup we have on our site, is through Portal, so all files are stored in: Portals/0/Root folder... so, if you wanted to access a file directly, you
could type: www.mydomain.com/portals/0/root folder/doc_name.doc

Note: this will only work if you have not secured your files.  As we will see in Edit 2.

Edit 2:

The process does not go in an endless loop, but id does take some time depending on the size of the directory you synchronize... you can open the Synchronization Log and view it as it unfolds.  If you synchronize a folder that has many files it will take a few minutes.  Since it is an asynchronous process, the message you reported will show up until the process is over and writes a "done" variable to the db. The next time you reload the page in which the library UI is, the done variable is read, and if it is true, then the message disappears.

Checking the "secure download option" will trigger a synchronization, on top of renaming every file in your selected folder (so it should not be done lightly).  Here is what the help says:

"If checked, this option will protect your documents from direct download by renaming them to a type of extension that is not directly served by a Web Server [.resx]. As a result, the only possible way to access the document will be through the document library interface.
When unchecked, this option will allow documents to be downloaded directly from a web browser or to be referenced by links. "

The crash could be due to a lack of memory on your system.  If you tried to synchronize "c:/", then you might have drained your AppPool memory resources that are set to 256 mb by default (I believe).  Allow the app pool to utilize more memory.  During testing we have synchronized the entire DNN root folder with no issues.  That takes about 3 minutes.

Regards,

Andreas

 

 
Previous
 
Next
HomeHomeOur CommunityOur CommunityCommunity Membe...Community Membe...Download the new Open-DocumentLibrary v2.0 BetaDownload the new Open-DocumentLibrary v2.0 Beta


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out