cfpb / django-nudge Goto Github PK

both as a management command and in the admin interface

Including batch items, batch log entries and push date.

Currently using the same initialization vector each time. This should be randomly generated and different each time, but okay to send in the clear.

See http://eli.thegreenplace.net/2010/06/25/aes-encryption-of-files-in-python-with-pycrypto/ for more info

limit server and client methods to just those that support the api and move batch-specific methods into Batch object. @rosskarchner's idea and he's right. My code is sloppy as hell right now.

find a better way. don't rely on id, maybe enforce that only one setting record exists? possibly move settings out of database and into a file?

Loading a batch sets PKs on the imported models. For some reason this doesn't update the auto increment sequence used to automatically set PKs on newly created instances (I think this might be postgres only). I've borrowed some code from Django's 1.4 loaddata command to remedy this:

https://github.com/EightMedia/django-nudge/commit/a58c3e61909086566e4d5da4ebeed464c0bf0067

Can't currently do a pull request as I'm working in branch that has my PEP8 cleanup branch applied.

The tests currently are broken. They import non existing names:

from nudge.client import serialize_batch
from nudge.management.commands import nudgeinit

Seems the tests haven't been updated to test recent refactor efforts.

Per conversation with @rosskarchner and @Burton, Local Address is unused and local key/remote key is confusing. We should clean up the settings page and have it make more sense to the user.

perhaps use version attributes to populate title of item?

encrypt commands sent from client to server

Scenario:

• A model "Jobs" with a many to many relationships to "JobType"
• Add a job related to jobtypes A,B,C
• Nudge it
• Remove the relationship between the job and B, and add a relationship to D
• Nudge the changes
• On staging, the job will be related to A,C, and D
• On production, the job will be related to A, B, C, and D

It would be nice to have a "Test Settings" button on the settings page that encrypts a dummy batch, sends it to the server and is notified of success or failure.

moved from internal issues list

eligible_to_batch and eligible_to_push were used before we had an admin interface. They're no longer needed and were never intended to be part of the release.

Nudge gently moves newly staged content to production. What about moving user-generated content from production to staging? Is "Coax" a possibility for v2?

possibly grab their old titles from the version object?

Exceptions will exist everywhere. Let's think through these, where to throw them and how they will be represented by a server response.

While listing changed items in "Add Batch" view, show what type of change was made (add, edit, delete)

Batch pushing is a nice idea, but it kind of falls down with highly relational models. Admins should be able to specify groups of tables (or whole apps) and a directionality (push or pull), and allow users to execute those actions on demand.

wide open right now

Unless we find a reason for them to be there.

Capturing a thought: it's possible for items to depend on others (on Crick, for example, questions have related items).

How do we deal with that? We may need the ability to define behaviors on a model-by-model (or relationship-by-relationship) way.

This prevents versions from being considered ineligible for a push.

The batch class has a field called "start_date" but I can't figure out what it's used for.

It defaults to date.today since that's what "default_batch_start_date" returns.

The comment of "default_batch_start_date" suggests that it should default to "date last completed batch pushed or date of earliest revision or today".

I can't find any method that uses this date field.

Expected behavior, but could be problematic for users.

'''
File/nudge/utils.py", line 14, in latest_objects
latest_obj=get_for_object(o)[0]
File "/usr/local/lib/python2.6/dist-packages/reversion/revisions.py", line 503, in get_for_object
return self.get_for_object_reference(obj.class, obj.pk)
AttributeError: 'NoneType' object has no attribute 'pk'
'''

Proposed flow:

• By default, local and remote keys are obscured
• User can check a box, indicating that they accept the risk that comes with keys being displayed. Explanation also includes an alternate, safer (command-line driven) process for viewing and updating keys
• if box is checked and form submitted, user can:
  • edit the remote key
  • see (but not edit) the local key.
  • click a button to generate a new local key

In client.push_test_batch the function serialize_batch is used. However this function is not defined anywhere.

For example, updating a job produces "ValueError: Cannot assign "1": "Job.category" must be a "JobCategory" instance."

There are other countries out there that have no meaning for "public domain" as a software licensing model. Please choose an Open Source license. Github has this nifty license selector now: http://choosealicense.com

Create dummy batch to test if dev and production are communicating.

It currently specifies 0.8 as the version but lists https://github.com/downloads/jroo/django-nudge/django-nudge-0.5.3.tar.gz as the download url.

for new models

As far as I can figure out it seems impossible to update files using nudge. With that I mean that models containing files get synced correctly, but the actual files do not get synced, resulting in missing files on the production environment.

Any plans/ideas on how to fix this?

The manifest file and setup.py includes the folder templates/admin/nudge/settings/ but this folder does not exist.

Also shipping a 500.html in the root seems like a bad practice.

So much for TDD. Never too late for DDT.

If we're syncing whole tables (see issue #60 ), we need to implement some sort of working copy support, so that editors can have pending versions of already-published content.