Ticket search results

Admin page to really delete projects

Dave Brondsema — Mon, 30 Nov 2015 15:35:11 -0000

Admins should be able to really delete projects, not just soft-delete. (Here's all the things we can do, possibly break out into separate tickets) * create admin page with a textarea in which project names or urls can be entered, whitespace separated. * `ProjectRegistrationProvider` should have a method to parse the (nbhd,project) out of each URL, so that custom sites urls can be parsed specially if needed. * to actually do the removal, SF can contribute our `forge-classic/scripts/purge-project` logic. Just need to do a little refactoring: * remove `find_project_by_unix_name` usage, it should work with a (nbhd,project) or such * probably good to make it a `ScriptTask` so it can be run that way too * forge-classic script should call the new script * fire an event so other custom hooks can do things upon project deletion if needed * /nf/admin/new_projects already builds a list of project names at the bottom of the page as you click the checkboxes. Enhance that list of names to link over to to the project deletion form. * include a text box for "reason". Log it to disk, and include in the event parameters. * have a checkbox for "Disable all project members". It should disable all users that are admins or devs of the project. And add a user audit log comment, noting the related project and the "reason" given. * document it in administration.rst

Live syntax highlighting for markdown editing

Dave Brondsema — Wed, 29 Jul 2015 21:10:17 -0000

An editor like https://github.com/lepture/editor which shows some Markdown style rendering as you are editing (not full WYSIWYG though) could be very helpful. Demo at http://lab.lepture.com/editor/ We should figure out how to change the help & preview buttons to use our help & preview URLs. However I don't think we should try to customize the syntax highlighting for our customizations (e.g. `~~~~`, artifact links, etc) yet. Can be a followup ticket. I like this because it doesn't attempt to do a full WYSIWYG exact render, so we don't have to worry about some of our customizations. Yet it does do enough formatting that people will notice if they unintentionally cause formatting with a `_` or a `*`. And it even helps with the sneaky gotcha of a bullet list without a preceding blank line (it doesn't work, it is rendered as italics) (This idea came from discussion on [#6822])

Phone verification system

Dave Brondsema — Thu, 20 Aug 2015 22:06:09 -0000

To control spam and other abuse, a phone verification system could be useful. This would be optional for any Allura instance to use, of course. Initially I'd like to see this on project registration. The `ProjectRegistrationProvider` can provide methods to allow flexibility in different deployments. A default implementation could be as follows. The first time a user registers a project, they will be shown a followup screen requesting a phone number for either SMS or voice verification. (If a user has any existing non-deleted projects, this will be skipped and registration occurs as normal). Verification occurs (see next paragraph). If verification succeeds, record that on the user record so they won't have to verify again, and add a user audit log too. Use a non-salted hash of the phone number, do not ever store the full number. Then project registration actually occurs. If verification fails, record an audit log also. Let the user try again. For actual phone verification, we should set up a simple abstraction layer to allow different verification services to be used. See the "spam.method" config and `SpamFilter` classes as an example of that type of setup. Specific implementations could include Twilio, Nexmo Verify, etc. These classes could be used for different situations later too (e.g. two-factor login) Site-specific messages will need to be included in this too. E.g. saying the phone number will be used for verification only and will not be stored; or if they are having problems how to contact support, etc. Simple text could be handled with a config setting, more complex with a template override. Don't need to apply this to project imports.

Use repo directly instead of DiffInfoDoc

Dave Brondsema — Thu, 20 Aug 2015 22:06:09 -0000

See [#7828] for analysis of where DiffInfoDoc is used. Goal is to remove it altogether, using SCM data directly. Then also remove the building of DiffInfoDoc records during repo refresh. (If there are really slow computations we could keep using DiffInfoDoc for a cache of those results)

New profile page design - NEEDS INI

Dave Brondsema — Thu, 20 Aug 2015 22:07:00 -0000

Implement webhooks

Dave Brondsema — Thu, 20 Aug 2015 22:06:09 -0000

We should have webhooks, compatible with github & bitbucket. I don't see a spec for SCM webhooks anywhere.

Update controllers & templates to use new SCM data

Dave Brondsema — Thu, 20 Aug 2015 22:07:57 -0000

[#2020] set up the new data structures, we should start using them. A total repo refresh is in progress to backfill the data needed.

Ming functional-level refactoring

Dave Brondsema — Thu, 20 Aug 2015 22:07:54 -0000

* ming:rc/functional-level * forge:rc/new-ming

Examine porting Allura to Pyramid

Rick Copeland — Thu, 20 Aug 2015 22:07:55 -0000

Timeboxed

Write forum import API

Mark Ramm — Thu, 20 Aug 2015 22:07:52 -0000

Based off of ticket import API system, probably. Look for existing forum data formats, i.e. any public standards. Consider supplementing the regular forum API with a few import-specific fields

Refactor reactors/auditors into tasks/events - NEEDS SCRIPT, REINDEX, FORCE NEW VIRTUALENV

Rick Copeland — Thu, 20 Aug 2015 22:07:52 -0000

Replace our auditors with background tasks Also update our reactors to call them 'events' and allow notifications Steps for SOG: * Remove all reactor-setup commands * Replace reactor command with taskd command (allurapaste taskd /var/local/config/production.ini -p2) * add a cron job to run every 5 minutes or so (allurapaste task /var/local/config/production.ini commit) (in production) * run a paster reindex

Make interactive commit browser for scm

Jenny Steele — Thu, 20 Aug 2015 22:07:55 -0000

Show a list of commits at the top with a view of the highlighted commit below with a diff

Interviews (monday)

Mark Ramm — Thu, 20 Aug 2015 22:07:55 -0000

Friday Interviews

Mark Ramm — Thu, 20 Aug 2015 22:07:57 -0000

Conduct a series of interviews for each of our candidates.

Revamp tracker import for TG project migration

Paul Sokolovsky — Thu, 20 Aug 2015 22:07:57 -0000

From Mark's mail: I know this is interrupt driven work, but if you could take a look at this issue and let me know what you find, when trying to import this JSON dump to allura, that would be great. I'd really like to have a major open source project come onto newforge, and I think TG is a good first candidate, as it's a reasonably active open source project where we have good ties already, so it should give us good feedback about the platoform. Also, just so everybody knows if anybody else expresses interest in migrating, I think it's worth our while right now to provide them with some help. --Mark Ramm ---------- Forwarded message ---------- From: Mark Ramm Date: Tue, Mar 1, 2011 at 6:21 PM Subject: Fwd: [tg-trunk] Trac Migration Status Update ---------- Forwarded message ---------- From: Christoph Zwerschke Date: Sat, Feb 26, 2011 at 9:10 PM Subject: [tg-trunk] Trac Migration Status Update To: TurboGears Trunk After the SF hosted trac option turned out to be unusable for our purposes (it's only trac 11.2, no plugins installable, no API or database access etc.), I tried the second (and preferred) option for hosting the TG tracker on SF today, the Allura tracker. The following scripts already exist to export from Trac as JSON and then import JSON to Allura: http://sourceforge.net/p/allura/git/ci/e1c0a20357afc3af25f470cc3488ad3d5127c352/tree/migrate-3rdparty/ It turned out that the trac export script does not work with trac 0.10 which we are running on our old server, so as a first step I have migrated it to trac 0.12 on my own server. There were several more small problems with the export script which I could fix easily. The script also stumbled over a oversized ticket containing only Chinese spam (#852) which I have deleted already. So I have now a ~10MB JSON file with our trac database. Btw, there are ~1905 tickets for TG1 and ~540 tickets for TG2. When I tried to import that to Allura, I got an "Request Entity Too Large" error - obviously because the import script tries to import everything with one API call only. So I modified the import script to read the data in chunks (slicing the artifacts list), but now I only get internal server errors with no further clue what's wrong. The error message says more info may be available in the server error log, but only SF staff has access to that log. Another problem that needs to be solved if we go this way, is the user mapping from our old Trac accounts to SF accounts. The import script has a usermap option, and maybe we will be able to map some users through their email addresses, but this is also something that can be only done by SF staff. @Mark: Any chance you will be able to solve these problems in the short run? If not, I suggest we migrate to Florent's server for the time being. However, since Trac cannot work with remote repositories, this also means we will have to move the repositories there. We can consider moving to SF at a later time again. -- Christoph

SCM layer: computing diffs for a repo is very slow

Paul Sokolovsky — Thu, 20 Aug 2015 22:07:55 -0000

Refreshing from scratch a repo with some 2000 commits takes around half an hour, both for git and hg. Most time is spent in "computing diffs" stage.

Fix discussion/email integration

Dave Brondsema — Thu, 20 Aug 2015 22:07:57 -0000

In addition to work done in [#1395] something else needs to be fixed. Emailing develop@discussion.allura.p.re.sf.net does not create a new thread or a message in moderation.

Make attachment subclasses be polymorphic_on - NEEDS SCRIPT

Paul Sokolovsky — Thu, 20 Aug 2015 22:07:54 -0000

Work on [#1280] showed that there is no good way to enumerate attachments within app/project, because we have wild varying object structure in the same collection, without type info on Ming level. Besides maintenance tasks like that ticket, it may be useful to provide admin tasks in the web app, like "list/moderate all attachments within project/tool". Let's consider tracker app example. For it, attachments can be of types TicketAttachment (direct attachment to ticket) and DiscussionAttachment (attachment to ticket comment). TicketAttachment has: artifact_id=FieldProperty(S.ObjectId) While DiscussionAttachment: artifact_id=FieldProperty(str) When doing M.TicketAttachment.query.find(), you'll get validation exception on first hit of DiscussionAttachment in the underlying collection, and vice-versa. So, you have to figure out additional duck-type style discriminators to add to find(), essentilly doing adhoc manual polymorphic_on. Rather, Ming should do that underneath.

Fix validation errors across all apps

Paul Sokolovsky — Thu, 20 Aug 2015 22:07:57 -0000

Now that #1233 is done and html5 theme fixes are backported, fix remaining validation errors across all apps, to be prepared to enable validation failures for tests.

make tracker admin options modal on the tools page

Wolf — Wed, 23 Mar 2011 14:41:38 -0000

Achieve 90% test coverage on Allura project

Rick Copeland — Thu, 20 Aug 2015 22:07:55 -0000

Fix up theme with tweeks from Wes

Mark Ramm — Wed, 23 Mar 2011 14:41:38 -0000

Update python FUSE for OSS release

Rick Copeland — Thu, 20 Aug 2015 22:07:57 -0000

For the OSS release, we'd like to not rely on the current SCM deployment environment that sf.net uses, including * patched versions of the SCM tools * patched version of ssh * sfx tools to manage ssh keys * SOG FUSE to manage access control Instead, we'd like to have a FUSE filesystem that runs without need for patched ssh/scm tools. We already have the start of one. To complete it, we need * Support for a virtual ~/.ssh directory in user accounts (to allow use of unpatched ssh) * Admin screen allowing for ssh key upload

Enhance test data so it meshes well with the SDS

Rick Copeland — Thu, 20 Aug 2015 22:07:56 -0000

We should have users and projects that mesh well with the sf.net SDS * Usernames should match those in the SDS * Projects should be created via the sfx api

Trac import spike

Mark Ramm — Thu, 20 Aug 2015 22:07:55 -0000

We need some sort of trac import system that we can use to import the support tickets into the forge project. Other external projects that use trac like Django, Pylons, Turbogears, ought to be able to use the same system, which runs against a customer facing api. * Ticket import API * Wiki import API (with history)? Ultimately we will want to be able to use the same API to import tickets, etc from sf.net, GitHub, BitBucket, GoogleCode, etc. There was an effort to be able to get exported data into a standardized format called ForgePlucker, and we should see if any of that can be used.