I need to perform soft deletion using jhipster.
Ex:
If user click on delete button I need to mark is_active flag to false.
Writing custom code will be the only solution or is there any way to do it?
Things I have done so far :
I have followed Jhipster web site and created Monolithic application.
Then I have created new entity called 'Student' using the entity sub-generator . (filed names : id, name age, address and is_active. )
The Sub generator generated files contain all the basic CRUD operations and provided a CRUD front-end for student entity.
The front end contains buttons for create student, view, edit and delete.
When I Click on a delete button the studuent record will be permanatly delete from the database.
But my Requirement is to keep the record in the database and mark only the is_active filed in to false.
Basically I need to keep history data of the student without permanatly deleting them.
you will have to edit it yourself. First of all, I recommend you to extend all classes generated by JHipster (except for Resources, you will have to create another class and use a custom mapping thus changing the service in the frontend)
Extend your StudentRepository and create a method that updates the is_active value (it would be better if it receives the id and the value: true or false)
Extend yout StudentService and create a new method (e.g. call it public void disableAddress(Long id))
In that method the your newly created method in the repository layer
Edit StudentResource and change the code inside the deleteStudent method and call your newly created method in the service layer
If you created a new resource, change the service calling your api.
Related
I use the repositoryFactory in a custom plugin's Vue file in Shopware 6. When I save an entity I do this:
this.settingsRepository
.save(this.setting, Shopware.Context.api)
.then((result) => {
In case the person sends the form and this function is called, I want to get back the id of the setting in case the person hit's the save button again. But then the entity needs to be updated and not created. As I see from the response, there is an id, but it's in config.data -> json serialised.
How's the default way of solving this issue?
The best practice would be to re-fetch the entity after persisting it. This is because some entities may have fields that get automatically computed or indexed server-side and you'd probably always want to have the entity in its actual current state. If you're absolutely sure you don't want to fetch the entity again, you could manually set the _isNew flag to false after persisting:
this.setting._isNew = false;
This will then cause the save function to use the update instead of the create route. Keep in mind that this is actually kind of an internal property, as there is no setter for it and as already mentioned fetching the entity again is encouraged.
Also you shouldn't have to worry about the id. It should've already been generated client-side and set to the entity, when using the repository to create a new entity like that:
this.setting = this.settingsRepository.create();
Similar post to this:
Curious about properly defining the DAC.
I have a T-SQL CREATE VIEW script that I've added to the 'Database Scripts' are of the Customization project as shown. But I suspect that I haven't added the DAC properly. When I attempt to add this DAC within the context of a Generic Inquiry 'Add Related table' screen I do not get any results when searching for the name of the DAC I tried to create.
When I initially attempted to define the DAC in the 'Code' area, the system complained that the object didn't exist in the database. This makes sense as it's a SaaS instance and I've just created the T-SQL view from a local copy of the database.
So I just added the CREATE VIEW statement within the 'Database Scripts' area and published the customization successfully.(This implies to me that the object exists in the database now).
But I now believe I need to retroactively 'Generate Members from Database' in order to identify the key fields so Acumatica can see how it aligns with other DACs. Is this a correct assumption?
In the CODE area I see this (where vGFCINItemClassSeg is the name of the SQL view )
using System;
using PX.Data;
namespace vGFCINItemClassSeg
{
[Serializable]
[PXCacheName("vGFCINItemClassSeg")]
public class vGFCINItemClassSeg : IBqlTable
{
}
}
Any suggestions on how to properly provide Acumatica with what it needs to associate this to the INItemClass table in the database and make it available as a DAC?
Got this resolved.
Problem was that I had attempted to add the DAC prior to adding the Database script.
Solution: unpublish the customization package. drop the custom SQL view from the database. Start a new customization package. Add the Database Script first. THEN publish. Then after that is successful, re-open the customization project and add the DAC as a second step.
I have a custom table in SQL Server called AnimalBreed and maintenance page.
I wish to add User Defined Field support via the KvExt approach instead of
traditional practices involving either CSAnswers or a CacheExtension of the
DAC and underlying "Usr" fields.
Is this possible?
Can it be done for line-level (child) DACs, such as
existing INLocation and INLocationKvExt?
Thanks!
UPDATE:
It appears the feature needs at least:
ensure your table has the NoteID column as uniqueidentifier datatype and the DAC has the corresponding field: Guid? NoteID and [PXNote()] attribute.
In the ASPX, if not ListView, add the following to the PXDataSource tag:
EnableAttributes="true"
By making these changes, I can Manage User Defined Fields, choose Attributes to include, and I can store values to the KvExt table.
I am using Version = 19.205.0023
Sales Order page observation: if I add two UDFs on SO Order Entry page, one is combobox and one is checkbox, setting their values saves just fine, but then updating the combobox and save leads to loss of the checkbox (from true to false), unless you uncheck and recheck prior to the save. Is this a bug?
Maybe technically possible but definitely not recommended to use undocumented feature like KvExt.
If you need to deploy User Defined Fields on a page which already contains them. Configure them manually and then add them in a customization package in the user defined fields section for deployment as described here:
https://help-2019r2.acumatica.com/Help?ScreenId=ShowWiki&pageid=e01f29d3-b6b1-40f4-a2d1-45c9d01bdde3
Example:
I use jhipster and I would like to modify the User entity and add fields and relationships.
I use jhipster entity user and this command is not good.
How can I do it?
User is not a JHipster entity, the generator does not manage it. You must edit the code manually or add a related entity where you put additional fields, see doc: https://www.jhipster.tech/tips/022_tip_registering_user_with_additional_information.html
If you encounter a problem where you need to alter the User entity, Its recommend not doing that. Modifying this default entity might break your app depending on the nature of the changes.
Instead, there are other available solutions like:
creating an entity composed of the User entity
extending the User entity
Using composition
by using OneToOne relation like this
entity ApplicationUser {
additionalField Integer min(42) max(42)
}
relationship OneToOne {
ApplicationUser{internalUser} to User
}
Or
Using inheritance
This solution does the same thing as the previous one, but isn’t as straightforward as the first one because you need to:
create a new entity by hand,
adapt the code to make it use this new entity,
potentially manage yourself the database migration to persist this new entity (depending on the nature of the changes).
More info: https://www.jhipster.tech/user-entity/
I'm designing my first project using Core Data (for iPhone) and Im having some issues that might be related with my design approach.
I'm doing an application that allows the user to create an Order (let's say for a restaurant).
I'm using the graphic designer to model my persistence object (i.e. OrdeMO). I add MO to the ead of each name to indicate its a Managed Object.
I use XCode to create the Managed Object Class automatically.
I have created some "DAO" classes that allows you to search or create a new object in the Managed Context.
Now to my problem.
I want to create an OrderMO object to store the order the user is creating, BUT I don't want it to be part of the context until the user actually places it.
I tried creating the object with [OrderMO alloc] but the object I get is "incomplete" and when I try to set any of its attribute I get an error.
I'm assuming the problem is that I need to create the order IN the context in order to use it. Is that so?
I have considered various options:
Create the object in the context and the user rollback if the user discards the order. The problem is that the user might save other context object during the process (like his prefs) so this doesn't work. Is there a way to create the object "inside a separate transaction" of sorts?
Create a wrapper object that will hold the same data as the MO, and then only create the MO when the user place the order. The downside of this is that I have to maintain a new class.
Create an attribute in the MO, such as "placed", and use to filter my searches in the context. The problem with this one is that I will end up with "trash" objects in the domain (i.e. unplaced orders) and I will have to do some cleanup from time to time...
Do I have any other choice?
Any suggestion is appreciated.
Thanks (for reading this long post!)
Gonso
You should create the OrderMO object in the managed object context and then delete it if the user decides not to place the order.
If the context is saved before the object is deleted, the "trash" object will be deleted from the persistent store on the next save (if the context wasn't saved, the "trash" object will never be saved to the persistent store).
The flag to determine if the order was placed or not does not have to live in the OrderMO object as you suggest in option 3. It could be in the view controller that is tracking the order(s) that are being edited. And, again, you won't have "trash" objects because they will have been deleted.