Product ideas | Community
Skip to main content

10000 Ideas

lgaertner
lgaertnerNew Participant

A possibility to set user rights in a more detailed and granular wayNew

Description - I am currently trying to find some solutions to be able to set up certain user rights in much more detail than currently seems possible or intended.In the course of this, the way in which the inheritance of rights works hierarchically with shared objects constantly presents us with new challenges. Why is this feature important to you - We want to use portfolios as self-contained silos, so to speak. It would be necessary to be able to assign different rights within a portfolio in a convenient and understandable way. One problem with this is that if a user or a user group has already been given certain rights at a higher level, these are always inherited completely downwards via programs, portfolios, tasks, etc. and the inherited rights always override any additional, more restrictive rights.Inheritance cannot currently be deactivated via the API. Although there is an unofficial workaround that can also be implemented in Fusion, the complexity leads to quite complex and therefore error-prone Fusion scenarios. In addition, there are simply too many different places in the system where access rights are set (Sharing settings on objects, access levels, templates, ...). All of this means that a lot of trial and error with many errors is necessary in order to implement certain requirements or to recognise that something is not possible. I would like to give you an example to illustrate this. We would like to restrict a specific user group to be able to only download documents from a specific folder on a task and if accessing other folders to see the documents, but not being able to download those. If the user group has access to the parent project, the users have download access to all files due to inheritance, regardless of which folder they are in.Setting up an additional sharing right on a folder to restrict the download possibility for this group is ignored because of the inheritance from the parent projekt / task.So it would be necessary to turn of inheritance here. I would prefer it to be possible to overrule inherited rights. Looking into the Access Levels, there is a possible additional restriction to Never inherit document access from projects, tasks, requests, etc...Nice approach, but that means, that the access rights need to be set for any document. A rule on a folder is completely ignored for the containing documents. Apart from the fact that it took and still takes me a lot of time to find out and understand these peculiarities of the system, you may come across other challenges in other places.Maintenance and ensuring that users are really only allowed to do what they are supposed to do is also a very difficult task at the moment.  How would you like the feature to work - more detailed and granular way to setup user rights to have a much more flexible application Current Behaviour - as described above.

lgaertner
lgaertnerNew Participant

A possibility to set user rights in a more detailed and granular wayNew

Description - I am currently trying to find some solutions to be able to set up certain user rights in much more detail than currently seems possible or intended.In the course of this, the way in which the inheritance of rights works hierarchically with shared objects constantly presents us with new challenges. Why is this feature important to you - We want to use portfolios as self-contained silos, so to speak. It would be necessary to be able to assign different rights within a portfolio in a convenient and understandable way. One problem with this is that if a user or a user group has already been given certain rights at a higher level, these are always inherited completely downwards via programs, portfolios, tasks, etc. and the inherited rights always override any additional, more restrictive rights.Inheritance cannot currently be deactivated via the API. Although there is an unofficial workaround that can also be implemented in Fusion, the complexity leads to quite complex and therefore error-prone Fusion scenarios. In addition, there are simply too many different places in the system where access rights are set (Sharing settings on objects, access levels, templates, ...). All of this means that a lot of trial and error with many errors is necessary in order to implement certain requirements or to recognise that something is not possible. I would like to give you an example to illustrate this. We would like to restrict a specific user group to be able to only download documents from a specific folder on a task and if accessing other folders to see the documents, but not being able to download those. If the user group has access to the parent project, the users have download access to all files due to inheritance, regardless of which folder they are in.Setting up an additional sharing right on a folder to restrict the download possibility for this group is ignored because of the inheritance from the parent projekt / task.So it would be necessary to turn of inheritance here. I would prefer it to be possible to overrule inherited rights. Looking into the Access Levels, there is a possible additional restriction to Never inherit document access from projects, tasks, requests, etc...Nice approach, but that means, that the access rights need to be set for any document. A rule on a folder is completely ignored for the containing documents. Apart from the fact that it took and still takes me a lot of time to find out and understand these peculiarities of the system, you may come across other challenges in other places.Maintenance and ensuring that users are really only allowed to do what they are supposed to do is also a very difficult task at the moment.  How would you like the feature to work - more detailed and granular way to setup user rights to have a much more flexible application Current Behaviour - as described above.

