TYPO3 Extbase FE form - how to remove/delete inline relation - frontend

I have a complex custom Extbase Database on which I am doing a frontend (FE) editor with subtables. With the propertyMappingConfiguration allowCreationForSubProperty I was able to implement an easy way for the user to add new sub-records in M:n relation.
Now my question is how can I implement a deletion of those records? Simply removing the properties from the FORM (in my case removing tx_jobfinder_jobanzeige[jobanzeige][sprachkenntnisse][2][niveau]) from the html-form does obviously not trigger a delete event for this sub-table entry.
Is there a way to automatically trigger it via extbase? How would I implement that?
Setting tx_jobfinder_jobanzeige[jobanzeige][sprachkenntnisse][2] to null or how would that be possible?

In case anyone is struggling with the same problem or asks how this is done. I found the hidden problem. In the edit-form the user can remove such a connection and via javascript I remove the selects BUT you also have to remove the hidden field [__identity] - then via cascade Extbase automatically updates the object and all will be saved correctly.

Related

Update Kentico document field regardless of versioning

I have a field on one of my base page types which I need to update programmatically from an external data feed, so that it can be included in my Smart Search index.
The documents are versioned, but I want to update the published value of this field regardless of checkout state, and obviously avoid any sort of overwrite when documents are checked in.
The field will not appear on the editor form -- or ideally, would conditionally display for Global Admins.
It appears that using the API to update the document without doing a CheckOut fails silently. However if I do a Checkout/Update/CheckIn on a checkout-out page, the author will lose their work I assume?
Any way to handle this "versionless" field via the Kentico data model and API?
I don't think there is a way around updating checked out pages. You can update the page type table directly, but as you mentioned, it will be overwritten when they check in. You could update the version history I believe to make changes to the current data that is checked out, but again, I think that will be lost if the user cancels.
The only way I can think of to solve your issue is to create another table that maps the values you want to the page. Then you don't have to worry about the pages being checked out, you just need to grab the documentID or something. Since the value isn't displayed to the editor, you just have a field that does a lookup on this table.
The preferred and right way is using the API but as you stated, it causes problems if a user has something already checked out and working on it or it's in workflow and not published yet.
If the field you're updating is page type specific, there is one thing specifically I can think of and that's going directly to the database to the page type's database field and perform an update to that field.
Note: this is not recommended unless you know specifically what you're doing and have done full testing on it
The down side of going direct to the database is this will not update the current version since you're using check in/out and workflow. You will also need to update the checked out and current version which means you need to:
Go to the Document itself in the cms_documents table and get the document you are working with.
Then using the fields DocumentCheckedOutVersionHistoryID and DocumentPublishedVersionHistoryID' you can get the version history IDs of the document from theCMS_VersionHistory` table.
Then you can perform an update to the CMS_VersionHistory and your custom page type fields.
You will then need to look in the CMS_WorkflowHistory table and find out if that document is in workflow and in what step.
After you have that workflow history step, use the VersionHistoryID field to go back to the CMS_VersionHistory table and update that record with your data.
Again, not an elegant solution since you are using check in/out and workflow but after some trial and error and testing you should be able to figure it out.
UPDATE
You may also be able to add a custom table or some other linked database table which will allow you to create a global handler. The linked table would be where you perform your updates via API and other calls without versioning or workflow. Then when a user updates a specific page type you could do a check to see when the last time that linked table was updated and update the field(s) you need on update of that particular page (of course by node and document IDs).
Unfortunately you'll have to check it in and out with API. See examples here.
Also you might need to publish it in order to reflect changes on the live site.

update netsuite parent field via suitescript in view mode

