At the bottom of each issue page there is a History of changes. Some of those are autogenerated by external tools, or by a user that made a mistake, so it would be useful to be able to delete them. Is this possible?
I tried in the standard form and also in the editable form after clicking "Update". I also tried with History updates made with my own user
I am used to do this from the database backend, there's a table which can be edited/emptied. If that helps in your use case.
PA
Yeah, you need to truncate the following tables: journals, journal_details. This way you will not destroy any other content. Just do not delete the tables.
PA
Related
I am trying to add a couple of ad widgets to my website http://yankeedesi.com. Please see the two widgets in the right panel. I created the widgets using the amazon associates interface and it showed up fine. However, when I try to change the style to gallery and transition to zoom and save it, the changes are not reflecting in my site. I am clicking on "Save" and then "Add to my webpage". I tried copying the generated code again (which looks the same as before) but even that did not work.
Even the new products I added are not reflected. Creating it afresh will probably work but I am experimenting with the style, and also intend to add/remove products on an ongoing basis, so every time I change something I don't want to recreate the widget. Any idea what I am doing wrong?
Have you republished your widget after the changes you have made as it is described in here?
UPDATE: (from OP's comment) I checked with their customer support and understand it is a known bug in their system. The workaround is to copy it to a new widget and delete the previous one. That works but is a tedious process if you have to make the changes frequently
I am looking to find out whether or not Items that are either descendants of or are, themselves, hidden items get published when a user Publishes or Republishes the content tree.
I know that this is a pretty basic question, but I haven't been able to find the answer online, and I do not currently have an instance set up with additional roles and users, to use to test this.
Thanks for your help! Happy coding :)
Items which have Hidden field set to true are published as any other items.
Still remember that this is up to you what kind of access rights you'll set for them and who will be able to access them.
By hidden items - do you mean things like the /sitecore/System folder? In any case, as long as it's publishable (i.e. not in workflow, not set as unpublishable in publishing restrictions and the like), it will be published.
Edit
It is important to note that it's parent/ancestors should also be publishable, otherwise it'll still not be published.
All items get published unless marked as Never Publish or have Publish End Date set to earlier than today (In this case the already published items get unpublished/deleted from web database)
I need a django form that submits multiple separate requests, and can't find an example of how to do this without a lot of customization. I.e., suppose there is a form that is used by a car repair shop. The form will list all the possible repairs that the shop is capable of doing, and the user will select which repairs they want to have done (i.e., using checkboes.)
Each repair can be assigned to a different mechanic. Each repair can also be cancelled or declared to be done, independent of the other repairs. That seems to require that each repair become a separate instance in a database.
Additionally, each repair job can be only performed by certain mechanic. So I need the ability to associate each repair job to it's own unique list of mechanics to choose from.
Has anyone seen an example of a django form, that does something like this? Thanks.
This is what formsets (and model formsets) are for.
It's been a while since the question is asked and I had the same problem:
I solved it by instance = form.save(commit=False), then setting the different attributes, then instances.save(force_insert=True), then deleting the form.instance.id....
HOWEVER this means that all fields that are eventually overwritten in the save method stay after the frist call to save()... This bit me hard!
How did you end up doing it?
I am building a site where users can make changes to their publicaly displayed profile. However I need all changes to be approved by an admin before going live. Until the changes are approved their old profile will be displayed. In the admin there should be a list of profiles awaiting approval. It is preferable, but not required, to keep a history of versions.
I have looked at django-reversion, but don't think that will handle showing an old version while keeping a new one under-approval.
I'm looking for ways to achieve this with django...
Two from-the-hip ideas. How about...
Use reversion and add logic which auto-marks a profile as 'unapproved' on save() if the save is not performed by an administrator, then add a custom accessor to your code that gets the latest approved profile from the reversion archive.
Or, if reversion won't play nicely, have a 'current profile' and 'pending profile' for each user and update the FKs when the profile is approved...
This apps do exactly what you need
http://github.com/dominno/django-moderation
I've had some problems using django-moderation from dominno, which are:
Using a unique model for tracking changes in several others, with a GenericForeignKey reduces the amount of tables needed to monitor things, but it's a pain to manage. And I don't trush GenericForeignKeys for this type of task.
Deserialization of sandboxed values would invariably fail if I changed one field's name in the model. (for example, if I migrated a field change of name after monitoring it in moderation). It should at least be able to recover non bogus field values.
So I made my own app, which tackles the problems mentioned above.
It should give you what you're looking for.
https://github.com/artscoop/django-approval
It has auto approval mechanism, field selection (you can always ignore some fields, and put others to validation) and default values (for example, automatically set an object to hidden when it's created, so that it can be moderated without being visible in the first place)
Instead of deleting records in my Django application, I want to just mark them as "deleted" and have them hidden from my active queries. My main reason to do this is to give the user an undelete option in case they accidentally delete a record (these records may also be needed for certain backend audit tracking.)
There are a lot of foreign key relationships, so when I mark a record as deleted I'd have to "Cascade" this delete flag to those records as well. What tools, existing projects, or methods should I use to do this?
Warning: this is an old answer and it seems that the documentation is recommending not to do that now: https://docs.djangoproject.com/en/dev/topics/db/managers/#don-t-filter-away-any-results-in-this-type-of-manager-subclass
Django offers out of the box the exact mechanism you are looking for.
You can change the manager that is used for access through related objects. If you new custom manager filters the object on a boolean field, the object flagged inactive won't show up in your requests.
See here for more details :
http://docs.djangoproject.com/en/dev/topics/db/managers/#using-managers-for-related-object-access
Nice question, I've been wondering how to efficiently do this myself.
I am not sure if this will do the trick, but django-reversion seems to do what you want, although you probably want to examine to see how it achieves this goal, as there are some inefficient ways to do it.
Another thought would be to have the dreaded boolean flag on your Models and then creating a custom manager that automatically adds the filter in, although this wouldn't work for searches across different Models. Yet another solution suggested here is to have duplicate models of everything, which seems like overkill, but may work for you. The comments there also discuss different options.
I will add that for the most part I don't consider any of these solutions worth the hassle; I usually just suck it up and filter my searches on the boolean flag. It avoids many issues that can come up if you try to get too clever. It is a pain and not very DRY, of course. A reasonable solution would be a mixture of the Custom manager while being aware of its limitations if you try searching a related model through it.
I think using a boolean 'is_active' flag is fine - you don't need to cascade the flag to related entries at the db level, you just need to keep referring to the status of the parent. This is what happens with contrib.auth's User model, remember - marking a user as not is_active doesn't prompt django to go through related models and magically try to deactivate records, rather you just keep checking the is_active attribute of the user corresponding to the related item.
For instance if each user has many bookmarks, and you don't want an inactive user's bookmarks to be visible, just ensure that bookmark.user.is_active is true. There's unlikely to be a need for an is_active flag on the bookmark itself.
Here's a quick blog tutorial from Greg Allard from a couple of years ago, but I implemented it using Django 1.3 and it was great. I added methods to my objects named soft_delete, undelete, and hard_delete, which set self.deleted=True, self.deleted=False, and returned self.delete(), respectively.
A Django Model Manager for Soft Deleting Records and How to Customize the Django Admin
There are several packages which provide this functionality: https://www.djangopackages.com/grids/g/deletion/
I'm developing one https://github.com/meteozond/django-permanent/
It replaces default Manager and QuerySet delete methods to bring in logical deletion.
It completely shadows default Django delete methods with one exception - marks models which are inherited from PermanentModel instead of deletion, even if their deletion caused by relation.