Product ideas | Community
Skip to main content

Filter by idea status

10000 Ideas

JustinWhNew Participant

Change color of proof comment marker to green after comment is resolvedNew

Description - We would like to be able to quickly scroll through the document and see outstanding comments needing resolution. Resolving proof comments is a great feature, with the added benefit of the green checkmark next to the comment in the right-hand comment column. To support this it would be great if the comment marker within the proof document also turned green. This would make visually scanning the proof for unresolved comments much faster.Why is this feature important to you - This color change feature would be valuable because often the proof owner/administrator cannot resolve all comments at once—some comments take time to evaluate or research before the can be resolved/approved/declined. In a proof with many comments it is not easy to scan through the document comment markers for unresolved comments; they all stay red, which is probably just the default user comment marker color. They do have a small checkmark, but this is not something you can quickly scan.  How would you like the feature to work - Recommend that when a comment is resolved its comment marker on the document gets the same visual indicator of resolved/approved/declined that the actual comment in the right-hand column already does.Current Behavour - Currently a checkmark appears on the comment marker, but this is not quickly scannableAttached is an example of what this might look like with color that changes upon resolution of the comment.

cvergesNew Participant

Contextualized and customized help text for a reportNew

DescriptionWe have LOTS of reports with which our users engage on a regular basis.  To help onboard new users and ensure existing users can easily consume new reports, we need some kind of way to provide the user with in-system instructions and tips/tricks/reminders about specific reports.Why is this feature important to youOnboarding new users or existing users to new reports can be one of the most costly ongoing endeavours for a sufficiently large organization.  Such training time is often non-billable and interspersed with other activities and training priorities.  As such, we need to minimize those costs.  One of the best options is to make the reports themselves more intuitive.  While we strive for that in design, there is often the need to provide help text that prompts the user just a nudge.How would you like the feature to workTwo ideas come to mind.One is that there is some kind of "side panel" that can pop out when the report title (or a "?" icon next to the report title) is clicked -- or perhaps an explicit "Help Notes About This Report" link/button somewhere next to the report.Another is the ability to have some kind of "below title / above content" note text that always renders, perhaps in a semi-collapsed state unless clicked.From an admin perspective, there would just need to be a new field added with each report module that would allow the admin to input the optional text.  HTML would be strongly preferred so that we could format, link to external images/sources, etc.Current BehaviourWe are playing with embedding external reports (like iframe'd HTML pages), but this can make the reporting page appear to be cluttered and isn't the streamlined experience that we're after.

Kurt_Koller
Kurt_KollerNew Participant

Document and officially support POST for API authenticationNew

I've seen many customers have a security review that comes back flagging the use of GET on the API and putting client id and secret on the URL. Apparently people are somehow convinced that that's "in public". https://developers.marketo.com/rest-api/authentication/#using_an_access_token developers.marketo.com/rest-api/endpoint-reference/authentication-endpoint-reference/#!/Identity/identityUsingGET I've explained to people that it doesn't put it in cleartext to the public exactly (which is what people seem to think), as all connections are HTTPS. There is an abstract risk related to logging or something like proxy intercepting - if they log full URLs somewhere then that would be logged in a file somewhere and then that file and who can see it is important. Regardless, it's not how OAuth 2.0 is supposed to work and there is risk associated with GET, which is why it's not allowed in the OAuth 2.0 spec. Would it be possible to update these pages to show that you can use a POST? i.e. both of these work perfectly well:   curl --location --request GET '123-ABC-456.mktorest.com/identity/oauth/token?grant_type=client_credentials&client_id=<client id>&client_secret=<client secret>'     curl --location --request POST '123-ABC-456.mktorest.com/identity/oauth/token' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'grant_type=client_credentials' \ --data-urlencode 'client_id=<client id>' \ --data-urlencode 'client_secret=<client secret>'I'm not sure if the POST is officially supported at Marketo, but it absolutely should be, and if it is, I think the documentation should have that as the default, not the GET, and maybe even deprecate the GET, up to you.Security is more and more on people's minds and this has been flagged in numerous companies. I tried the POST like 2 years ago, and saw that it worked, and have told people they can use that instead - I just told someone else today and I think it might be best to just support this and change the documentation.Thanks for the consideration.