A "GetMonthLastDay()" function that receives as input a specific date and retrieves as output the last day of the month provided (i.e. 28, 29, 30, 31). Something similar to this: This can be very helpful when handling custom date widgets with no day to choose and you still want to filter the range from day 1 of a month to the last day of some future month. Also useful when you want to know if some date belongs to a leap year (or not).

When creating an entity diagram, have the ability to hide the attributes. This would make it easy to see the relation between entities easily.

Hi,I believe that can be a good improvement to have the possibility to disable an REST/SOAP method from our exposed APIs.With that we can maintain versions with methods under work without the need to have different versions and, I believe it's more practical :)  (like the "disable" capacity in the action flows).The idea is to have them under the API but not available to use and not present in the generated documentation.Best regards,Ricardo Pereira

It is difficult to track down a version of a forge component once you have installed it in your environment and the component receives new updates from the community.It should be easier to check how far behind I am in adopting a newer version of a particular forge component by just going to Service Center or best in LifeTime itself.Based on a trustable hashing algorigthm, why can OutSystems not determine if the package hash for the version of Forge component is matching with a signature with a published component and if so flag it to me easily. If the match does not happen then tell me that I have customized the copy of forge component so it is not possible to track it against the public repository.

For each of our native platform apps, I usually have three different versions running on my phone, one for each environment.the development  versionthe testing  versionthe current production  versionI identify these different apps by specifying a slightly different ICON for each environment.The DEV icon for development, the TEST icon for TESTING, and the plain icon for production.This helps because I can immediately see on the phone which version I am running when I touch the app to open it.This works well until it comes time to deploy the latest changes from Dev -> Testing -> Production.Immediately after deploy, I must then open the application, and upload the TESTING icon  again ( and upload the Production icon in the production environment. )How about a feature when editing the application inside service studio to upload THREE icons; one per environment. Then we wouldn't have to keep remembering to change the icon after every deploy.Thanks for your consideration.

If there are any advance queries, replace that by aggregateDon't use foreach Loop in preparationDon't use if conditions in preparationi.e try to avoid if conditions in aggregateApply pagination on list pageDon't show more than 100 records on single pageMove JavaScript webblocks to bottom of pageDon't use preparation aggregates directly in screen actionsBefore using them in screen actions refresh themSuggested by  Suraj.

I have been using images that I have uploaded to the images resource folder but every time I have to select an image all I have is the name of the image as a reference , It would be nice to have a thumbnail next to the name of the image to allow me to preview the image before adding it to the screen/weblock. Images folder There should be thumbnails next to the names of the images

When an input parameter is removed from an action in OutSystems, the platform should automatically remove all references and assignments of that parameter throughout the application to maintain consistency and prevent warning.

Right now, when we want to consume REST API with authentication (Auth2 or Basic), we should add the credentials manually and hard coded. But if we should use the same credentials for different API, we should have the ability to configure these credentials as Site Properties. With that, we can manage the credentials only once for all the API's.

There are similar names in the community and I did notice that some developers can also get confused on who to tag. Or will have some hard time finding the person to tag. It did happened to me a few times. If we can maybe have a tag suggestions, probably will suggest those names first that are already in the conversation, then I think it can help in some ways.