DocumentType.BeforeSave fires after saving Properties
I wanted to track changes to property aliases when saving DocumentType.
Im not sure if that is the wanted functionality, but DocumentType.BeforeSave is fired after all Property changes are saved, so I thought better to ask it here first, before posting the issue to codeplex.
I traced the source code and found out that private method ContentTypeControlNew.saveProperties is called immediately after the button 'Save' is clicked, so I dont get the point of having BeforeSave eventhandler of DocumentType if it works this way...
I'm just hitting the same wall today! And yes, indeed, for example setting a different template (if multiple templates available for current doc type) will get persisted even if you're cancelling out the event!
It's also a bug to me!
And there's more than a single property being affected. Also, text, update date, release date, expire date are also persisted to the database before being able to cancel out the event.
Please add to Codeplex, as this is a serious issue.
I tried to add BeforeSave eventhandler for Documents as well (as Update actionhandler cannot track the value of a property before updating the doc), and it actually behave similar - Changes are preserved before I handle BeforeSave event at docs.
I WAS using documents!! I must have misread your first post, because i was hitting that wall registering for the Document.BeforeSave event. Anyway, it's an issue.
I wonder if this is related to a problem I am having :
I created a custom TextString property on a document type and also a Document.BeforeSave handler. In the handler I set the property to a value. When I save the form my handler is hit and the form screen is refreshed however the property is still blank despite the value being set. When I publish the document I can see the property value is set correctly in the umbraco.config xml but the property still displays blank in the document editting form.
The only way to get the property value to appear in the form is by clicking on another document and then back again to "refresh" the values.
In addition it is something I'm *trying* to fix for the upcoming 4.1 release, I think I have it solved but we'll wait for testing during the alpha/ beta phase to determine that for me :)
Not sure this is the same problem I have, I'm not trying to cancel the event and I want the value to be saved but it just isn't displayed on the edit form after I programmatically set it in Document_BeforeSave().
Am I missing something about your post and how it relates to my problem?
DocumentType.BeforeSave fires after saving Properties
I wanted to track changes to property aliases when saving DocumentType.
Im not sure if that is the wanted functionality, but DocumentType.BeforeSave is fired after all Property changes are saved, so I thought better to ask it here first, before posting the issue to codeplex.
I traced the source code and found out that private method ContentTypeControlNew.saveProperties is called immediately after the button 'Save' is clicked, so I dont get the point of having BeforeSave eventhandler of DocumentType if it works this way...
Hi,
I'm just hitting the same wall today! And yes, indeed, for example setting a different template (if multiple templates available for current doc type) will get persisted even if you're cancelling out the event!
It's also a bug to me!
And there's more than a single property being affected. Also, text, update date, release date, expire date are also persisted to the database before being able to cancel out the event.
Please add to Codeplex, as this is a serious issue.
Cheers,
/Dirk
Thanks Dirk!
you can vote up our issue here:
http://umbraco.codeplex.com/WorkItem/View.aspx?WorkItemId=21847
Cheers,
Nikola
I tried to add BeforeSave eventhandler for Documents as well (as Update actionhandler cannot track the value of a property before updating the doc), and it actually behave similar -
Changes are preserved before I handle BeforeSave event at docs.
Can anyone confirm this issue?
Hi ni5ni6,
I WAS using documents!! I must have misread your first post, because i was hitting that wall registering for the Document.BeforeSave event. Anyway, it's an issue.
Regards,
/Dirk
Haha... good,
](*,) its funny.. neither I did notice that you were talking about documents..
Thanks again Dirk!
I wonder if this is related to a problem I am having :
I created a custom TextString property on a document type and also a Document.BeforeSave handler. In the handler I set the property to a value. When I save the form my handler is hit and the form screen is refreshed however the property is still blank despite the value being set. When I publish the document I can see the property value is set correctly in the umbraco.config xml but the property still displays blank in the document editting form.
The only way to get the property value to appear in the form is by clicking on another document and then back again to "refresh" the values.
Is it the same? Could it be a caching issue?
For the record I covered this error in a recent blog post - http://www.aaron-powell.com/blog/july-2009/the-great-umbraco-api-misconception.aspx
In addition it is something I'm *trying* to fix for the upcoming 4.1 release, I think I have it solved but we'll wait for testing during the alpha/ beta phase to determine that for me :)
Not sure this is the same problem I have, I'm not trying to cancel the event and I want the value to be saved but it just isn't displayed on the edit form after I programmatically set it in Document_BeforeSave().
Am I missing something about your post and how it relates to my problem?
I get it, I'm poaching the thread! I'll start a new one
Hate to bring this old topic back up, but im trying to implement the DocumentType.BeforeSave to control which backend users that can manipulate tabs.
Im using umb 4.5 and trying to do something like this
void DocumentType_BeforeSave(DocumentType sender, SaveEventArgs e)
{
DocumentType oldSender = DocumentType.GetByAlias(sender.Alias);
oldSender is now filled with the new values...
Looking at http://www.aaron-powell.com/blog/july-2009/the-great-umbraco-api-misconception.aspx i understand the issues, but looking at http://umbraco.codeplex.com/workitem/21847?FocusElement=CommentTextBox it says fixes by Niels...
what's the status of this?
is working on a reply...