I have scripts that react off of, for example, a client Recalc client event. For example, on my form I have a subtab that users may add or remove items from. Based on actions on this subtab (housing a child record of the parent) I would like a field on the parent to update (say to show a total from the children records).
As I was saying, these events seem to work fine if in edit mode but they do not work correctly in view mode. (even in view mode these child records have a "Delete" option at the end of each row in the subtab. This was provided by netsuite by default.
I wondered if anyone had any tips to best allow this parent field to update real time while in updating the subtab rows with the form in view mode.
Thanks.
You can make a custom field on the parent (header) whose value is determined by saved search. For instance, make a saved search that totals the line values by transaction. Be sure to make it filter by transaction in the Available Filters tab. Make the search public so everyone can use it.
Create the custom field that sources the total from the saved search. Make sure to uncheck the "Store Value" checkbox, as you don't want to store the data, you want to reference the search results. You do this on the Validation and Defaulting tab. You'll see a field for Saved Search there. Choose the search you created above.
As you remove/add/change lines on the transaction, the field updates accordingly. In essence, you don't need a single line of code to make this work - it's all in how you create the search and the custom field that references it.
I have a similar situation posted here.
The NetSuite team answered me by email, and it happens you can't really achieve this on the view mode: some API methods are not available. Their suggestion to my case (and I think it applies to yours too) was really to force a refresh on the whole page.
Of course, you can always achieve this accessing the DOM elements directly, but this isn't a best practice, as your code can stop working if these elements change on a version update.
I had the same problem, I'm not able to restrict on view or remove edit button. But, there was one alternative solution with workflows, you can deploy workflow on child record edit mode restrictions, then if the user clicks edit on view then the record will not be available to edit. This concern will apply to custom record as well.

Remove note's autosave functionality by adding other entity's notes on form in CRM 2011

In CRM 2011, notes get automatically created and attached to main record on lost focus event. Requirement is to remove this auto save functionality. Only till main form is open user should be able to edit notes. And newly added notes should only get saved once main form is saved. For example, if user add one note and closes the browser or do not save the main form, then that note should not get attached to main record, new note should get discarded.
I was thinking following solution:
create new custom entity TempNotesHolder
Create 1:N relationship with the entity where we want this functionality, for example Case entity
Make actual case's note section read only(it is requirement, user don't want to edit/delete functionality for notes once note get created)
Write plugin for create event of Case and create one Record for TempNotesHolder and associate it with case(RegardingId field in TempNotesHolder = incidentId) This will ensure one Case will always have only one associated TempNotesHolder record. There is no way in CRM 2011 to ensure One entity record will have only one record in associated entity i.e. 1:1 relationship. At least I don't know the way. Let me know if any one are aware about it.
On Case form, add one IFrame below Case's note section
on case form load event, get TempNotesHolderId associated with case using fetchXml.(There is no actual field in Case entity that refer to associated TempNotesHolder, hence need to use fetchXml. Some how we can add associated TempNotesHolderId to Case entity, and place that field on Case form, make it hidden, to avoid fetchXml)
Prepare url to display only notes of TempNotesHolder record.(/_controls/notes/notesdata.aspx?EnableInlineEdit=false&EnableInsert=true&id=&ParentEntity=
Set this url to newly added IFrame, so notes of associated TempNotesHolder get displayed in IFrame. It will also have link "Add New Note".
User can add note to TempNotesHolder which are not directly added to Case record.
Next develop plugin on pre save event of Case and check if there are any notes added to TempNoteHolder, if yes move those notes to Case record, and delete notes for TempNoteHolderId. This way notes will get saved to main record only on main form save.
To handle browser close event after adding few notes to TempNotesHolder, write plugin on Case pre Retrieve event, check if any notes present for associated TempNotesHolderId, if present then delete those notes. (As notes are present on TempNotesHolderId, that means due to some reason these notes are not moved to actual case record and we no longer need them, so delete them. This will ensure on case load, TempNotesHolder note section always be blank)
The above solution was fine till step 8. When I tried to add notes in TempNotesHolder, it gave me error, "Record with does not exists in TempNotesHolder". Then I checked that GUID, I disappointed to know CRM is taking IncidentId when I create note for TempNotesHolder. Then I tracked down the actual code for create notes to find why it is taking IncidentId instead of TempNotesHolderId. I found following code in "_static/_controls/notes/notes.htc" function name "UpdateNote"
xml="0"+CrmEncodeDecode.CrmXmlEncode(value)+""+_parentCrmFormSubmit.crmFormSubmitId.value+""+this.parentEntityType+""+CrmEncodeDecode.CrmXmlEncode(currentTitle)+""+this.userId+""
CRM is taking _parentCrmFormSubmit.crmFormSubmitId.value as objectid while creating note.
Now I stuck with this problem. Any thoughts to overcome this show stopper issue are appreciated. Also any other alternate solution to main requirement are also welcome.
Pravin Pujari (Microsoft Dynamics CRM 2011 Developer)
I would suggest simplifying the solution as follows:
Add a field to Case called new_notetext.
Create a Plugin against the Pre-Create and Pre-Update messages on the Case entity.
In the plugin, take anything entered into new_notetext and add a note to the Case entity using that text. Then clear the field new_notetext so nothing is saved with the record.
Should work just fine and is much simpler to implement.

How should I implement `OnLoad` event handler when creating an activity using a contact?

I've created my own solution with a custom entity of type activity. I'd like to show a message whenever a new instance of it is created using an existing contact but not allow the user to create one, if only attempting to do that without going via contact.
Basically, my aim is that it won't be impossible to just create that activity (the form will be hidden directly at any attempt except for one way only). The user will have to go to contacts (or leads etc.) and in there add and create an instance of the custom activity entity. That way, I can assure that the field "regarding" will be filled out already.
I'm guessing that I need to detect somehow that the opening of the form is a creation attempt. How can I do that?
Also, as it is now, the user can't create a contact-less activity of the custom type because it doesn't appear on the menu with other activities. I must have disabled it somehow but I have no idea how. Anybody who has one?
You could do this a bunch of ways but the easiest would probably be to:
Make the regarding field read only.
Make the regarding field mandatory.
That way if a user opens a create new form they wont be able to set the regarding and because its mandatory they wont be able to save the record. When they open via an existing contact the regarding field will be mapped automatically. That said in this case just making it mandatory my be enough.
(As a side JavaScript can be used to identify the current form state, but I'm not sure how useful that is here).
In terms of where custom activities appear, by default mine show in a number of locations, for example:
CRM > Workplace > Activities > Ribbon > Other Activities > XXX.
CRM > Workplace > Activities > View Selector > XXX.
They don't show under the left hand navigation of the workplace because they are grouped under 'Activities'. I'm pretty sure these are all the default settings.
You can exercise greater control by editing the sitemap, where you can put pretty much anything, anywhere.
In addition to Mr Wood, I'd like to show you some code. It works as supposed to but I'm not sure if it's optimal.
var foo = function () {
var whatIsGoingOn = Xrm.Page.ui.getFormType();
if (whatIsGoingOn === 1)
alert("Let there be an entity!");
else
alert("Not a creation...");
}
The other states' (deletion, update etc.) numeric values are listed here.
Answering the second part of your question:
When you create a custom activity you can choose whether to have it appear in 'normal' Activity menus or not by checking the box at the top right of the entity form. This is a once-only choice as far as I know and can't be changed later.
For your setup, I would suggest NOT checking this box, so it does not appear in the activity menus to avoid users even being tempted to do it that way.
Instead, add an explicit relationship to the activity N:1 to Contact, and another N:1 to Lead. Use this relationship to add your activity to the left navigation of Contact and Lead forms, or add a grid for them (depends on how you want to use this and if you need to filter the view to something other than the default "Associated View").
When a user navigates to this section they will see if any previous activities of this type exist, and be able to add a new one. BUT this means that the child record is a child via this relationship, not using "regarding", so use a script on the form for the activity so that if Contact is filled in, it is copied to Regarding, and if Lead is filled in then that is copied. If neither, then use an alert or other means to warn the use that something is wrong (see comment earlier). If you want Regarding to be read-only but filled in by script, you will need to make sure to use the force the value to be saved:
Xrm.Page.getAttribute("regardingobjectid").setSubmitMode("always");
You must have the lookups for Contact and Lead on the form to be able to use them in your scripts, but you can make them not "visible by default" so they are there but not seen by the user (and taking up no space).

How to handle entity creation/editing in a master-detail

I'm wondering what strategies people are using to handle the creation and editing of an entity in a master-detail setup. (Our app is an internet-enabled desktop app.)
Here's how we currently handle this: a form is created in a popup for the entity that needs to be edited, which we give a copy of the object. When the user clicks the "Cancel" button, we close the window and ignore the object completely. When the user clicks the "OK" button, the master view is notified and receives the edited entity. It then copies the properties of the modified entity into the original entity using originalEntity.copyFrom(modifiedEntity). In case we want to create a new entity, we pass an empty entity to the popup which the user can then edit as if it was an existing entity. The master view needs to decide whether to "insert" or "update" the entities it receives into the collection it manages.
I have some questions and observations on the above workflow:
who should handle the creation of the copy of the entity? (master or detail)
we use copyFrom() to prevent having to replace entities in a collection which could cause references to break. Is there a better way to do this? (implementing copyFrom() can be tricky)
new entities receive an id of -1 (which the server tier/hibernate uses to differentiate between an insert or an update). This could potentially cause problems when looking up (cached) entities by id before they are saved. Should we use a temporary unique id for each new entity instead?
Can anyone share tips & tricks or experiences? Thanks!
Edit: I know there is no absolute wrong or right answer to this question, so I'm just looking for people to share thoughts and pros/cons on the way they handle master/details situations.
There are a number of ways you could alter this approach. Keep in mind that no solution can really be "wrong" per se. It all depends on the details of your situation. Here's one way to skin the cat.
who should handle the creation of the copy of the entity? (master or detail)
I see the master as an in-memory list representation of a subset of persisted entities. I would allow the master to handle any changes to its list. The list itself could be a custom collection. Use an ItemChanged event to fire a notification to the master that an item has been updated and needs to be persisted. Fire a NewItem event to notify the master of an insert.
we use copyFrom() to prevent having to replace entities in a collection which could cause references to break. Is there a better way to do this? (implementing copyFrom() can be tricky)
Instead of using copyFrom(), I would pass the existing reference to the details popup. If you're using an enumerable collection to store the master list, you can pass the object returned from list[index] to the details window. The reference itself will be altered so there's no need to use any kind of Replace method on the list. When OK is pressed, fire that ItemChanged event. You can even pass the index so it knows which object to update.
new entities receive an id of -1 (which the server tier/hibernate uses to differentiate between an insert or an update). This could potentially cause problems when looking up (cached) entities by id before they are saved. Should we use a temporary unique id for each new entity instead?
Are changes not immediately persisted? Use a Hibernate Session with the Unit of Work pattern to determine what's being inserted and what's being updated. There are more examples of Unit of Work out there. You might have to check out some blog posts by the .NET community if there's not much on the Java end. The concept is the same animal either way.
Hope this helps!
The CSLA library can help with this situation a lot.
However, if you want to self implement :
You have a master object, the master object contains a list of child objects.
The detail form can edit a child object directly. Since everything is reference types, the master object is automatically updated.
The issue is knowing that the master object is dirty, and therefore should be persisted to your database or whatnot.
CSLA handles this with an IsDirty() property. In the master object you would query each child object to see if it is dirty, and if so persist everything (as well as tracking if the master object itself is dirty)
You can also handle this is the INotifyPropertyChanged interface.
As for some of your other questions :
You want to separate your logic. The entity can handle storage of its own properties, and integrity rules for itself, but logic for how different object interact with each other should be separate. Look into patterns such as MVC or MVP.
In this case, creation of a new child object should either be in the master object, or should be in a separate business logic object that creates the child and then adds it to the parent.
For IDs, using GUIDs as the ID can save you quite a bit of problems, because then you don't have to talk to the database to determine a correct ID. You can keep a flag on the object for if it is new or not (and therefore should be inserted or updated).
Again, CSLA handles all of this for you, but does have quite a bit of overhead.
regarding undo on cancel : CSLA has n-level undo implemented, but if you are trying to do it by hand, I would either use your CopyFrom function, or refresh the object's data from the persistance layer on cancel (re-fetch).
i just implemented such a model.but not using NH, i am using my own code to persist objects in Oracle Db.
i have used the master detail concept in the same web form.
like i have master entity grid and on detail action command i open a penal just below the clicked master record row.
On Detail Add mode, i just populate an empty entity whose id were generated in negative numbers by a static field.and on Save Detail button i saved that entity in the details list of the Master Record in Asp.NET Session.
On Detail Edit,View i populated the Detail Panel with selected Detail through ajax calls using Jquery and appended that penal just below the clicked row.
On Save Button i persisted the Master Session (containing list of Details) in database.
and i worked good for me as if multiple details a master need to fill.
also if you like you can use Jquery Modal to Popup that Panel instead of appending below the row.
Hope it helps :)
Thanks,

Resources