Thanks for the great work on this @Evan Gabhart and @Matthew Giesmann! This should be very helpful for keeping environments clean!
- Log in to post comments
Thanks for the great work on this @Evan Gabhart and @Matthew Giesmann! This should be very helpful for keeping environments clean!
Thanks @Bernd Mueller ... this is very helpful!
Do you see an issue with having RELOAD = 1 always in source control, even if it is removed from the environment copy?
I really like the idea of it reloading, but am concerned about RELOAD = 1 being removed from the copy sitting on our DEV environment where all changes originate ... it would be too easy for someone to accidentally upload a new version of the file without RELOAD = 1 being in the file, meaning it would propagate through our CICD pipeline without that value present and not automatically be activated in higher level environments.
Do you know if there is a way to prevent RELOAD = 1 from being removed from the CSP.ini?
Please note - I updated the article to highlight the new Usage Warnings in the Overview tab (nice work @Alexander Obolenskiy!)
Please provide feedback as to whether this is useful and how it could be more helpful!
Great course! I strongly recommend it for any Tier 1 sites using CCR if you haven't taken the training yet :)
The issue is that you need the logic to run synchronously in process so that it can actually write out the JavaScript as part of the response to the web client. If you job off the logic it will run in a separate process and there is no way to return the JavaScript to the caller because this is done asynchronously and the response has already been sent by the time your job will finish in all likelihood. If you need something to run asynchronously then use the #call() command in your CSP page.
thanks @Jeffrey Drumm!
@Pietro Montorfano - I suggest that if you haven't already done so that you subscribe to https://community.intersystems.com/tags/ccr so you see other CCR related posts in the future.
@Pietro Montorfano - VSCode use with CCR is definitely supported. You just need to make sure that your workspace is properly defined with isfs, etc to get you access to the files on the server. Since CCR uses server-side source control hooks, you can actually have people using Studio and VSCode concurrently against your BASE Environment.
We've tried to make it as easy as possible by allowing you to export the VSCode workspace definition directly from CCR (credit: @Timothy Leavitt ). Go to your Environment Details page and use the "Export (VSCode)" button on the top of your Environment list:.png)
Please try it and let us know if it works for you. P.S. would you mind adding the #ccr tag to your question so others can easily find it?
that is a very cool feature ... thanks!!
community edition will not have the PWS removed, in order to make it as easy as possible for people to kick the tires on IRIS
congrats!!!
... and we suceeded!!
"VSCodeTriageBot commented 5 hours ago
🙂 This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!"
can you please show your actual variable being set and then your command and its execution? as you can see from my example above, I was able to get DD for a single digit day with 09 yesterday.
agreed - which is why I always recommend forcing 4 digit years using yearopt with $zdate() :) Keep in mind that $zdate() preceeded Y2K which is why is has behavior that defaults to 2 years in certain circumstances (to keep the API calls backwards compatible).
Yup - that works. Great use of $ZStrip!
this would do mmddyyyy and not ddmmyyyy ... use 4 as your dformat instead (https://docs.intersystems.com/iris20232/csp/docbook/DocBook.UI.Page.cls…)
Please see details on the yearopt parameter for $zdate (https://docs.intersystems.com/iris20232/csp/docbook/DocBook.UI.Page.cls…) ... depending on the locale and on the year in question, if you don't specify yearopt you risk have a 2 digit year rather than a 4 digit year (default for my locale is yearopt = 0 which would show 20th century years as 2 digits). You probably want to specify a yearopt of 4 to force 4 digits all the time.
Amen to that!
Let's not stop here but keep going :)
Or, to make it work for any international locale:
USER>write $replace($ZDate($h,4,,4),##class(%SYS.NLS.Format).GetFormatItem("DateSeparator"),"")
09082023Something like this?
USER>write $replace($ZDate($h,4,,4),"/","") 09082023
Upvoted and you are up to 13!
10 days to go to the the last 7 needed for the 20 required upvotes.
Thank you for bringing this to our attention @John Murray!
sure helpful - thanks :)
I was thinking the same thing .. kudos for the screenshot :)
@Julius Kavay - I was thinking more about it and I think your point about moving tags to the head of articles is a very good one which can save people a lot of time by helping them more quickly see the context of the content. I have submitted the enhancement request here: https://ideas.intersystems.com/ideas/DPI-I-426
Feel free to upvote :)
Thank you for the feedback @Julius Kavay - I added a hyperlink to the first use of CCR for those that don't scroll down far enough to see the tags. I would however suggest that if an acronym is used 8 times in a post and it is tagged with an acronym of the same spelling, then the balance of probably makes it most probable that the acronym in the article has the same meaning as the acronym in the tag ;)
Thanks for the question @Julius Kavay - the #CCR tag indicates the context for this post: https://community.intersystems.com/tags/ccr
I was remiss in not recognizing @Alexander Obolenskiy who did all of the brilliant work to make this vision a reality!! Thank you Alex - this is going to be incredibly helpful to a large number of people!
@Dmitry Maslennikov - as GA is eminent the guys were set to expire post-GA, but Product Management decided that this really wasn't necessary so next time it will have a longer expiration even if GA is right around the corner. Thanks for raising the question!
that looks like a very cool idea :)
This probably has something to do with the security configuration in the SMP and how session sharing is working. Sounds like it's starting a new session every time. I suggest contacting InterSystems Support and they can help you debug the situation. This definitely should not be the behavior and would certainly be quite disruptive to anyone's workflow!
Thank you!