One of my models has a 'status' field which is only ever modified in code. It is an integer from 1 to 6 (although this may change in the future).
However, in the Admin site, I would like to display a label for this data. So, instead of displaying '5', I would like it to say 'Error'. This means I would be able to easily filter the objects in the database that have the status 'Error' and also my colleagues who don't know what each status means as they are not involved in coding, can use the admin site to its full.
I don't know if I am going the right way about this or if it is even possible, but I would appreciate any help you can give. I would rather not change how the status is stored as it would require a big re-write of some parts of our system. In hindsight I guess it was a bad way to do it, but I didn't think the field would matter as much as it does.
Consider to use choices. Anyway you can customize lots of things in django-admin, just read the docs:
http://docs.djangoproject.com/en/1.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_display
http://docs.djangoproject.com/en/1.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.form
You could create a custom field type that overrides to_python and get_prep_value to store integers in the db but use string values within Python:
http://docs.djangoproject.com/en/dev/howto/custom-model-fields/#django.db.models.django.db.models.Field
Related
I searched on google and found this: "SlugField is a field for storing URL slugs in a relational database. SlugField is a column defined by the Django ORM. SlugField is actually defined within the django.db."
But still, the definition sounds a little complicated to me. I don't even know what a slug is in this context and not sure about Django ORM.
I just need a reason why I should use SlugField in Django in simple terms.
You don't strictly need to use a SlugField.
"Slug" is a term borrowed from journalism that refers to a short version of a title. As mentioned in a comment to your answer, it's a way to make URLs more explicit while still keeping them somewhat short, instead of using, for example, the full title (which would often be too long), or an ID (which wouldn't be explicit or memorable at all: think of a user who wants to find an article they remember reading: if they start typing some keyword in their address bar, a URL that contains it will pop up, one with an ID will not).
If you wanted you could craft your own slug, by making it URL-friendly (remove any symbol that a URL wouldn't hold, converting anything that would need to be url-encoded, turning spaces into hyphens...) and removing anything unnecessary (e.g. removing words like the, a, an, is, are... or cropping lenghty titles to a maximum number of words or characters).
SlugField is simply a convenience you can use to automate that to some extent. It also comes with some extra features that you might need: for example it automatically generates a slug from a field of your choice, and it can add a unique number to the slug so that you don't accidentally end up with two identical URLs for two different articles that have the same title.
The reason it is a field is that, although you could, it's not smart to calculate a slug every time you access an object: the slug will only change when the title changes, meaning possibly never, so it makes sense to generate it only once and then store it in the database to use it next time, without having to produce it again. This has the added advantage of making a URL to a certain article permanent: you could make it so the slug won't change even if you change the title of the article, which would be a good thing.
Once you have it, since a slug refers unambiguously to a specific object, it acts as a sort of human-readable unique ID, and so it can be used to retrieve the object from the database as efficiently as an opaque numeric ID. It also obscures how many objects you have (if for some reason you want to do that), since a sequential ID of, say, 1543, tells anyone that you probably have 1542 other objects that came before that one.
I am making a CRM, and I ran into one task: I want to make a “Client” model, with all possible fields, and give an opportunity for users to “enable” only those “Client” fields that he needs.
I have little experience and unfortunately I have not been able to find a solution for this for a long time.
I would be grateful if someone can show me an example of how this is done (or a link to a repository with a similar method).
The answer is JSONField, new DBMSs support JSON Fields natively and Django has a native support from 3.0, so you can add the extra fields as attributes in a JSON and save to the a column called extra for example you want to add a field called 'mobile2' so rather than creating the column, so you can add it to the extra column like this
obj.extra["mobile2"] = "0xxxxx"
this allows you to extend quickly and give different attributes per user.
In the clean method of my form class I am working with many different inputs from the billing, contact, and account sections of the form. As such there are many self.add_error statements and many fields that depend on other fields in order to validate.
I have noticed that after adding an error for a field I am unable to access that field any more. This is strange as you can add more than one error to a field, but that is not the issue.
I am seeing this method grow more complicated and unreadable, is there a good way to do this so the person that comes after me will understand it? I don't feel that the code ordering to prevent access after error is appropriate. My only thought is to set error variables in clean and call a different method at the end to add the errors to the fields.
Thanks
Edit: To add, I am only returning after clean has run in order to give the user all errors at once. I did not feel that returning after each found error was a good user experience
It's good practice to provide your code to help people see what you are doing. This includes your error reports/traceback info. Use the markdown options to help make your post more readable.
I could be wrong but from my own experience, I usually clean each field individually as per the documentation unless they rely on each other such as passwords, etc.
you can read this part of the documentation to help get some clarity:
https://docs.djangoproject.com/en/1.10/ref/forms/validation/#cleaning-a-specific-field-attribute
I'm new to Django. Last night I worked hard on a view that would allow me to edit any of the entities in my current project; Chapters, Stories, and Worlds. In order to ensure that I know precisely which database object is being modified, I added a database entry to the tables 'edits' that stores the hash, the type of object being edited (eg. 'Chapter'), and the id of that object as found in the database. The hash is added to the form as a hidden input.
On the back-end, after the form has been submitted, I grab the hash and use it to find the related Edit item in the database. I then use this to find which object was initially being edited. This was done for two reasons:
I can know what object is truly being edited. If all form items have changed, there would be nothing to compare to (except URLs) to actually know which object is being edited.
Users should be unable to hack the front-end to do weird things like modify the wrong stories.
Today I discovered that Django has a generic view called update_object. This seems to handle a lot of things for me. But given that it doesn't automatically use the database to ensure that the correct object is being edited, or even determine which object is being edited, is this secure? surely there must be a simple way to hack it on the front end by modifying HTML elements.
Secondly, if this should be a concern, would you recommend that I keep my own edit view, or that I extend the update_object view, or some other solution?
Lastly, am I going about this the right way at all? Please correct me if I'm not thinking about solutions to this problem in the right way.
I don't feel that this is a question that requires code. It's more of a general question about the security of forms as they pertain to Django.
Thanks,
ParagonRG
Your problem of knowing which object they're editing is typically solved either by inspecting the URL or by a hidden form element that just has the database ID.
Before accepting any changes from a user form, you should be verifying that the user has permission to do whatever it is they're asking to be doing, and that the edits make sense. You'd normally do this with form validators and/or explicit checks in the view. This is a somewhat safer way of dealing with this problem, because it guarantees people aren't making DB changes they're not allowed to be making, whereas in your Edit object approach it's conceivable they could get around that.
If you take this approach, I don't see any reason why it's a problem that the user could be editing hidden ID fields to pretend to be editing a different object. They're just using a silly roundabout way to edit things when they could have just gone to a different edit link.
(Also: if you're using Django 1.3+, it's better to use the new class-based UpdateView rather than the function-based update_object.)
I'm trying to write my own Trac plugin to notify an external system of changes to tickets matching a certain criteria. From my research so far, I've figured out that implementing the ITicketChangeListener interface is the way to go.
The method definitions are all very straight forward, but what's not straight forward for me is the Ticket object and accessing its custom fields. I've learned that you can access default ticket fields as simply as:
# t is a Ticket object
theStatus = t['status']
I've found several sources that say this won't work:
myCustomField = t['my_custom_field']
Yet none of them tell me what will work.
In addition, I need to know if the old_values argument of the ticket_changed() method will have my custom fields or if I'll have to do something different there as well.
I'm fairly new to Python and very new to Trac. Any help to point me in the right direction is appreciated.
The sources are wrong about custom ticket fields. The value-by-name approach should work. And *old_values* contains all fields values, including custom fields too. That's it.
You may want to look at the TracAnnouncer source for some change-listener coding examples.