Closed danielwagn3r closed 10 years ago
maxrossello
commented
10 years ago Hi, looks like you have a Version in database with null name (???). This should be forbidden by database integrity rules.
Can you please tell what database are you using and your system (Windows, Mac, Linux...)? What version of the plugin?
maxrossello
commented
10 years ago Hmmm... no sorry, my mistake
Do you just have an order and no shared versions from projects? Would you try to create a Version in some project and share it globally to see if this helps?
danielwagn3r
commented
10 years ago we've checked that there is now version with NULL as name but we do have
versions which are shared with all projects.
maxrossello
commented
10 years ago does changing the NULL in database solve the problem? What Version is it? Is it the newly created order?
danielwagn3r
commented
10 years ago Sorry for the misunderstanding, but I meant no versions with NULL as name.
maxrossello
commented
10 years ago I suspect it could be a bug in your ruby, which I see is 1.9.1 (rather old). Can you please try to cd to your redmine installation, run 'rails console' and try to give the following command:
[].uniq.sort_by{ |v| v.name.downcase}in the meanwhile, I am installing it myself to try as well
maxrossello
commented
10 years ago Ok, I got a closer hint. Can you please look into your db for column order_id into table ts_permissions and verify if there is any order_id that does not match with any id in table versions?
danielwagn3r
commented
10 years ago I found only one record in ts_permissions where ts_permissions.order_id and any versions.id match, but there are about 10 records in ts_permissions with order_id that do not match any version.id.
Regarding the Ruby version. I use the current Bitnami Redmine Stack, where everything is bundled and preconfigured.
maxrossello
commented
10 years ago Right. Ruby is actually not the problem, rather the mismatch creates nil's in the query that therefore returns error.
Did you remove Versions directly from database? If not, what type of database are you using?
As a protection you may want to edit line 252 and change
{ |v| v.name.downcase}to
{ |v| v.name.downcase unless v.nil?}but I'd like to understand the root cause for this problem.
danielwagn3r
commented
10 years ago Just for simplicity here the complete version information:
Environment:
Redmine version 2.5.1.stable
Ruby version 1.9.3-p231 (2012-05-25) [i386-mingw32]
Rails version 3.2.17
Environment production
Database adapter Mysql2
SCM:
Subversion 1.8.5
Git 1.9.0
Filesystem
Redmine plugins:
redmine_app__space 1.0.3
redmine_app_timesheets 1.3.19
redmine_watcher_groups 1.0.1
redmine_wiki_lists 0.0.3Ok, thanks. Now I wish to understand if database mismatch among ts_permissions and versions was due to manual handling or caused by the application. If it was manual, then just remove the mismatched entries in ts_permissions as well, otherwise I need to find the root cause in the application.
danielwagn3r
commented
10 years ago Oh, that's hard to answer, because I'm not the only one working with our Redmine environment. I'm sure we deleted an order but potentially deletion of versions (e.g. via Roadmap) has happened, too.
Btw, the { |v| v.name.downcase unless v.nil?} didn't change anything.
maxrossello
commented
10 years ago You probably still have an error 500, but in another place, having those nil's in the way.
Ok, I replicated the problem.
The problem is that removing some version in the backing project (where versions become orders) leaves stale entries in ts_permissions. This is a bug.
I need to hook up version removal and clean ts_permissions.
In the meanwhile, you can restore your site removing unmatched ts_permissions entries manually.
Thank you
danielwagn3r
commented
10 years ago I didn't delete the version in roadmap in the backing project, but in a normal project.
Is there a way to make a cleanup of all redmine_app_timeseries data, just to begin from a sane point with further testing?
maxrossello
commented
10 years ago There is some irreversible migration, but since you want to wipe out everything and restore a clean environment, you can migrate db back and forth this way:
Please dump your database before you do
danielwagn3r
commented
10 years ago Hi, today I discussed with a colleague what he exactly did during his tests and it turned out that he deleted versions from the backing project as he found no other way to delete an order.
I took a quick look at the database scheme and should it be sufficient to repair the database with these deletes?
delete from ts_activities
where order_id not in (select id from versions);
delete from ts_permissions
where order_id not in (select id from versions);
delete from time_entries
where order_id not in (select id from versions);Hi, For what concerns time_entries it is necessary to keep the entries where order_id is null, which are standard redmine time entries not related to order's time sheets
Daniel Wagner notifications@github.com ha scritto:
Hi, today I discussed with a colleague what he exactly did during his tests and it turned out that he deleted versions from the backing project as he found no other way to delete an order.
I took a quick look at the database scheme and should it be sufficient to repair the database with these deletes?
delete from ts_activities where order_id not in (select id from versions); delete from ts_permissions where order_id not in (select id from versions); delete from time_entries where order_id not in (select id from versions);
— Reply to this email directly or view it on GitHub.
danielwagn3r
commented
10 years ago Hi, after
delete from ts_activities
where order_id not in (select id from versions);
delete from ts_permissions
where order_id not in (select id from versions);the timesheet view opens again. How can we delete an order in a safe way, through the gui? Disable it first and then delete the according version?
maxrossello
commented
10 years ago I have marked this as a bug to be resolved. I need to hook and perform your same actions at order delete in the backing project.
In the meanwhile, you still have to do these manual cleaning actions: order delete was actually not foreseen (it makes sense to delete an order only if it was created wrong, otherwise you can just disable it) and is not supported yet.
Daniel Wagner notifications@github.com ha scritto:
Hi, after
delete from ts_activities where order_id not in (select id from versions); delete from ts_permissions where order_id not in (select id from versions);
the timesheet view opens again. How can we delete an order in a safe way, through the gui? Disable it first and then delete the according version?
— Reply to this email directly or view it on GitHub.
maxrossello
commented
10 years ago When Versions are deleted, related time entries (those with matching order_id, not those with NULL order_id which are related to project or issue) are destroyed automatically
After creating an order the timesheet cannot be opened anymore. We get an Redmine 500 error.
In the production.log I found the following: