I have a reason to prefer my plugin to be registered on post-op but I'd need to put something in it (change a field to another value). Do I really have to register it on pre-op or can I shove my update into it despite that the operation has been carried out already?
I'd prefer to avoid firing up an update. The code logic might get a bit crowdy and confusing by that, since there'll be a lot of stuff to do upon a "real" update.
Changes made to the target entity in post-op will not end up in the database unless you run an update manually.
You could consider breaking up your plugin into two. One to change the field in pre-op and one to do whatever it is you're doing in post-op.
Plugins can share data: http://msdn.microsoft.com/en-us/library/gg328579.aspx
Related
I have a custom service module (myproject-service & myproject-api).
With Liferay 7.2 and previous versions, when I changed my database model (for exemple : add a new column in a table in the service.xml), I used an UpgradeProcess and an UpgradeStepRegistrator, with an incrementation of the Liferay-Require-SchemaVersion.
Since the 7.3 version, the autoupgrade has been moved to a property and changed to false value. In developpement, this value is true and everything works fine but in production, my custom service doesn't upgrade now at server start.
Is there a solution to make this system works again automatically ? I've seen that now we have to do the upgrade manually in the gogo shell with upgrade:execute command.
You are probably looking for
Set this to true to execute the upgrade process when the portal starts and modules are activated.
upgrade.database.auto.run=false
You still need to build the "upgradeProcess", as in:
https://help.liferay.com/hc/en-us/articles/360018162851-Creating-Data-Upgrade-Processes-for-Modules-
Technically, you could activate the same property in production systems. However, this is neither safe, nor performant: The solution for table updates is generic and (as far as I know) will
export your table's data,
DROP TABLE,
CREATE TABLE (with the new structure)
populate the table with the previously saved data.
Now, apart from this being horribly slow for large amounts of data, there are some other shortcomings:
if you have renamed a column, or
added a non-nullable column,
this would fail to do the work as you expected it (even in development).
Further:
If this process is interrupted at any time, you might lose all of your data
In many cases, a simple ALTER TABLE xxx ADD COLUMN yyy would be sufficient, and is quick, safe and easy to do within SQL. That's where your UpgradeProcess kicks in. You wouldn't want to do that after every little bit in development (hence the property), but you certainly don't want to DROP TABLE with important data in production, and wait for who-knows-how-long, when there was just a trivial change.
From that point of view: You want to write a custom UpgradeProcess, even if you don't know that you do. And there's even a great starting point, that takes away the repetitive and low level work.
I need to change creation time of a product for my custom logic in my project for the PLP.Is it fine to alter the creation time for a product,via ImpEx?Is it recommended or can it break something else?
Creation Time is initial=true, which means it can be set only once, and only during creation. It can't be edited after that. This value is automatically set by Hybris, and I wouldn't recommend changing it.
Yes you can change it if you use forceWrite=true and use the legacy import mode (it only uses the Jalo layer).
Cf. https://help.hybris.com/1808/hcd/8bef094d86691014a87a93789935b39b.html
However this should only be used for testing purpose. In your project you'll prefer creating a custom attribute to store your own "creation date" if you absolutely need to have logic on this info.
Also, to answer your question, modifying the creation date may impact the cache management. And if you force inconsistent values (creation in the futur or after the modification date for example) you can expect weird results.
Yes, it's not recommended to change it and neither you can change with any modifiers or ImpEx. Still, if you need to change, you can use SQL query to update it directly on database level.
After doing "jhipster import-jdl your-jdl-file.jh" to generate entities, if I found something missing (ie. relationship, entity, or field within an entity), can I redo the jh file and rerun the command again to make the changes? Appreciate the help!
Yes, you can. But you must be carful to:
Your code is in source control
No file is dirty, I mean all are committed
Regenerate and overwrite all files
Review changes carefully file by file to bring back your overwritten
changes.
In case of any problem, it is safe to just remove all local changes.
Another approach that I prefer, is to use the command line to do entity changes commands to affect changed entities only. Use
jhipster entity entity-name
It will overwrite affected entity files only, but be carful that, these changes will be outside your JDL file.
You still must be carful using source control as described above.
It is indeed possible but this might erase some of the custom modifications to the model you've made as it is regenerating them.
That being said, I strongly advise you take a look at the liquibase capabilities offered by Jhipster (For SQL databases). With that, you just have to update your model classes using the right annotations and that will update your database model accordindly (After a few other steps). That can be used for small adjustments when you've already been working on your app, rather that re-generating everyhting, which would seem a bit overkill to me.
If you want the full procedure, take a look at the (well detailed) documentation : https://jhipster.github.io/development/ and go down to Using MySQL, MariaDB or PostgreSQL in development.
Hope this helps !
I have a ribbon button on the case entity that updates a single two-option field on the form via javascript. When this is used on a case that has been resolved/closed it returns an error as the form is now read only.
Is there a way in javascript that I could get it to re-activate the form, change the field and then put it back to the way it was before? I have tried to force the change on the form but even if i manage to make it appear that you can save it, it will return the error as the form record is still counted as de-activated, even though you can change the fields
Thanks
You should be able to use a SOAP call for this, its a little involved, I would suggest starting here. You have to generate XML that represents the request, the link provides some tools to do this.
I believe you will need to issue JavaScript versions of SetStateRequest (to open) and CloseIncidentRequest (to close).
On the other hand, which is a different approach entirely, is to disable the button when the record is deactivated, then users have to manually renable the record make the change and close again. This is closer to 'working with the system' which I have touched upon here, its a different situation but the principle still applies.
I have a request form I'm working on, wherein different departemnts need to be able to update it. To minimize overlap and lost changes I'd like to be able to submit data from the new form to different lists, but I cannot find a way to do this.
Does anyone have any experience trying to do anything similar?
If you're familiar with JQuery andSPServices I could envisage a way to do this.
In the EditForm.aspx, add the JQuery and SPServices libraries. using the $.(document).Ready function, I'd do a quick item update with the SPServices and just copy a column with the same data, so in effect no change looks to have taken place. I'd add in the edit comments something like "Pseduo checkout to [name], [date_time]".
Then allow the user to edit the form as normal but in the code you've added, you trap the PreSave Action and check that the person trying to do the save is the same as the last modified - if it is, save as normal, otherwise, return false on the PreSave and it will be denied. When you actually allow the save, set the edit comments to something sensible.
To complete this, check before doing the pseudo checkout, that the last comments don't contain the psuedo checkout phrase so that you can prevent anyone opening/editing the form whilst somebody else is in the middle of an edit.
This gives a cheap and relatievly easy to implement Check-In/Check-Out for a list. Not perfect of course but should work well in most scenarios (not in datasheet though, so you might need to prevent that type of edit).
If you have two lists would you not then have the problem of potentially two requests for the same thing?
Does none of the version control options for the list solve the problem of potentially multiple concurrent editors?
While SPService is certainly a solution, but you will have to build a UI of ur own.
Try writing a event receiver, which can copy over item to another list as soon as it is created.
It will be nice if you can tell why you really want to have a copy of item in another list
i.e. Auditing purpose etc. , you can get a perfect solution for this in Forum