Trevor Daniels wrote Saturday, May 16, 2015 10:44 AM > > I've pretty well completed my assessment of Allura at SourceForge, and find > the facilities available pretty well match our needs, in fact they are > surprisingly similar to those at GoogleCode. There are some differences but > none which we can't live with. So far so good. > > However, there is a show-stopper concerning the integrity of the Issues > discussions recorded in the tracker. Each item in the discussion has an > owner, and this is set to Anonymous during the import, since the original > owner is not recognised as a SourceForge account-holder. This in itself is > not a serious problem, as the correct owner is recorded in the text of the > message. However, owners of discussion messages are always permitted to edit > them, irrespective of the permission settings, and I can find no way of > preventing this. That means Anonymous, which is any not-logged-in user, i.e. > anyone, will be able to edit, accidently or maliciously, any and all > discussion entries in our Issues DB. > > I've reported this to the SourceForge maintainers: > https://sourceforge.net/p/forge/site-support/10317/
Further to this, I had a very helpful interchange today with one of the other users at SourceForge who responded to my ticket. He suggested exporting the text part of the DB as a JSON file, changing all the occurrences of "author": "*anonymous" to "author": "tdanielsmusic", and re-importing the file. I tried this. It works and fixes the exposure problem. I've now created a new account "googleimporter" and am in the process of changing the author to that in all the imported tickets so my account remains separate. However, this has exposed another difficulty. Importing DBs is a bottleneck. I managed to import part of the first file I modified, enough to check it fixes the problem, but importing the main DB with 4000-odd issues has so far failed due to congestion. The file uploads but is then rejected with "Too many pending imports. Please try later." This suggests we should aim to start the migration proper early rather than later. Trevor _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
