Skip to main content

Filter by idea status

10000+ Ideas

Mylah_DLevel 4

Restrict User Visibility by Group/Team/Job Role Membership (not Company)New

There are various regulations governing the handling of Personal Identifiable Information (PII). Based on the definition of PII, if you can see a user's profile in Workfront, you can see their contact info and manager, and that is already PII. Workfront currently allows 4 controls allowing admins to restrict profile visibility using Access Levels:1) Access Level > Users > View - leave "View Contact Info" unchecked2) Additional Restriction: Users could View only companies, groups & teams they belong to3) Additional Restriction: People in other companies should only view users from...Their Company4) Additional Restriction: People in other companies should only view users from...Primary CompanyWhat is not offered is the ability to restrict People in other companies so they can only view user profiles from groups or teams at other companies with which they're explicitly working. There is an unfortunate limitation for us with current functionality, because if you can't see a person (in Search Bar typeahead) due to restrictions because they're at another company, you also cannot tag them in Update threads. Our organization relies on teams from various companies to collaborate with one another on Work Items. The visibility restriction makes it so we cannot allow users from different companies to tag one another (to get their attention thru notifications) when there is an update because it means they can see EVERYONE at the other company. We're pretty seriously hampered because we have to disallow people in Company A from tagging people from Company B if it means the personally identifiable info of everyone at Company B is exposed to Company A. PROPOSED IDEA: add another level of granularity so that users from one company can at least tag users from diffferent companies, as long they are all in the same team or group, while still preventing them from seeing ALL users from any other company. Plugging up this hole should allow maximum availability of the Updates tagging feature without exposing Workfront customers to liability of sharing PII unnecessarily.

LaurentLam
LaurentLamLevel 5

Updating the documentation with a good practice.Investigating

In the documentation, a bad practice for developper is unwantedly suggested:https://experienceleague.adobe.com/docs/campaign-classic/using/configuring-campaign-classic/api/data-oriented-apis.html?lang=enTo limit the number of records returned by the query to 100:<queryDef schema="nms:recipient" operation="select" lineCount="100">...To retrieve the next 100 records, run the same query again, adding the startLine attribute.<queryDef schema="nms:recipient" operation="select" lineCount="100" startLine="100">...In fact, a dev should never use the startLine attribute as it contribute to a loss of performance:exemple with a SQL translation of the 1rst example:select top 100 from nmsRecipientYou'll get the 1rst 100 records... No issue about that Now is the SQL translation of the 2nd querydef:select top 200 from nmsRecipient=> as the startLine begin at 100, the "top" will start at 100 and add the line count attributes (100) ... Then the JS engine will keep the last 100 recordsThis doc is used by developper to create code in order to loop over all the records of a table as queryDef are limited to 10000 records usually:Imagine a loop with a lineCount of 10K... If you want to use a queryDef in order to operate on a 100K table: it will creates 10 sql queries, retrieving each time 10k more results leading to retrieve 550K results instead of 100K and each requests to be more greedy on performance (10+20+30+40+50+60+70+80+90+100). The good practice should be then to use an Id (directly the id of the schema or a rowId from a wkf work table if possible) in the where clause in order to replace this "startLine" attribute:<queryDef schema="nms:recipient" operation="select" lineCount="100"><where> <condition expr="[@id] > " var.lastProcessedId /></where></queryDef>I observed in the past some workflow JS activity with the "startLine" implementation that were optimized from 4h down to 2 min. Placing a warning in the documentation in order to inform that they should never use startIndex as a way to loop over a schema would be really helpfull, specially for beginners. Ps: TY @cedricrey  for this tip months ago

ACC 'File Resources' revampNew

Description - File resources currently has limitations and issues around trying to re-upload files with updated code, annoyingly enough, the only way around is to change the file name and re-upload a new file which fills up file resources folder with a lot of junk. Furthermore, while deleting the file from the file resources folders gives the impression of file deletion, this is not the case, it still lives in the server, even after I run a shell file deletion script which literally removes the file from the server, the file still is accessible from online, as if it was cached by cloudfront perhaps?How would you like the feature to work -Enhance the file resources form provide an actual file manager which allows advance file handling and search functionality.Upon uploading new file, allow file replace so that users don't end up uploading dozens of variants of the same file which fills up file resources folder. (particularly annoying while working with css and js file, where changes are done frequently and require alot of code refresh)Allow acc to call cloudfront, or whatever caching module is being used as to force expiry of cached assets to allow us to test in real time uploaded files.Allow file upload whitelisting control filters from file resources, currently this is configured from within serverfile, perhaps creating an admin control zone that allows these filters to be controlled from within the client will be easier to manage.Current Behaviour - lacking features, bugs, limitations