New models appearing in "Moderated objects" in admin, but are visible even before approval

[dmsm]

I've followed the instructions for setting up the app and everything seems to be working fine - there are no errors and new models are placed in the moderated table - but even if I do not approve a new model, it is still visible when I try to access it. Any thoughts on what's wrong?

[treyhunner]

You may have auto-approval enabled or you may have enabled visible_until_rejected (this is the expected behavior with that setting on). It would help to see what the problematic moderation and registration code look like?

As I noted in this issue, if you are testing with staff users you may be auto-approving the model instances without realizing it.

[caseycesari]

I'm having a very simliar problem. A model instance is created both as a moderated object and as a live instance of the model that should be moderated (in this case, Project). This happens whether I created the new instance through the command line or through a BaseModeratedObjectForm. Even if I reject the new object in the moderation queue, the live version stays as is.

The only time changes are held in moderation is if a change is made after the model is created. If I make a change to the model then, the changes are viewable in the moderation queue but not on the actual instance.

I have visible_until_rejected = False and I'm not testing with a staff account.

Any other recommendations? Thanks

[gdsaxton]

I have a similar situation as @caseypt - has there been any resolution for this?

[somesmart]

are you overriding the save function inside the view or the model? I'm getting the same results as @caseypt and @gdsaxton, and I think that is the reason.

[gdsaxton]

@somesmart - I'm not sure what you mean by overriding the save function. Could you please give an example?

[somesmart]

@gdsaxton sorry, I'm still a beginner with Django. I probably should have said if you are manually calling the save in a generic class based view and overriding the is_valid function. Here's an example from my code (used to assign the user from the person who submits the form):

def form_valid(self, form):
    if form.is_valid():
        obj = form.save(commit=False)
        obj.user = self.request.user
        obj.save()
        return HttpResponseRedirect('/accounts/')

This may not be related, just a guess from what I've seen!

[gdsaxton]

@somesmart Thanks -- that helps. I am not an expert, either. I'm doing something similar to you:

def article_add(request):
    form = ModeratedArticleForm(request.POST or None)
    if form.is_valid():
        cmodel = form.save()
        cmodel.save()
        messages.success(request, 'You have successfully added your article to the database.')
        return redirect(article_add)
    return render_to_response('article_add.html', {'article_form': form},
        context_instance=RequestContext(request))

[artscoop]

Same bug/issue here. I tried the app with 2 models :

• A small model with no ForeignKey and no custom objects
• A more complex model with ManyToManyField, ForeignKey and custom objects (doesn't work either with the default attribute)

The moderation does not work using the admin interface. When one (superuser or staff) creates a model instance, it is visible by anyone and visible in the moderated objects too. This is not valid for both models.

However, for the small model, the behaviour when creating an object from the shell or from code is fine.

[dominno]

@artscoop Have you solved this issue ?

Keep in mind that auto_approve_for_superusers and auto_approve_for_staff is set by default to True I have tested with auto_approve_for_superusers and auto_approve_for_staff set to False and its working for me.

Also it could be that you had visibility_column set to True by default. It should be set to False by default.

[artscoop]

Hi, the only way I had to solve the iuusues with moderation was adding a "moderated" boolean field to my model. From time to time, I need to manually call auto_moderate on some objects, but globally, I've managed to use the app well. (Had to do some edits in the code for admin form building, since django-moderation dit not take into account the Meta class and some other fields)

[dominno]

@artscoop Do you have some fixes that you think could be merged with origin repo ?

I thinking about making the visibility column in moderator class the default behavior.

[lsmithso]

Hi: I'm having the same problem. The only way I could get it to work was to add a visibility_column. Even then it doesn't work fully. An instance remains visible even after changing it from Approved to Rejected.

The model objects are created anonymously. The Moderation admin shows them as being in the correct state.

My Moderator class settings are:

auto_approve_for_superusers = False
auto_approve_for_staff = False
auto_reject_for_anonymous = False
visible_until_rejected = False
visibility_column = 'visible'
auto_approve_for_groups = []

[artscoop]

Hi. Actually, I think that moderation works on ModerationObject instances. For example, you create an instance of User. It is made invisible, and a ModeratedObject instance is created. If you reject this instance, the User object is never made visible. In your case, you create an instance of A. It is invisible, and has a ModeratedObject tied to it. If you accept this object, it makes your A instance visible. You have your first version. Subsequent operations on the matching ModeratedObject are about allowing changes to the object or not. Maybe I'm not clear enough, but this is a consistent behaviour.

[lsmithso]

Hi: Yes, that makes perfect sense, its just not the use case I need for the project I'm working on.

artscoop writes:

xHTML, UTF-8 [Click mouse-2 to display text]

Les Smithson

[artscoop]

Actually I think there is a way : you can write a signal listener, listening on moderation events. On refusal, you can set the visibility attribute of the original object to False. This might be enough for your use case, I think.