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.
Related
We have SharePoint Online site with list. Users can add, edit and delete own items in this list.
How I can resolve new issue - Users can't edit and delete own items older than one week (from creation date).
Is it possible without coding Remote Event Reciever or Azure function?
Per my knowledge, there is not an OOTB way to achieve it, we have to write some custom code.
If you only want to the user can't see some items in list view base on some condition, we can use list view Filter to achieve it. Note:User also access item form through URL.
I suggest you use remote event receiver or azure function to achieve this requirement.
In classic site, we can also add some JavaScript code into master page to prevent users access edit form page and hide the delete button in the page.
For this kind of requirement the solution which is 'no code' and with SP online is Power automate (previously MS Flow).
The best option in Your case would be to create a recurring flow which for example starts every day at 00:10 AM -> please see MS docs with description how to do this.
The Flow should get all items from a specific list for a specific site. You can do that with the 'Get Items' step. After that You can use the 'Apply to each' Step to check each item creation date with a 'Condition' Step. When some item will be older than one week You can use additional steps to break permission inheritance on item and remove all groups from permissions on this item or change the permissions on item from edit to read. Here I found an interesting article where are some predefined steps shown how to remove all permissions, remove and add a group. To tell You the truth I was not aware there already are this kind of steps in Power automate (maybe something new :) ) .
I would use SharePoint HTTP request and use SharePoint API to remove permissions on item and change some group role from edit to read. So I would do a similar procedure like here the only difference is not to break permission on all list but just on a specific item which I would get by ID. You can do all of those API request with a 'SharePoint HTTP request' Step
Please be aware there usually is a 5 000 unique permission levels threshold (50 000 is in on-prem) in list (place check here for latest info on limits in SP Online). So a better option would be to create a folder with view only permissions for the users before and when an item is older than one week You could only move this item to that folder also with Power Automate. That way all the files (items) in this folder would be read only and You would have only one unique item scope in this list and not as many as the old items.
Some other options You could use are:
Also code solution, but not RER and Azure function, would be to create a console app that uses CSOM to look through items in this list and either breaks permission on each item or moves to a folder (like the flow) and schedule this CSOM app on some local or remote server in Task Scheduler... Of Course You would need some local (or other) server for it which is always up and running :)
If You would like to use some 'little coding' and by any chance You are still using classic UI (not modern) You could use JSLink attached to CT or some column like Title and block editing of fields in edit forms etc (this is not the best option as always the users may create a view without a columns with this JSLink and go around this or modify the item using CSOM or Rest API)
You might consider using PowerApps (In case you have it configured in your subscription) to customize the edit form,
Then you use the validate() method, and disable a user from submitting the form in case ("Created" + 7 days) <= Today() or something like that.
I want to trigger a NetSuite workflow when the user sets the value of a field, but I don't want to have them submit first. The Workflow state builder looks like it has useful options but I can't get it to work.
There's some useful looking blog posts around but a lot of them seem out of date.
Update - more info
My primary issue is this one: Restrict what customers an employee can see (NetSuite)
The hack I'm currently looking at is populating a custom Transaction Column Field that I've added to a custom Time Recording form. The idea is to load this field on the UI with only valid projects (not customers as well), and this I have been able to do.
The problem is I still (as far as I can tell) still need to populate the "Customer" field, which is mandatory; I'm also assuming that if I don't do that then any time that is recorded won't go against the project. I had thought that if the user selects the project they want then I can populate the customer field with that value. I hate this as an approach but I can't see how else to do it. I do have coding experience (including JavaScript) but haven't made the leap into SuiteScript yet.
You won't be able to do this in a Workflow, as they are currently limited to only work with body level fields and cannot modify Transaction Column Fields (aka sublists).
You should be able to achieve this with a Client Side Script though.
Source (Netsuite login required).
Sublist changes will be available for transactions in the 2018.1 release sometime in Feb/Mar.
Is it possible to validate the Xpage's ACL depending on the Source document's field value.
We need to make the Authors & Readers ability at XPage level (as per requirement I am not supposed to use the ROLES, since, it is dependent on each individual Authors which is stored in backend document FIELD).
Kindly suggest the approach, as I am not even looking HideWhen for the Buttons(edit,save etc)
Example code in the ACLEntry[0] in Xpage:
if getComponent("inputText1").getValue() == sessionScope.user {
session.getEffectiveUserName();
} else {
return false;
}
Thanks.
I do not quite understand your code on that property...
To query the readers/authors level at XPage level I suggest to use the database.queryAccess method (http://www-10.lotus.com/ldd/ddwiki.nsf/dx/NotesDatabase_sample_JavaScript_code_for_XPages?opendocument&comments#queryAccess)
You try to compare the username only. This may fail if your access level is computed by a membership in a group where your username is not relevant.
XPages' ACL depends on the database ACL, so you have to setup the levels there - the XPages' ACL is in addition to the "real" ACL as far as I experienced.
I also experienced that readers fields affect the ability to use an XPage to open a document by default.
I hope my answer is not too confusing ;-)
I think the question is valid (to my current knowledge):
If I want to design a workflow application but the current approver should not edit the full document I want to give him only access to parts (ie. a comment field and the approval button).
The question above relateds somehow to access controlled sections in old LN development. I so far also didn't find a good solution
What you describe is a very common workflow scenario. There are several ways how you can implement that efficiently. Here is what I would do:
Have one (or more) custom controls that render the "payload" (the fields the requester fills in)
assemble them into one bigger control that is used to render the form
compute the mode to read/edit depending on who is opening the form and the mode (new, pending approval, approved, rejected etc.)
Optional: when submitted remove submitter from the author field
Have one "Approval Control" that show only when the current user is the (current) approver and status is "pending approval" That control has fields that are NOT bound to the document, but a scope variable
The approval button triggers SSJS that takes the scope variable values and updates the document (and triggers notifications, access change etc)
The approval component can be used for any approval form. You then can contemplate not to give the approver write access since you could handle that in code.
How do I create an activity feed rule that writes an auto post on the Record Wall of a case when an email is automatically assigned (made Regarding) to that case because of its tracking token?
Our users are having trouble realising that there is something new to look at in the case and this would go a long way to preventing them from missing an important event.
EDIT:
These solutions have already been considered
They don't want follow up tasks.
The email is already displayed in a grid on the case
They don't want more Queues to check.
They don't want more emails to deal with.
This user is recalcitrant to say the least...they only want a note to appear on the record wall of the case.
To accomplish this with little/no coding, you could:
1) create a task or other activity that would show up on the activity feed. This is easily accomplished via workflow.
2) display the email/other activities in a grid on the case.
3) also set up queues to handle this.
4) send an email to the owner of the case when an activity gets appended to it.
There are a lot of options to resolve the issue of notifying users that their case has additional info.
EDIT:
Your comments are accurate and well received. Can't you do something as simple as create a workflow that will create a post when an email is created and/or when set regarding field changes. Then you can check within the workflow that the set regarding is for a case or else cancel the workflow. Within the post record, set the type to auto and the regarding to the same regarding as the email. (I was unable to get the record wall part working in my local VM, so I assumed that any post record regarding the case should show up in the case, but I couldn't test that).
I've just started to look workflows in 2010 which seem pretty good but I can't find seem to find out how do something very simple.
Basically I'm creating a lost property list and workflow, essentially anyone can add a new item to the list for an item that they've found. Next anyone can make a claim on an item in the list which should then email the admins where they can investigate and close claim if the rightful owner has claimed their item.
Should be very simple and would take me no time in .net but not in SharePoint! Any suggestions on how I could do this?
I've been looking at SPD workflow tasks and not really getting anywhere. My next step is to go into VS2010 but this seems overkill for such an easy task.
Thanks
Dan
what is your intention to allow someone to "claim?" are you intending to enable a "claim" as just a flag and a workflow sending emails to the admins?
Create a Yes/No field Claimed with the default value set to false.
Create a SPD Workflow that would start OnItem Create.
In this workflow add an Action that waits till the Claimed Flag is set to true.
Then you can send the email to the administrator (also with an SPD activity).
Optionally you can delete this item from the list after a period of time.
Based on my understanding of your question and the fact that we tried something similar a while back, I have created a blog (my first blog entry!). Below is the link, feel free to leave comments;
http://sp10tech.blogspot.com/2010/10/creating-simple-workflow-using.html
Alternate Idea;
Maybe use two lists. One for items lost and one for claims. This way you can have multiple claims on each lost item. Add a field that references the claims list so the user can select it. Then simply have the administrators use a out of the box alert mechanism. No need for elaborate work flow.