I have a list of initiatives (proposals) which have an originating team and impacting team.
For e.g.
There are leads for each of these teams and yes the impacted teams data is a continuous string of teams.
Originating team will be part of impacted teams too.
Given that there is a mapping between Originating teams and leads, I have created a user filter such that Leads only see the initiatives originating from their teams. That was pretty straightforward. User filter on Originating teams and mapped the users to the teams.
Now the ask is, they also want to see the initiatives that impact them.
For e.g. The Product lead also want to see the Initiative 2 where they are impacted.
How do I go about creating this complex user filter?
Related
I am using Frappe framework. I would like to share same data that is collected from Sign up to POS profile but keeping in mind that both of them located on different servers. Any advice?
You can use Event Streaming.
Event Streaming enables inter site communications between two or more
sites. You can subscribe to Document Types and stream Documents
between different sites.
For Example: Consider you have more than one Company hosted on
different sites, one among them is the main site where you want to do
ledger posting and on other sites, the Sales Invoices are generated.
You can use Event Streaming in this case. For this, your child company
sites can subscribe to the main company site for Item, Customer, and
Supplier Document Types. The main Company in turn can subscribe to the
child companies for Sales Invoices.
Source: https://docs.erpnext.com/docs/v13/user/manual/en/automation/event_streaming
I have been trawling the internet and clicking myself blue in the face! Hopefully someone has a definitive answer.
I want to have one Group (in either of Azure AD, Microsoft Teams or Azure DevOps). This group must have access to a DevOps project and a Team site. When I change the membership of the group, the membership must change for both the Team and the DevOps project. I want to avoid the overhead of managing the groups for both separately.
Is this at all possible? Thanks.
This is a really good question, and the answer is not obvious at all. Ironically we had the same exact problem in Microsoft Teams - when a user was added or deleted from the underlying Office 365 Group (which is mastered in Azure AD), it would take up to an hour, sometimes more, to be reflected in Teams, which has its own copy of the member list.
There is a way to do it, and it's how Teams does it: it relies on a relatively new feature in Microsoft Graph called subscriptions. You can find the documentation for it here: https://learn.microsoft.com/en-us/graph/api/resources/subscription?view=graph-rest-1.0.
Essentially what you want to do is create a subscription to the group: POST https://graph.microsoft.com/v1.0/subscriptions with the right message body and your endpoint will be called whenever there's a membership change in the group. Your endpoint won't know what changed, just the event and some IDs - you will likely have to make a separate call to retrieve the actual data (unless the IDs alone are sufficient).
There's a sample on GitHub that illustrates how to use Microsoft Graph subscriptions including more details on how to subscribe to group notifications specifically.
One thing to be aware of is that to use these APIs, your application will require fairly elevated permissions: Group.Read.All which means it has the ability to read not only the team/group members, but all of its messages too (among other things), for every group in your Office 365 tenant. We are working with the MS Graph team to support a less-privileged, per-group permission approach, but even after that's released for Teams Graph APIs, support for that will have to be added to the subscriptions APIs I just mentioned and that may not happen for a while.
I am working on system that will manage orders. Orders can be created via admin or via customer. Employee can take orders and change it's status.
My system should have three global types of users:
Admin - this type of users mostly uses WEB interface. Admins have different access levels, so some of them can only create orders, and others - edit core info about pricing and so on.
Customer - this type of users uses customer's mobile app. Main action is to add and cancel orders.
Employee - this type of users uses employee's mobile app. Employees can see open orders, assign themselves to orders and change order statuses.
Also, Customer and Employee can be authorised with phone number, that can be changed at some time (independently of each other). Admins can be authorised with uname + pword.
Current solution has one table for Admins, one for Customers and one for Employees.
So first part of question is how to structure database properly?
The second part is about authorising in REST api. In current solution I have three endpoints, that are authireses usertype independently.
admins/auth
customers/auth
employees/auth
And my thoughts is to keep three tables as is, because each usertype is slightly different concept and really independent. And keep authorisation as is, but add something like roles and privileges to auth token to restrict access for some resources.
I am trying to run a workflow on the creation of a 1:n relationship.
I have a Contact entity, and PortalRole entity. When I associate the PortalRole with the contact I would like to trigger a workflow which sends out welcome emails to the users.
The PortalRoles are assigned to the contacts from a ribbon button which launches a HTML web resource and uses JSON / JQuery and the REST services to create the associations.
How can I call the workflow? I need to grab the Contacts email address and send them 1 of 2 emails depending on how many associations they have (new portal user or portal user gaining extra roles)
You should build your workflow for the PortalRole entity and trigger it from Create. You'll still be able to access Contact fields in the workflow.
The trick is in your last requirement - send "Email A" for the first role association and then "Email B" for the each additional association.
You could add a Yes/No field to Contact called "First Role Assigned." Your workflow would look something like this:
If Contact:FirstRoleAssigned = Yes
Send "Email B"
Else
Send "Email A"
Set Contact:FirstRoleAssigned = Yes
This blog post provides a very good explanation of dealing with relationships.
(So Many) Many-to-Many Options: Which to Use?
So…of these three approaches, which is best? As always, it depends on
what you need to do, but here are some rules of thumb you can use as
guidance:
Native N:N
Probably the easiest to configure but the most limiting. Use when you
only need to know that two records are connected to each other but you
don’t need additional information about the connection itself.
Examples:
Custom entity Industry with an N:N to Account Add a custom N:N
relationship between the Competitor and Territory entities to track
which competitors are active in which territories Custom entity Color
with an N:N to Contact (you don’t track your contacts’ favorite
colors???)
Manual N:N
A little more work to configure, but generally worth the effort. Use
when in addition to knowing two records are connected, you also need
information about the connection, such as its status, when it was
created and so forth.
Examples:
Associations and Members Events and Registrations (1:N from Contact
to Registration, 1:N from Event to Registration) Subscribers and
Subscriptions (1:N from Contact to custom entity “Subscription”, 1:N
from custom entity “Subscription Product” to Subscription)
Connections and Connection Roles
As I mentioned above, these are actually a specific implementation of
the Manual approach. And if you delve into this a little, you’ll find
that the Connection entity is a bona-fide customizable entity. You can
even customize it, adding custom fields to the connection form and so
forth. But…be careful about overdoing it: there’s only one Connection
entity, and customizations made for one Connection Role generally will
not be applicable to another one.
One specific advantage of these is that a single connection role can
connect records of different types (e.g., contacts can refer other
contacts, accounts and opportunities)
This is a judgment call, but I’d say to use these when you need to
track some information about the actual connections (such as when
they’re created and how many there are…), but not that much. Examples:
Referrals (Contact to Contact, Contact to Account, Contact to
Opportunity) Former Employee (Contact to Account, Lead to Account)
Board of Directors (Contact to custom entity “Board”, Lead to Board)
http://community.dynamics.com/product/crm/crmtechnical/b/richardknudson/archive/2011/05/08/many-to-many-relationships-in-dynamics-crm-2011.aspx
I've been delving into a lot of recommendation algorithms lately (collaborative filtering mostly) and I've found quite a lot of answers on recommending an item based on either a specific user or item (which is part of what I want to do, so that works out). I also want to sent out somewhat-personalized emails, meaning given an email with a certain set of products, pick a set of users to send out the email to.
What would be the best way/algorithm to go about doing this?
For this, you simply turn around the usual collaborative filtering process: instead of recommending items to users, you recommend users to items. You are therefore guessing which users will most like a given item.
Just feed in product IDs as "user IDs", and your real user IDs as "item IDs" into a collaborative filtering system like Apache Mahout. It will recommend users ("items") that would be best for any given email ("user").
Of course you still need input data. Perhaps you have collected a past history of which users have rated or bought or viewed products. That is still your input.