Thanks Dan,

I was actually thinking also last night of:

3. Override the save() method on the model.

Not tested, not sure how robust, but as it happens there's a hook there 
already as all the models I'm work with have it overridden with tiny method 
that updates some admin fields like last_updated and last_updated_by. This 
could be a nice place for a small hook.

Signals are an idea too, and want to explore them as much for the heck of 
it and learning as anything. But I wonder what you mean by "This is easily 
circumvented." - I'm guessing that even if you catch a signal prior to save 
and do something, there's no guarantee some downstream code won't do a 
save. I wonder if overriding save() is more secure, or if there's any 
possibility other code could go around such an override.

Regards,

Bernd.

On Sunday, 4 March 2018 22:24:38 UTC+11, Dan Tagg wrote:
>
> Two possibilities spring to mind
>
> 1. Don't grant django's database user the right to update the relevant 
> table. If you take this approach you'll need to catch any errors if anyone 
> writes code to attempt to do this
>
> 2. Use signals to catch any save attempts. This is easily circumvented. 
>
> On 4 March 2018 at 09:41, Bernd Wechner <bernd....@gmail.com <javascript:>
> > wrote:
>
>> An interesting question I've not been able to solve reading docs or 
>> Googling. As every posting here only after some serious research efforts 
>> including class inspections ;-). But am stumped and wonder if anyone else 
>> has any ideas.
>>
>> Here is the use case:
>>
>>    1. Load an object from database 
>>    2. Flag it as unsaveable, not to be written back to database under 
>>    any circumstances 
>>    3. Make changes to the object (its fields) 
>>    4. Present a detail view of the object. 
>>
>> Basically, would like the freedom to change an object knowing the 
>> database is secure. 
>>
>> As ever, am more interested in how to do this, than questioning why to do 
>> it. It may not be possible in which case fear not, I'm on top of the why's 
>> and can look at alternative strategies. But this use case provides an easy 
>> way of injecting some filters in one place of a code body I have without 
>> changing any of the views or other code. Simply one small hook I place into 
>> extant code, which will play around with the object (making translations 
>> for example). But in order to do so would want to know this cannot be 
>> written back to the database, that from here on in, it's for display 
>> purposes only.
>>
>> Have a suspicion after some research that this can't be done. In which 
>> case there's a second and almost as useful use case:
>>
>>    1. Load an object from database 
>>    2. Make a copy, that is unsaveable, not to be written back to 
>>    database under any circumstances 
>>    3. Make changes to the copy (its fields) 
>>    4. Present a detail view of the copy. 
>>
>> This has some slightly better chance of being possible. If not as well, 
>> yes indeed, I have to dive into the view itself and put hooks into each 
>> field as it renders I guess. Which is life. But would seem useful to do it 
>> with one of these use cases (again no need to discuss the merits of one 
>> approach over the other at all, am more interested in possibility - 
>> projects have huge amounts of context not readily shareable that influence 
>> the relative merits of one approach over another of course.
>>
>> Regards,
>>
>> Bernd.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com <javascript:>.
>> To post to this group, send email to django...@googlegroups.com 
>> <javascript:>.
>> Visit this group at https://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/9162bad4-935a-ed39-d2d8-a001103ec705%40gmail.com
>>  
>> <https://groups.google.com/d/msgid/django-users/9162bad4-935a-ed39-d2d8-a001103ec705%40gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Wildman and Herring Limited, Registered Office: 28 Brock Street, Bath, 
> United Kingdom, BA1 2LN, Company no: 05766374
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5e292463-504b-41db-984f-86a25d8c36b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to