When working on the theme I accidentally introduced an error by putting a square bracket in one of the lines, like the one we can see in line 92 here: This did not raise any errors on TrueChange allowing me to publish the theme and break all the classes that were below that line. Since the theme was visible in the sources of the browser and properly loaded, it took too much time to realize it was a simple syntax error. This could have been avoided if TrueChange would not allow to publish CSS with syntax errors.

Rank the badges on the certificates, instead of just showing them by date. Put the expert/Professional badges at the top, making them bigger, possible with a line under that section, and don't show the lower "Associate" certifications that they supersede, or put them smaller at the bottom: (They are only at the bottom in this example because I passed them first.) Thus:

In any modules, the paste option is not working or you can say its disabled in few places and its not working on the find and replace dialogue box, i need to type manually everytime in this new update.

Hello @OutSystems Community. When we create an OutSystems Support case we are not always aware of its importance. My idea is to allow the possibility of clicking on the Tag with the severity of Issue (level of difficulty) of Support Case resolution for example "Normal" to "High" to open a popup with the possibility of changing the level of difficulty of the ticket. This idea is also in order to help the OutSystems Support team to better track the degree of demand that the resolution of each support case may require. Best Regards, Paulo Russo .

Hi everyone,I spend a lot of time inactivating the users who should not have access to an environment for some reason. What I would like to suggest is for us to have the ability to set an expiration date for each user that is not an administrator.This way I can easily manage the users on my factory especially when we have outsourced developers.

When changing locale of a screen, in multi-lingual applications, everything is translated, except validation messages. The validation message is displayed in the right locale when triggered, however, if the validation message was already added, and then the locale changes, the validation messages are not translated to match the new locale. To translate the validation messages, the user has to trigger the form validation again.

Currently, when using an Input widget with Type = Number, it is not possible to set a Max Length for the field. This forces developers to switch the input type to Text and implement additional JavaScript, masks, or custom validations just to control the number of digits — which increases complexity, reduces maintainability, and removes the native numeric keyboard on mobile. Adding a Max Length property (similar to text inputs) would allow developers to: Prevent users from entering more digits than required Avoid using JavaScript workarounds Keep the input type as Number Improve UI validation consistency Increase development speed This enhancement would significantly reduce unnecessary logic and provide more control over numeric inputs without losing native browser behavior

Personal test/learning accounts have very short time limits, selected long ago, before the average wristwatch had gigabytes of storage. This has created a problem that if you don't log in to your account weekly, all your work, like forge components you may be maintaining, get deleted. Please can the timeout be extended based on community rating / responsibilities?

Branching could be useful in different situations, some more relevant than others, but on big factories with a team with several developers, it could be very useful.A situation that occurs frequently is when we receive a change request which requires changes on core entities, this will break the environment , and will affect other developers that are working on a different feature, but are prevented of testing/developing without pain since the environment is broken.So it would be great of having an way of creating a branching per pta of a solution, were the developer could make the change that will break the environment isolated, finishes the development, could test it isolated again (remeber that i've mentioned a branch of the solution), if everything is ok, perform the merge of the branches, create a new solution and schedule the publish.Im mentioning PTA was a way of doing it, it could be by branch, if it was possible to work on different espaces on a context of a branchIf i was a smoker i would quit smoking with this feature :)

 The BaseTheme used in Outsystems, as like most of the designers in the market, use the   multiple of 8  rule to create sizes for margins, padding, font sizes, grids... So, if BaseTheme uses the same rule for variables for everything why not use it in the Style Tab too?   Benefits : Less maintenance , Easier for the Develop team to match mockups margins and paddings. Less frustration,  Help experience between the Develop team and the Ui/Ux/ FrontEnd teams easy and softly. Less work for the FrontEnd team finding wrong margins and paddings. Apply best practices , (One-click change everywhere) , Even if there is inline CSS (which isn’t the best practice) when the variable is changed on the theme, the value is automatically updated everywhere. CSS learning ,  Make the Develop team more familiar with the CSS variables.