Is there a way, while configuring recast bot, to set an action to reset all memory, except a specific field?
I already tried to unset all fields except the one I need, but it's boring, unextendable, unscalable and unmaintenable.
Thanks
You should ask it on Recast.ai 's GitHub issues. Most of the time they respond within 24h.
currently there is no way to unset all memory expect one specific field from the Builder but through the API you can send a new memory object with only the field you want to keep and this will erase the current memory - you can do this using a webhook call that has only this purpose.
Related
I'm starting to integrate PayPal checkouts with a server workflow.
My basic need is to create an order on the server and ensure that the client can not modify it in any way.
Because of this requirement, I have already ruled out using the "simple" JavaScript-only solution, and I'm instead going for a server integration, calling my own URL endpoints for creating and capturing orders.
However, I have found that the client can just ab-use the actions.order.patch() method to modify almost every aspect of the order, including the amount and the custom_id that I'm attaching to the purchase_item.
Basically, It looks like I have absolutely no guarantee on the order contents, even if I created it on the server, is this correct?
In that case, it means I have to check each order's contents against the orders database of my application. It is possible, but I was hoping to not have to do that.
Any clues? How do you deal with this issue?
Thanks!
If you are particularly concerned about this scenario of patching down the total or other details before capture, the only way to ensure it has not changed is to do a server-side ‘get details’ call before the capture and at least validate the total amount value, as well as any other field you’re concerned about.
Otherwise, the usual general safety solution in ecommerce (for this as well as other potential issues that might crop up) is to simply capture and validate the total in the capture response. If the capture has a total you don't expect, issue an immediate refund or flag the occurrence for review before fulfilling anything.
Event stores are supposed to be Add only, you never delete or edit data.
In my case, we didn't disallow some mid-stream changes that were made by a user, and the data is "bad" / inconsistent... in that they changed a domain name for google docs that we were provisioning mid-stream...
I can reprovision from the event store, but that data is broken.
Should I create a mutator of some kind that as it pulls the data from the event store, fix it up?
I need some ideas here!
If I understand you correctly, the "bad" data were correct back then?
I suggest you fix this by not touching the events, but update the provisioning service to handle the broken domain names. That could be a component which knows how to fix a domain name or a url: You send a resource in and get a corrected version in return. Unknown resources could be returned as is.
Is it possible to programmatically create a new version of a CQ5 page that has a start time some time in the future?
As an example, let's say we have a page that displays tax rates. We have a component that allows the author to upload a new rates table (in the form of a css file) and it creates the rates page content. We would like to allow the author to upload rates that will be effective the first of next month.
I know the jcr supports multiple versions of nodes, but its unclear how (or whether) this relates to cq5 page versioning. And, further, whether a new version can be activated in the future.
Given the requirements as you've described them, I would probably accomplish the task in a slightly different way...
Instead of storing my rates table information directly within the page's jcr:content node (or a sub node their of) I'd probably abstract it out to somewhere else in the repository. You could then, if you so desired, create some sort of an admin interface to allow content authors to upload their csv file of new rates, and ingest that into the repository as needed. Alternatively, assuming that data comes from some sort of a database, you could probably just write a job to automatically injest it on some sort of a scheduled basis by using a JDBC connection from CQ. Once the data is in the repository, you could then write the display component to read the data from the repository, instead of it being directly inside the page.
This approach has the advantage of making that data re-useable within CQ to be shown on multiple pages, multiple sites, even many different display formats if need be. In addition, you can design your jcr structure to support whatever requirement you have around updates to the data, including daily, monthly, weekly, yearly etc., obviously this will depend on the specific requirements.
The one downside to this is that since there is a separation b/w the data and the page(s) where it is displayed, you may need to find a way to ensure the cache is properly cleared whenever the data does change.
Update (based on your comment):
The problem I foresee with versioning the page, and granted I've not tried this so maybe it will work, is that there can only ever be one active version at a time. Therefore, once the next months data is uploaded, you need to maintain the old data (active) and the new data (not yet active) at the same time. What happens if you require a separate content change during that window...from a business process perspective that just seems messy to me.
Back to cache clear issues, If you know the affected pages, especially if they are all in one subtree, you could write a custom workflow process that uses the replicator service to clear the cache for the affected pages, then set up a launcher to run the wf on node change for the data.
The other option, and this one is less defined in my head, so some experimentation required, would be to use CQs built in activate later and de-activate later functionality.
Maybe create a specific template for the rates data, with the implicit requirement that only one page using that template is ever active at one time. Your display components could use a query to find the currently active rates data.
I have not personally tried this, but...
I assume that you can use the PageManager service's createRevision method, and then if that returns without throwing an exception, you may call page.getContentResource.adaptTo(Node.class), and from there take the node that is returned and edit the JCR properties for your tax rates component.
See PageManager
You could write a workflow that includes a publish step that is triggered by the arrival of a calendar date. The version of the page with the new tax rates remains in the workflow pipeline in draft form and is only published/activated when the date arrives. (So you'd need some sort of process that wakes up once a day to check the calendar.)
Each time a page is modified cq creates a version of the page.
This modified page's modification time is set in jcr:lastModified property of the page.
Manipulation of this property can be done to save future date and activate page on that date though its not preferred way.
You can store the future date as a property in the page.
Later as suggested by #David you can create a workflow or a scheduled job which activates pages with a future date.
I am currently drafting a concept for a (mostly) HTML-based collaboration suite which I plan to implement using CQRS. This software will contain messages that can be sent to the user (which can either be read or unread, obviously) and other elements which shall be marked "new" if they were created after the last user login.
Hardly something new, but I am not quite sure how that would be correctly implemented using CQRS. As I understand it, Change of any kind should, without exception, only be possible via Commands. But creating commands for every single (new) element that is being accessed seems a bit too much, not to mention the overhead.
I don't know if I need it, but what would be the best way to implement a Last-Accessed Timestamp on elements. Basically the same problem like the above, with the difference that the change happens EVERY time the element is accessed, not only the first time for each user.
CQRS seems to be an awesome concept but it really needs more learning material. Can't wait till a book is released :)
Regards
[Edit] No one? Wouldn't have thought that this is such a complicated issue..
I assume you're using event-sourcing in which case once you allow your query-service/event-handlers to raise appropriate events then this becomes fairly easy to solve.
For your messages/elements; when handling the specific creation events of your elements either add to existing or create additional event-handlers, to store to a messages read-model with a status of new and appropriate information about the element.
As part of you're user login I don't see why you can't raise a user-logged-in event (from the security/query service depending on how your implementing authentication) to say the user has logged in. An event-handler could capture this and write the last-login timestamp to a specific user-last-login read-model.
In addition the user-logged-in event-handler would need to update all the new messages (for that user) to an unread status. Seeing as we're changing the status of the messages as the user logs in do you still need to store the last-login timestamp?
For your last-accessed timestamp, perhaps you could just work this into your query service as queries for your different elements complete. Raise a query-completed event with element id/type information.
I'd like to make some drastic changes to my iOS app, but I don't want those changes to affect existing installs, since it may cause existing users to complain. How can I limit the new functionality to new installs only?
One easy way would be to set a global flag at a point in the code that only occurs before the user completes the tutorial, then if that flag is set, use the new code. Other, more elegant solutions?
Thanks so much for your wisdom!
I'll set aside whether you should do this. Other answerers have said what I have to say about that.
Technically how you'd do this is by looking for any data that persists when a user updates the app. So, any NSUserDefaults values you've set, anything you've written to the app's sandbox, keychain values... Any hint you've been here before, and you set yourself a userDefaults flag to only show old stuff. Otherwise, set yourself a flag to only show new stuff.
If you want 2 different app behaviors, you can just submit a new different app to the App store. Apple may or may not like "hidden" behaviors that they can't find during review.
the most elegant solution that I can think of is letting the user choose.
if your changes are so well delimited that you can use a flag (like you say in your question) to decide which code you run, I would add a setting useNewUI which is by default YES unless you detect the app was already installed (read further for more details about this). Then the user can go to the settings (you might also ask them) and decide and at any moment change.
You could decide whether your user is a new or an old one by checking whatever data you are storing in NSUserDefaults. At the start of the program, you check, if data is there, then you add useNewUI to NSUserDefault with a value of NO, otherwise you add it with value YES.
This approach could based on NSUserDefault could be useful to you even if you disregard the possibility of letting the user choose through a setting.
If the app is radically different, then make a new app. Otherwise, anyone who updates will get the new one.
Some existing users may want to have the new one, some may want the old one. This gives everyone the choice.
You can't. Once you submit an update, all of your users can download it and will have the new feature. If the update is going to annoy your existing customers, it will probably annoy your new users too.