Is it possible to assign a user to a workspace through asana API. The documentation here doesn't seem to be making any mention of it.
Is it possible to assign a user to a workspace if we have the API keys to both the asana accounts(i.e one belonging to the user and the other of the user to which the workspace belongs)
We do not currently support managing workspace members via the API, however we have made significant progress towards supporting this. We're currently weighing some security considerations, though, so it's hard to say when we'll be able to launch this. Sorry, I'm sure that's frustrating to hear.
Related
I currently have a script that takes a list of people and creates new Asana projects, one for each person. These people are not in our Asana organization and need to be invited as guests to their respective projects. If I try to include a followers or members property in my API request, I get denied, and the docs list those properties as read-only.
I noticed this question from over a year and a half ago, where an Asana engineer said that it was on the API roadmap and that he hoped to publish it soon. It seems like the engineer in question no longer works at Asana, so replying to him won't help me, but has any progress been made on this front? Being able to invite guests to each project programmatically would be a huge time saver. Thanks!
We decided to keep this as a read-only endpoint. Apologies for the confusion.
You can add and remove followers on a task through the API. Perhaps you could adjust your workflow to use tasks instead of projects.
Experience with Jira is based on what I have seen from clicking through the project. There is no knowledge transfer as all people who knew this customized system left over a year ago.
As for the Atlassian PDF guide, it is not able to assist because the feature to add users and manage the users in Jira have been removed. An external LDAP system is where the users are managed.
I can view the User Browser and see users and do some editing of a profile and even delete the user from a navigation link in the footer.
But the real question at hand is, what do I need to do in order to
A. Assign users to an Organization Role that only allows them
1: A view only mode of the users in that Organization
2: View the details of the user and that users permissions/roles given
I've been looking for a few days now and just keep running into brick walls.
Thank you.
The upgrading of the system to the new version is not an option due to the extensive undocumented modifications made to Jira. It has been tried 3 times in the past 2 years without success.
I am answering based on JIRA 5.2 and higher experience.
Only place to see list of users is User Manager and you need to be JIRA admin to access it. So it's not a solution for you.
I searched for addon doing this but no luck. Moreover your JIRA is too old to be supported by addon providers.
The same story with JIRA REST API. Looks like for JIRA 4.1 you need to use JIRA REST 1.0 (current is 2.0) and I can not find docs for it.
I believe it's possible to write the addon to accomplish what you need but again it's not smart to invest in obsolete JIRA.
The most right solution is still migrate to the newest version of JIRA. Maybe you need abandon the undocumented changes or rewrite them into JIRA addons. It will not be easy and it can be costly but looks like you do not have too many options.
Task has been abandoned.
No answer to bad implementation and poor engineering practices when one is to continue to follow them.
I'd delete the post entirely but I'd rather give credit to the few that tried to provide some insight. Thanks again.
I continue to get a "HTTP/1.1 403 Forbidden" response from a PUT request to /d2l/api/lp/1.2/courses/7917 . This may be a permission problem with the user/role that I'm using, but I can't figure out what specific permissions may be required. Can anyone point me to a list or matrix of valence routes and required permissions? Or, answer for this specific one?
The same appid/userid/username works for the GETs associated with the same path.
confused...
cwt
The permissions associated with API calls should mirror the permissions you'd have to have if you were to perform the relevant function through the Learning Envrionment's web UI. You can think about this problem in two ways:
Frame the question in terms of a user role: identify the class of users you'd reserve this ability for in your existing configuration, and ensure that a user of that role can make the call through the API as you'd expect.
Frame the question in terms of an abstract single user: start with a role that has no privileges and add permissions until you arrive at only the ones required for the API call. This is not a trivial exercise, and the first way is far more useful in the long run.
In this particular case, because the API requires you provide a complete course offering set of properties when you want to update it, you have to have permission to alter all the properties in the set (under the Manage Courses tool). You also need to be able to see the course info in the first place, so you need to have Course Management Console > See Course Info as well.
You're probably safest to look at the permissions array in the Manage Courses and Course Management Console tools for the user roles that would do this thing in the web UI and make sure that the users employing your app also have a similar permissions array specified in those tools.
We're looking at using Asana to combine CRM, administration and issue tracking in a web dev firm. The key feature we need is a view of the "next actions" or "top [1|2|3] priorities" across all projects in a workspace, irrespective of who they are assigned to. It seems Asana does not provide this out of the box (is that right?) so I am looking into writing API queries to pull this out into a dashboard of our own.
I understand you don't want to let people pull ALL tasks in one workspace, as it may grow, but is there a way to pull out the top few open tasks in each project, without having to specify the assignee?
(I work for Asana)
Currently, the API allows you to grab all tasks in a project, see https://asana.com/developers/api-reference/projects. It will return them in ranked order (the same as they would show up in the Asana UI), however it won't limit them to some number; you'll have to get them all. Limits and pagination are on our roadmap to enable developers to work more efficiently with larger projects and workspaces.
So, it seems like you'd want to grab all projects, then iterate through them and query all tasks - this will give you their name and ID by default. If you want more detail for the ones you're going to show, then I recommend querying the details on each of those tasks individually.
I've been reading some feature request-style threads in Atlassian's own JIRA install on how to disable (not remove) users in JIRA, and their suggested solution involves a series of UI actions. For the number of users that our organization supports, this needs to be automated with the rest of our employee account provisioning logic.
I've been looking in the JIRA database and found the membershipbase table, but simply removing records from here WHERE USER_NAME="$username" doesn't seem to have a completely successful outcome. When I go to the User Browser in the Administration section and look up that user, groups still appear for the user.
Does anyone have any experience with this that could point me in the right direction on any other tables I need to modify?
Thanks in advance,
-aj
Maybe you should take a look at Atlassian's Crowd. Even if you don't use SSO, it may help you to integrate with your existing infrastructure for handling authentication and authorization (i.e. groups) centrally. It also provides an administrative frontend that is designed for the corresponding tasks.
You could have a look at the EditUserGroups.setGroupsToLeave() method. As far as I remember, users need to be in the jira-users group to log in. So, if you remove this group from the user, it may be effectively what you need (not delete but deactive user acount).
If this does not help, I'd look into the source code of JIRA (which is available for all types of licenses afaik) to see which tables are modified by the above method.