I'm integrating Freshbooks with an application at my company and am accessing the Freshbooks API. We have a few developers that work at our company. I'm finding that even if several developers are all assigned to the same Project on Freshbooks, when accessing said project via the API on a per user basis, each user has a different Project ID for that one Project.
My question is: Is there a "common project ID" that all Users who are assigned to that project can access via the API? The only consistent point of reference seems to be the Freshbooks Project Name -- which is fine except when the Project Name changes.
As I discovered, the reason there is no global project ID across my developers' accounts is because they are all registered as Contractors on Freshbooks and not Staff Members. Freshbooks makes a distinction here. Contractors have fully separate accounts, whereas Staff Members can be queried in the API THROUGH the account under which they are staffed -- allowing you to use the same Project ID amongst all Staff Members.
Related
I'm creating education class teams via MS Graph API. I create an education class and then a team for that class using the method described here: Create a team from group.
Teams remain inactive until the teacher is ready to set up and activate the team. All good.
But until a team is activated, when I List members of a team, non-owner members (students) are not included in the response.
Is anyone aware of an option to include the students in the response? Note that if I List members of the Education Class then the students are included, but that does not give me the team membership-id required to Remove members from team.
You can't do this with Microsoft Graph API at this point. Uservoice is raised on this.
One bit of clarification, the Team isn't "inactive" so much as it hasn't been fully provisioned yet. When creating a Class, it adds a Team provisioning option. This simple queues it up for provisioning when the owner opens the UI. Until then it is simply a Group.
Since there isn't a fully provisioned Team, there isn't a Team to remove members from. What there is, however, is a Group/Class directory object. Removing a member from the Class (or the Group) will result in that member not getting added to the Team if/when the actual provisioning occurs.
I am building an application that creates Teams for my training classes and I can Create a Group, make it a team, and then add the required folks to the Members list. I want to be able to differentiate between "students" and "facilitators" for reporting and management.
I have found /api/v1/teams/{0}/memberTags/ but I don't seem to be able to call it directly or find it in the SDK documentation.
Is this API available?
Teams Tags are currently in the Graph beta
https://learn.microsoft.com/en-us/graph/api/resources/teamworktag
Tags provide a flexible way for customers to classify users or groups based on a common attribute within a team. For example, a Nurse or Manager or Designer tag will enable users to reach groups of people in Teams without having to type every single name.
Tags are scoped at the Team level.
When a tag is added, users can #mention it (#tag) in a channel in that team . Everyone who has been assigned that tag will receive a notification just as they would if they were #mentioned individually. Users can also use a tag is to start a new chat with the members of that tag.
No, there’s no API for this now .
Check here to Manage tags in Microsoft Teams app. We will keep you posted once this feature is available through API.
I created a Group using
https://learn.microsoft.com/en-us/graph/api/group-post-groups?view=graph-rest-1.0&tabs=http
and then used
https://learn.microsoft.com/en-us/graph/api/team-put-teams?view=graph-rest-1.0&tabs=http
to create a Team. Now I am facing issue when adding a plan using a Planner app
"Failed to create the plan."
How I can fix this issue?
In my investigations, I found that the other team members are able to create plans. As an owner of the team, I am not able to create them. if I am trying graph API I'm getting an error:
You do not have the required permissions to access this item, or the item may not exist.
I'm glad you came right and that I was able to help. I'm updating the answer so that it's more clear on a few points:
Technically, this actually has nothing to do with Teams at all, it relates to Office 365 Groups, which forms the core underneath Teams, Planner, and more. You actually link in your question to the Groups docs, incidentally. I've updated the question title to reflect this.
I haven't tested this exactly, but I doubt that it needs your account exactly in the Owners and Members - I suspect the main constraint is that there needs to be at least one person in each of those roles (that means there has to be at least one Owner and at least one Member). Arguably, this is actually a bug in Planner, but it was maybe never detected by Microsoft because if you create a Group from the web interface, it automatically puts your user in as Owner and Member.
If you do put your own account into both positions, but that's not what you want long term, you could probably just take them out after creating the Planner plan.
Just a reminder that best practice is to have more than one owner of a Group, in case/when the original Owner is not/no longer available.
It's fixed after adding the creator of teams as a member too. So I had to add the user who is creating Teams in Team members too.
I made sure that there was another owner on the Team, demoted and removed the owner and the re-added them to the team. This resolved the issue that I had with multiple teams
My question is how to create client specific projects in JIRA cloud, so that clients can't view company's internal project and are restricted to their own project view in JIRA?
You'll have to configure:
User Groups
Project Roles
Project Permissions
Typically your customer users are part of a customers group. Your internal users are part of other groups, e.g. internal.
Within a project you have different roles. You can assign groups to a role, ie. customers can have the users role in the project that is relevant to them. Your internal people can for example be in the developers role of projects that are relevant to them.
In a project's permission scheme, you then configure which permissions correspond to each role. If you assign the browse permission to the users role, and the customers group has that role, then they will be able to view the issues in that project.
If you don't put the customers group in a role then they won't be able to see or do anything with the issues in that project.
I am having a little difficulty understanding when a person should configure JIRA permissions using groups and when they should use project roles. I have read the online documentation, however, the difference between the two seems subtle.
A group seems simple enough. Group users into a named bucket. Assign the group to one or more permissions within a permission scheme to enable access to functionality for any users within the group. Assign the permission scheme to a project to apply the permissions to that project.
A project role seems very similar. It does all of the above except that you can also add groups to project roles. It seems that a project role also allows a project administrator to add their own users to a project instead of requiring a system administrator.
However, I am not sure how I can leverage this. Here is an example of what I want to achieve.
Have multiple projects created in JIRA.
All of our managers, developers, etc. have the same permissions across all projects.
Our clients have access only to their projects.
I think that the best way to accomplish this is to:
Create an employees group to which I add all of our employees.
Create one or more project roles to which I add the appropriate clients.
Assign permissions to the Default Permissions Scheme using the employees group.
Copy the Default Permission Scheme to a new project specific scheme, e.g., client-scheme
Assign the client-scheme to the client specific project.
However, it seems that I am not leveraging project role membership. How does this come into play?
What is the best practice for using JIRA groups and project roles? What is the different between the two?
We are advising to work with roles as it has a couple of advantages
a. You can setup the complete configuration based on roles.
For instance you might have a workflow transition 'validated' which can only be executed by someone who is a tester.
You have the choice to add a transition condition 'user is in group tester' or 'user has the role tester'.
If you are working in an organisation where users have different roles in different projects, choosing the first transition condition (user is in group tester) will not work (or you would need a new workflow for each project)
The same applies for notifications.
You can configure a notification on the 'issue resolved' event, specifying that the 'users in group tester' get notified or 'users who have the role tester'.
When using roles, adding someone to a project is very simple - just check what role the person has in the project, add them in the project configuration (view members) and you are done. He will have the right permissions, get the right notifications ...
b. Configuration
When you use roles for configuration, you don't need system administration rights to add someone to a project. The project lead will be able to add the user. No need to bother the system admin.
Looking at your description, I would have
A project role 'employee'
A project role 'customer'
A group 'employees'
configure the project role such that the group employees is a default member of the project role employee
This way you can use the same permission scheme for all projects. When adding a new project, you just need to add the client specific userid to the client role.
When a new employee start, you add him to the employees group.
The day that you have a specific, ultra secret project, where only a couple of employees need to have access, you can remove the group 'employees' from the role 'employee' and add the specific users to the role.
Hope this helps
Francis
Historically, JIRA had groups first. Then roles came along and are the recommended way to control authorization in most cases.
~Matt
Groups are global. Roles can be thought of as per-project (local) groups.
Roles are much better: else with a large number of projects you quickly end up with a proliferation of Groups and permission schemes (one per project).
You lose nothing by using role-based permission schemes, since you can add a Group to a role.
But you gain a lot of flexibility. Eg you'd currently have the Employee role be filled with your Employees group for every project, but as your company and complexity grows, you can have different Employees per project, without having to change the permission schemes