I tried to pass false but it doesn't seem to do anything. In any regards what I was really looking for was to unread / unseen. At this point it was mostly for testing purposes but I could see this becoming a feature in our system.
mark_read Comma separated list of activity ids to mark as read, or boolean true
mark_seen Comma separated list of activity ids to mark as seen, or boolean true
$results = $notification_feed->getActivities(0, 10, $options);
Marking activities as unread or unseen is currently not supported by Stream's latest API (v1.0)
Related
Sorry this isn't a specific coding question, it is more of a design concept.
What is the usage case for programmatically adding and removing fields to Notes Forms e.g. NotesDocument.RemoveItem(), ie why would you add and remove fields in the background?
For many years I have designed my forms with the fields layed out on the form which are required and then hide and show as required.
By adding dynamically you can't position them and frustratingly removing them or deleting they still appear the Database Fields in Domino Designer, getting rid of them is a bit a a black art, but that's another story.
I must be missing a trick or a basic design concept. Any thoughts on best practice would be appreciated.
Many thanks.
Yes, you are missing the difference between "Fields" and "Items". A field is a design element that you can place anywhere on your form. You define how it looks, what content it contains, what datatype it is, etc.
When creating a document with the form the value of the FIELD is stored in an ITEM in the resulting NotesDocument.
This item is totally decoupled from the field that created it. If you were to change the field in the form from text to number or move it around or make a names- field of it, the item in the existing documents would never change unless you open the documents and save them in frontend or use any LotusScript or Formula Code to recalculate the document in backend.
Very often items are added programmatically to documents to fulfill different purposes: Calculate values to be displayed in views, calculate values that are import for the workflow but not for the user, etc.
Complex applications often consist of a lot more items than there are fields in the several forms.
Back to your question: Removing an item from a document simply removes the value that was created by the field in the form. When reopening the document, the item will be repopulated, either by default value or whatever....
Usually you would use this to remove items that you no longer need (and probably already removed from the form).
As soon as you removed all references to a field / item everywhere in design and documents, you can finally get rid of it completely by compacting the database.
An item is distinct from a field in Notes. The form is purely a UI concept, the item is what the data is stored in.
Manipulating data in the backend can be used for a number of reasons. One such use case is the setting of a flag when a date on the form has expired.
Say you want a view showing all documents that have expired. Your rules dictate that documents are considered as "Expired" after 7 days. You could create a view with a formula that shows all document whose date is 7 days older than today:
SELECT Date < #Adjust(#Today; 0; 0; -7; 0; 0; 0);
This view will ALWAYS be out of date and will constantly be updated by the server as it re-evaluates #Today.
Now, a better way would be to create an agent that runs daily that sets an item on the document to indicate that it has expired e.g.
#SetField("Expired"; 1);
The view formula would then be
SELECT Expired = 1
The view would only need to update daily and you have a much faster view because of it.
RemoveItem is used to get rid of data no longer needed e.g. FaxNumber.
There are many use cases for RemoveItem. Here's one that comes up frequently.
You have a database and an agent that processes documents in that database. Every time it runs, the agent replaces the value of a bunch of items. There are a variety of error conditions that can cause it to abort processing a document early, but you're a smart programmer and you've accounted for that with on error traps. When you hit one, you log an error message, save your document, and then either abort your agent or go on to processing the next document.
But at this point, some of the items that the agent normally updates have values saved from this run, and some of them have values saved from a previous run. This might be bad. This might be confusing for someone who is looking at the item values and trying to figure out what's going on. This might even cause validation errors on the form.
So how do you avoid this? At the very beginning of your agent, you call a cleanup sub that finds and removes all the items that the agent is going to update. Now you have a clean slate, and if your agent hits that error condition, it can save whatever it can save without any concern about whether it is leaving things in an inconsistent state. Of course, in cases where you are doing this to avoid validation errors, your validation formulas will have to be smart enough to be checking #IsAvailable for dependent items, but that's a good practice anyhow.
I'm conducting a lucky draw to encourage colleagues to post on Yammer, and I want to do the following:
Colleague posts message on Yammer
Pull a Lucky Draw Participation code from SharePoint List
Send colleague an automated message with this Lucky Draw Participation code.
There are only 100 codes, and for obvious reasons, are single-use and cannot be easily reverse-engineered. So I have crafted them in advance by hand.
My question now is... what are the functions I can use can to set up a Flow, that plucks a code from a Sharepoint list (never re-uses it as well), and that this flow would cease after 100 times (i.e. all codes used up)
Thanks!
(Following is the screenshot where I was stuck at...)
Currently stuck here in MS Flow
One example:
First, add a flag to your SharePoint list that indicates the code (row) has been used, e.g., Yes/No field named "Used."
Use Get Items action that uses the ODATA filter query "Used ne 1" without quotes. That will only pull codes that have not been marked as used.
Set Top Count to 1. Only the next unused item will be retrieved.
Use Update Item action to mark that code as Used.
Use the output of the Get Items action however you see fit.
Note: You can also add a condition to send you a message that all codes have been used if the length of the output for the Get Items action is 0.
We are building Feed Groups similar to Facebook Groups and we want admin and moderator functionalities to be implemented. How can we implement such functionality?
Presently, we thought of two ways,
1) Have a separate feed group UnApprovedFeed for unapproved posts and once the feed from UnApprovedFeed gets approved, it gets deleted from UnApprovedFeed and gets published to Normal FeedGroup,
2) Have an extra boolean object Approved to the activity, and filter based upon it, If approved the boolean is true else false.
Or is there any available abstraction for moderators already in Stream?
both of your ideas will work, but the second option is what we've seen most frequently (and what we've done ourselves in a few projects our services team have done for customers). You can have your front end query that field and just not display.
I would like to add training phrases like
Yes
I would love to
No
No, thanks
and extract a boolean var $extraCheese containing True or False which I can use later. If I was expecting a color, I would do $dressColor and #sys.color, but then I don't find #sys.boolean
How do I do this?
It is, indeed, baffling that Dialogflow doesn't offer this natively. They offer this as an option for a Followup Intent, if that is suitable for you, but not as a System Entity.
Fortunately, it is fairly easy for you to make a Boolean Entity yourself.
Click on the + sign next to the Entity menu option on the left.
Set the name for the Entity: such as Boolean.
Add the value for an entity (true for example) which is the text value your webhook will be sent. You then also add aliases for that value. This needs to include the value itelf (true, again), but also anything else the user might say to represent this value (yes, sure, etc).
Then repeat this for other values you may want.
When you're done, you can click Save and then use this entity in your sample phrases just like the built-in entities.
I went through all tutorials and docs which stream-django provided.
And there was one thing that I could't understand.
I can't find the differences between these feed_manager methods.
# (1)
feed = feed_manager.get_news_feed('timeline', request.id)
# (2)
feed = feed_manager.get_news_feed(request.id)['timeline']
# (3)
feed = feed_manager.get_news_feed(request.id)
Could you explain the difference? Are they doing exactly same thing? timeline means flat feed, then why do we put timeline in param?
Thank you
timeline is the name of the feed group that you've created within Stream.
Once you create a feed group in Stream, you'll select the type of feed group ("flat" in this case, but can also be "aggregated" or "notification"), then, you'll name the feed group - common names are timeline/news_feed (a homepage feed showing activity from other users) or profile/user (a profile page feed showing all activities from a single user). There are no "reserved" words in feed group names.
Re: whether or not these methods are all doing the same thing:
feed_manager.get_news_feed('timeline', request.id) (1) is definitely correct. It'll fetch the feed activities for the specific timeline:1234 feed, where 1234 is most likely your user's ID.
(2) and (3) I'm not sure about - it's likely that they're doing the same thing as (1), but I'm not able to tell at the first glance at the docs.
Hopefully that helps!