[quote=Pierre_Admin]

I don't quite get it... can you provide more details and / or a practical example ?

[/quote]

 

Yes. This is something I had in my notes for a few weeks (I managed to do things a bit differently but...).

A bit complicated to explain without going into gory details.

 

 

 

I use a a field to block changes to certain date fields for items that should never be "moved" in time (whether I use the Gantt or the grid to make the changes).

 

i.e. If I "block" an item I shouldn't be "able" to "permanently" change its values using the gantt or the grid. So if I move it in the gantt (or change its values in the grid), the TaskActStart and TaskActEnd values come back to their initial values right after. This is to avoid moving important events that shouldn't ever be moved. It happened a few times and it wasn't fun.

 

 

 

In my DB, because the TaskActStart and TaskActEnd fields are partly determined by functions and auto-assign rules, I decided that when a custom "TaskStarDurLock" field is checked, the TaskActStart and TaskActEnd  values would be copied to 2 other  fields (i.e. : They'd be storage fields) which would be able to provide back the original date values in case TaskActStart and TaskActEnd  are moved.

 

It works pretty well, however, I need to touch the the "DueDate" field (which is associated with the other fields through "auto-assign rules) so that TaskActStart and TaskActEnd re-fetch their original values.

 

I have to do that manually. But I thought that maybe I could do that through a "touch" function which would be run automatically at midnight, only on those "TaskStarDurLock" checked items.

 

That's it.

 

If you want the functions details etc. I can post them. But I'm not sure if that would be useful.