I have a bot in Botframework Composer and maintain a user state in the user memory. I need to clear the user state. Unfortunately, I am unaware of a way to wipe the user memory as a whole so I have had to resort to deleting individual properties. This works fine but does not work with structured objects. So for example, if I have a property (for example)
user.options.color
user.options.font
user.options.size (etc)
If you use Composer "delete property" to delete user.options, nothing happens, it remains in the user state. One can go in and delete individual properties (user.options.color, etc) but I don't see a way to delete the entire structure of user.options
Any suggestions?
Related
I am developing a plugin that allows the user the post content that I am storing in an object in publicData. To identify the user that posted the data, I am storing the _id that is returned from buildfire.auth.getCurrentUser() in that publicData object along with the content of the post.
Is there a way I can access a list of the users of my plugin, then iterate through that to find the user with the corresponding _id? A list of the users of my plugin must exist somewhere, I just do not know how to/if I can access it.
Any help on this would be greatly appreciated!
I would recommend caching the user object's nonsensitive data. Remember, you have a bit more access to the logged-in user over fetching another user profile using the user id. https://github.com/BuildFire/sdk/wiki/How-to-use-Auth#buildfireauth-getuserprofileoptionscallback
Since the user profile picture URL is really an API, you don't have to worry about the user changing it since it will always return the latest. The other property I recommend you cache is the Display name (not the first name and last name) since that rarely changes as well. This way your performance wont suffer and you can do a lazy fetch for a distinct list of user ids an update them as needed. KNowing most wont need an UI updates since nothing changed
I have a Notes application that is used offline on a local replica most of the time.
Users can create and update documents.
On the server, an agent processes all new documents.
The idea is that - once the agent processed the documents - the users are no longer allowed to update the documents.
In general, this is quite simple to setup by setting author access on the documents processed by the agent.
But, because users work on the local replica and the agent runs on the server, this scenario is possible:
user creates document offline
replication of document (creating of doc on server)
agent runs on server / user updates document locally
replication of document (updating author access locally / updating changes on server) ==> Causes save conflict or inconsistent data
Is there a way to make sure that the user can no longer update a document once it is replicated to the server.
Or is there a way to force the agent to run on replication and immediately replicate the access update?
I was thinking of creating a button the user can click to replicate/update all documents, but to avoid users that forget to click the button, I prefer the default replication settings to make sure everything is replicated when possible.
When I investigated a few years ago replication does a "pull", then a "push", so doing something on the server won't work. There are a couple of options.
A separate "flag" document which server processing updates, instead of updating the actual document. This would allow for updates causing a second set of processing.
Store a config document / environment variable with the last replicated date, and check against that in the Form's queryModeChange and queryOpen (if editMode). You can then prevent editing if the document was created before the last replicated date.
Instead of using Author fields for the "wrong" reason, I'd add a non-editable Status field, with values like "Initial", "Ready", and all the rest you might need. Then, replication should be set up differently, using a formula that only replicates documents with Status!="Initial". The user might have 2 buttons to save a document: one just saves to the local database and the other also changes the status to Ready. Once Status="Ready", the user can no longer modify the document.
By the way, did you set document replication to "Merge conflicts"? You might reduce the number of conflicts considerably.
One alternative would be to set up the form so that the user never actually saves the document locally. Instead, the document is emailed to the server where an agent triggered by mail delivery performs the actual update. When the agent is done with the update, it sends an email back to the user telling him/her that the updates are available and instructing them to replicate in order to retrieve them. If the Notes client is actually being used for email, you can probably even put a button into the email and say "Click here to replicate and open your document".
I have a mobile app using Couchbase lite. When the user logouts, I want to remove some of the documents on the device; the user-specific documents. I do not want to remove all of the documents. Documents have a purgeDocument() method that I thought I could call on those user-specific documents.
The problem is that the purged documents are not re-synced down to the device if the user logs back in and a pull replication is run.
Based on the little I know of CouchDB sync protocol, it makes sense that those are not re-synced down because there are not newer Sequence updates on those user-specific documents to trigger a re-sync.
How should I approach this problem?
Possibilities
Delete the whole database (including common documents) and lose performance.
Somehow reset the last sequence for the replicator and hope the replicator does not transfer the already-downloaded docs over the wire. (Probably would screw up CBL)
Have separate databases, one that stores the user-specific docs and one that contains common docs. Databases can have filtered replicators (by channel) so it would be feasible to partition the incoming data into separate databases. The problem would be the seamless reference loading between documents of differing databases when using CBLModel objects wrappers.
As i understand from the official documentation in the subsection Purging documents, you are not retrieving the document again just because it has not been modified/updated (in short, its rev is the same) on the server side.
You can try to create again a dummy document with the same type and, for example, username (or whatever you are using to identify the user's configuration) when the user logs again in your app so that you trigger the pull replication from the server. You probably will have a conflict that can easily be solved taking the revision from the server.
I hope this idea helps a little.
UPDATE AFTER COMMENT
The idea is to store somewhere the id and type of the user's documents you're going to purge. That way you can create a new dummy document with those two fields when the user logs in again. Perhaps this new dummy document triggers the pull replication.
NOTE: I haven't tried this method. I am just guessing what it might be a work around to your problem.
I would suggest that your backend modifies the selected documents - this could be just a timestamp update - upon user login, which will post the new revisions to the device
You can keep purging the documents when the user logs in.
To solve problem of re-syncing specific document, I think the easiest way is to use filtered replication where the filter is document id.
These document IDs can be created in a manner which can be derived. For example it can be as UserDocument::.
Now when the user logs in you can start one shot replication with document ID as filter. This can only be done in one shot. And when this One Shot finishes you can start replication again by changing the setting of the replication(changing filter/channel).
following is the URL by Couchbase which explains filtered replication by document ID.
https://developer.couchbase.com/documentation/mobile/1.4/guides/couchbase-lite/native-api/replication/index.html#filtering-by-document-ids
Try Push after Purging the document with Couchbase Lite which allows you to Pull the document from the server at a later point.
I have an HTML web resource on a CRM 2011 form that users will be entering data into. This data will be required by CRM create/update plugins if the user chooses to save the main form, but there is no functional requirement that the data needs to be saved to any field on the entity. I am considering a hidden dummy field that the data could be saved to, but am wondering if there is anything more elegant for persisting data from the client to server technologies. I've done some research on "sharedvariables" but haven't been able to determine if they might meet this need. Any example of setting a value using JavaScript and then retrieving it from a plugin would be valuable.
Edit: I just wanted to clarify the response that I received based on my testing. While CRM has "SharedVariables" available for both plugin and scripting use, any data saved in scripts will not be available to plugins. Data saved by one javascript function to "SharedVariables" will be available to other javascript functions registered for the same event, and data saved by a plugin is available to other plugins registered for the same event, but the data is not persisted from script to plugins or vise-versa. This leaves dummy fields as the only option for persisting data from javascript to plugins. As NickNow suggested, unless you need to persist the data to a database, deleting it on a pre-plugin would be a good idea. Thanks Nicknow!
The hidden/dummy field is the correct approach. SharedVariables don't exist, from the standpoint of a plugin, until the data is sent to the server.
The form save is just a UI to trigger the Create or Update event - from the platform's standpoint you are just sending an entity logical name, the record guid (for an update), and the fields/values. The plugin has no knowledge, and shouldn't require knowledge, of how the event was triggered.
What I do is create a field (such as `new_internalmessaging') as a text field (since I'll never persist the value to the database I just make it a 2000 character string). During a JavaScript OnSave event I grab whatever data I need into an object and create a JSON string which I then use to populate the field.
In my Pre-Create and Pre-Update plugins I retrieve the string and deserialize it to an object for use in my plugin (I can also place it into a SharedVariable at this point if I need it for a post plugin). At this point the plugin code should remove new_internalmessaging from the Target.
I do this to ensure the data in that field will never get persisted to CRM.
there are many standard objects e.g. AccountcontactRole, LetterHead, Approval etc. which can be retrieved using Salesforce APIs. What is the way to see these objects in Salesforce environment in browser?
Very roughly speaking - easiest cheat is to simply put the Id in the URL. So if your Salesforce instance is https://na1.salesforce.com then adding /001.... (any valid Account Id) will take you to this account. Similarly /016... will take you to "this" Letterhead record.
Some data is easily accessible to users - for example AccountContactRole should be available as related list under Account. If it isn't - probably the administrator removed it from page layout because the company decided to use only the straightforward Account - Contact relationship.
Some data like Letterheads, EmailTemplates, Approval processes is visible in the setup area (not all users have the "View Setup and Configuration" permission in their Profiles!)
*Share records (like AccountShare) would be visible after you click the Sharing button on the page layout (if it's not visible - again, check with Admin).
If you're using API to fetch the data, you probably can also use "describe" calls to fetch info which objects are available, what fields are present in the tables... Sometimes the "Frontdoor URLs" property is set (although I confess I'm not sure how to get it, http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_Schema_DescribeSObjectResult_instance_methods.htm doesn't mention it).
Also - if you haven't noticed yet - all Accounts start with "001". Try to guess where "/001" and "/001/o" links would lead.