NoNameForMe
NoNameForMeNew Participant

End Date Field References Start Date Field By DefaultNew

When a requestor fills out my form, they choose the Start date (which defaults to today's date). Then they choose the End date (which also defaults to today's date). Is there a way (maybe in Text Mode?) that we can make the second field (End date) defaulted to select the previously entered Start date value, since the End date should always come after the Start date?I'm always trying to reduce form clicks for my team. Requestors are noticing the behavior when entering numerous issues with the same form, specifically when using Start and End date fields in tasks and issues (also with default Calendar month at load-in). It takes extra time to select the End date, and is very obvious when flow is repeated numerous times. Maybe when a date field is added following after another date field, or, maybe when two date fields are set side-by-side (same line), then the second (End) date would allow the user to reference the first (Start) date. You could use the "Add Logic" menu and UI to reference the first form, with a function drop down with the option/value to "reference start date". That would be very cool. Right now, even if you select a Start date of Jan 1, 2035, the End date field will always default back to today's date, causing you to have to click a lot to get back to the year 2035, just to select the next day for the End date, resulting in double the amount of clicks for each issue created. Thanks!

Tlovie
TlovieNew Participant

Requesting that Adobe create new user access level for fusion only users - Do they truly need Sys Admin Access Level?New

Description - We have fusion users who create fusion scenarios, but are not acting as system admins within Workfront. To create fusion scenarios, users must be given the access level of System Admin.  For example we have users within our Corporate IT team who are experts in Jira. They create fusion scenarios that link Workfront into Jira, but their expertise in within Jira. They take training on how to work in Fusion, but their focus is not on being a  Workfront system admin. They own, document, update their fusion scenarios.Why is this feature important to you - We have users in Fusion who show as System Admins, when in reality they are not system admins. They only author and maintain fusion scenarios. We would like them to be assigned a newly created access level to denote that they are Fusion only users. We don't want or need them to be viewed as system admins, because in reality they are notHow would you like the feature to work - We would Adobe to develop an access level that allows users to interact between Workfront and Fusion, but not give them System Admin access level. Would it be possible for a fusion person to only be required to have group admin access level?Current Behavior - Our Workfront instance gives the appearance of having System Admins, who don't act as system admins, and we don't expect them to act as System Admins. We need visibility on who is  a "fusion only user". Yes, I know we could create a job role or team, but the reality is we don't want these users to have the same access levels and permission as a System Admin. All feedback is welcomed. 

natteaNew Participant

Enhanced formatting options for Project & Task Descriptions - HTML formattingNew

When creating a Project and Task there should be a more robust feature for creating the description. Wrike has this ability and it's amazing. A lot of times, a project's description reaches far beyond plain text and custom form fields. How most people at our company communicate is through email, and although email is a complete mess, what email is good at is allowing the person to format a message and description is multiple ways: through documents, screenshots, HTML text formatting (BOLD, underline, strikebreaking, bullet points, numbering, indenting, tables, charts, font colors, etc). Most project and tasks have supporting information in the form of images and charts, and there isn't a way currently in WF to communicate this within the system. We now have to go outside the system and go back to emailing or using other project management tools. Workfront has a lot of amazing features, but I feel as though you have to think back to the basis of a project management tool - and this tool should focus on the easy communication of project and task creation. This could also be applied to requests and documents as well, but not as important as projects and tasks.The creation of a task should be a bit simpler and less cluttered. Workfront has so many options and features, which is fantastic, but it can be completely overwhelming for users who are not necessarily tech savvy and just want to use the system for creating a task, description, dependencies, assignee, and due date. This information should be at the forefront of the design and the rest of the functionality can be shown differently. And custom form fields should really be considered part of the projects description and be within that same area. Right now it's not very intuitive where to get necessary details about the project in order to do someone's job. The user needs to go to project details, look at the main overall timeline details then click custom form to get the actual full description of the project.