"Share" and "Move To" options greyed out
robkgriffiths opened this issue · 23 comments
I hope someone can help me with this. I was recently asked to set the Recogito server for a member of staff in one of our departments. All appears to be well but we have noticed that the "Move To" and "Share" options appear to be greyed out when trying to manage any of the files in the user interface. I may have missed a step in the configuration of the server and was hoping that someone may be able to point me in the right directions to correct this.
Any ideas anyone?
Hi @robkgriffiths,
- Move to sould be available as soon as you select at least one item
- Share should be available if you select one folder (it's not - yet - available for multi-select, if I remember correctly).
In both cases, you need to be in My Documents, or a subfolder of My Documents.
If you can confirm that this is the case for you, and it still doesn't work, then I'm suspecting you may be running on a slightly older version of Recogito. Both features are fairly recent addtions, and there was a phase in the codebase where the menu options were already shown, but the implementation was missing. Do you have the chance to update to the latest version of the master branch?
Hi rsimon,
Thanks for the update. I attempted to upgrade to v3.3 last month and was still seeing the issue. I am suspecting I may have not carried out the upgrade correctly and it may be running v3.2 still. Is there a guide on the steps to take to carry out the upgrade properly anywhere that I could follow?
Rob
It should really just be a matter of doing a git pull
to the latest state of the master from this repo. Version 3.3 might, in fact, be too old for this feature. (I'd need to double check.)
If it's not the upgrade: can check in the browser console (F12) whether there's any weird stuff going on? Errors in the JavaScript console or, in the Network tab, requests going out to Recogito which return error responses (HTTP 500 etc.)?
After carrying out the git pull again it says it is already up to date. I have brought up the console in the browser but nothing out of the ordinary is showing. I can't see any errors as such.
Version 3.3 seems to be the latest version on the master repo as far as I can see.
3.3 was the latest release. But the master branch has moved on (there will be a 3.4 in Dec.) Can you check whether you‘re on master, not 3.3? (git checkout master)
Just tried that and it says my branch is up to date with origin/master.
Hm, weird. Can explain the exact steps you’re making in the UI? Can you try hitting CTRL+F5 (or Shift+F5) to make sure your browser isn’t caching the old UI code? Also: which browser are you using?
The steps I am taking are that afer logging on I click on one of the files which then highlights and I then select Options to bring up the menu. From here I can see "Open", "Open in new Tab", "Duplicate" and "Delete". The "Move To", "Share" and "Name Entity Recognition" are greyed out.
I have cleared any cached pages with CTRL+F5 and have tested in Chrome (my main browser), Edge and Firefox. All produce the same result.
Is there any reference in the folder structure to check if the version is the current one? Maybe GIT has a problem on my server with the files and it thinks they are the latest and maybe they are not.
Sounds all good. Really a mystery, sorry for the pain. Some more thoughts in terms of tracking this down:
-
git log
will give you the most recent commits, with date included. This should allow you to check whether you are indeed in sync with the actual master branch. -
Share currently works for a single folder selection only. If you have multipe items selected, or your selected item is a document, then the option will be disabled. (To share a document, you still need to open the doc, go to Document Settings and share individiually, like in the old days of Recogito. Making it work from the workspace is on our list... just a matter of finding time to write the necessary code.)
-
Share also currently doesn't work when you are in the Shared With Me space, only in My Documents.
-
Selecting any number of documents and/or folders should definitely activate the Move to option however.
Is your installation intranet only? Or can it be reached from outside? If its on the Internet, I could register an account and see if I can find out anything else, if that's ok.
The git log look fine and I seem to be up to date.
I can confirm that the share function is in fact working and it is just the "Move To" option that is not.
My installation is intranet only I am afraid and I would not be able to give you remote access to the server as it would be against the security policy for where I work.
I have however located the application.log file in /recogito2/target/universal/stage/logs. I have taken a snippet from the last few weeks and there is a number of errors and warning in there that you may be able to make sense of if you would not mind looking? Possibly these are related to the issue.
There are some really unusual error messages in that log... it looks like someone has submitted some really weird stuff to the Named Entity Recognition. Something with special characters, file paths etc. (Maybe some kind of system config file.)
Also someone seems to have attempted to access an /index.jsp page (with some extra special character attached to the end of the URL). That produced internal exception (as it should).
Weird - but, off the top of my head, nothing I think would be able to have an impact on the Move to feature.
The only thing I can think of now is that I'd provide you with some modified code for the workspace UI, which adds client-side logging... Perhaps that might get us closer. I'll look into it & get back to you.
Another thing: are you able to create new folders in My Documents?
No problem creating folders in "My Document".
I am noticing some inconsistenties with the file management. When dragging and dropping files it does not always work.
I have checked the package versions I have installed to run Recogito. Could any of these be contributing to the problems? Do any of these need upgrading at all?
openjdk version "1.8.0_22"
sbt 1.2.8
Elasticsearch 5.6.16
nodejs 10.15.3
npm 6.9.0
postgresql 11.3.1
All the versions look good. (Personally, I'm still running a 9.x version of Postgres, but that can have no effect on the UI).
I'm still completely puzzled by this. I checked the code now for the workspace UI. Since the Move To feature works for any type of selection, it is always enabled (in the current code state). There is no logic at all that would disable it as a menu option anywhere.
That means you must somehow be stuck on an old build of the workspace frontend. Although I can't explain how. I'll attach a ZIP with the latest built JS for the workspace frontend. If you manually copy that into your installation... well at least we'll see whether that does anything. Give me a moment...
Ok, here are two files:
-
static.zip. This needs to go into the public/javascripts/ui folder, replacing the /static folder there.
-
my.zip. The two files in there need to go into the app/views/my folder, replacing the files of the same name there.
Last but not least: you always need to restart Recogito after updating, of course.
Hi,
Sorry it has been a while but I have been busy on other projects. Thanks for the advice but I followed your instructions above but I am still seeing the issue. Would reinstalling from scratch be the only option now?
Hi,
re-installing from scratch is certainly the last resort. But before we go that far, perhaps one more idea: how are you starting Recogito on the server? Assuming you use the standard sbt production mode command:
$ sbt runProd
or (if you are running on a different port than default 9000)
$ sbt "runProd -Dhttp.port={portnumber}"
Can you stop, clean and re-build?
$ sbt stopProd
$ sbt clean
$ sbt runProd
Changes to the source directory won't reflect on the production system, which creates it's own copy during build/start. The only remaining thing I can imagine is that, somehow, the changes in your code directory don't get properly reflected in the build directory after start. An sbt clean
should wipe the slate clean.
I have actually been running it as a service which looks like the reason why this has not been working. I have followed the instructions above and the Move option is now appearing but I am now getting errors in the logs and I cannot see the files I originally had in my account on Recogito even though they are on the network share that I have linked to the system.
I have attached the error log if you would not mind looking? It seems to fail after checking the existing folders exist.
Great :-) That confirms you are now indeed running on the latest version. And that your current version was quite a bit out of date. You need to apply a few migrations to the database schema. (I kept these manual, for fear of breaking something in production...)
Can you run the following statement on your Postgres DB and then restart?
ALTER TABLE document ADD COLUMN cloned_from TEXT ;
Thank you for all your help. It looks like we are back in business and all is working.
To prevent having this issue again what is the best method of starting this as a service in Ubuntu and maintaining that the latest version is running after doing a git pull?
I was origianlly running a service file which was calling the following file.
/recogito/recogito2/target/universal/stage/bin/recogito2
Is there a better way of doing this?
Good to hear things are working now!
I think the way you are doing it should be perfectly fine. Are you first building a binary distribution using the sbt dist
task? If so, you'd need to rebuild the distribution after a git pull
. But after that, the dist should be in sync with the source code directory.
Many thanks for all your hlep on this. I assumed that the service would check and update on launch which is why this has happened. At least now I know what to do for future reference.