Check-in comments
8219
Views
175
Comments
On our RadarOn our Radar
Collaboration
In OutSystems Platform publishing is like comitting your changes to Version Management.
It would be extremely helpful to be able to add comments on the 1 Click Publish process.
This would be even more flexible if one could drill down these comments by changed object (webscreen, webblock, action, webreference action, etc)
2016-04-21 20-09-55
J.
mvp_badge
MVP

Yes.

would be great with linking them with ect.

2011-06-15 10-51-22
Joop Stringer
Be careful what you wish ... I was working with Microsoft TFS before and there we needed to add comments to a "check-in". It turned out to be a blank or just something stupid like "checked in".

So make it configurable within an eSpace wether to have comments on check-in
2016-04-21 20-09-55
J.
mvp_badge
MVP
we cannot fix the developer ;)

we wish, but we cannot.


One should be able to add comments after publishing an eSpace, extension or solution. This should be optional.

This comments could have information on the new features, whether or not it was a valid version to rollback to, name of the project in your external sourcecode control application,  etc.
2018-05-04 12-26-50
Gonçalo Veiga

The platform might aggregate all top-level elements which were modified, since the last publish and generate a comprehensive text, which would be added on publish and be presented in Service Center. Aditionally, the developer might add a comment, during the publish, to be appended at the end of deployment.

For example:
Added Screen Action to Web Screen CustomerList
Modified User Action Customer_ImportDetails

 



Merged from 'Auto-generated publish description (ex. Added Screen Action to Web Screen CustomerList)' (idea created on 2010-05-11 12:16:53 by Gonçalo Veiga), on 2010-05-28 10:59:34 by Paulo Tavares
2016-04-21 20-09-55
J.
mvp_badge
MVP

almost the same as https://www.outsystems.com/ideas/70/

only with added auto-generated comments


Merged from 'Auto-generated publish description (ex. Added Screen Action to Web Screen CustomerList)' (idea created on 2010-05-11 12:16:53 by Gonçalo Veiga), on 2010-05-28 10:59:34 by Paulo Tavares
2016-08-25 18-41-23
Lúcio Ferrão
I personally prefer automated change logs instead of comments :)

I've already requested this in the forum before, so I totally agree with you. I think it's very handy to enter the issue number for example when publishing an eSpace.

Although automatic comments would be nice, specially for development environments, I think that it is important for users to be able to add their own comments in the production environment.

Imagine you're responsible for deploying eSpaces into production. Automatic comments like "Action CUSTOMER_Create changed" might not give you the details you would like in order to understand what's new in that version; you might want to add that customer's email address is now mandatory and validated using a regular expression, and that a welcome email message will be sent to new customers.
Automated change logs is not enough. If you know what has been changed but you do not know WHY it has been changed, it is not very helpful.
I've asked for this for some time but haven't followed through on implementation.

This would allow a cursory look on the versions of an espace on service center to know what each release was about.

The automatic change log and the custom message are both useful, the first because if gives a nice overview for operations and project management ant the latter for the developers.
There is a long time that in the service center - factory - espace versions i miss a column with very brief info about the published version.
It happens quite often having to download and open the espace to know which version is what, what differences in code were added, it it is a production hot fix...

It would be very usefull to be albe at publish time to enter a small label (even if only 10 characters length) to be able to distinguish later on, in the service center, that version from the others in case of need.

In the studio a simple button like "Add label to this version" would do it.
If would be blank for default  each time the espace would be published, unless the user would explicitly press the label button and fill it.

In the service center there seems to be enough space for a 10 char column that could spare a lot of time looking for versions, specially the old ones.

Tkx!

Merged from '[Service Center] at espace versions tab, add a column (label) with short info about each published version' (idea created on 2010-07-29 10:50:50 by Joao Carlos Carvalho), on 2010-07-30 11:04:42 by Pedro Oliveira
2022-09-05 17-58-21
Matthias Preuter
mvp_badge
MVP

Must have!


Merged from '[Service Center] at espace versions tab, add a column (label) with short info about each published version' (idea created on 2010-07-29 10:50:50 by Joao Carlos Carvalho), on 2010-07-30 11:04:42 by Pedro Oliveira

Similar to Check-in comments.


Merged from '[Service Center] at espace versions tab, add a column (label) with short info about each published version' (idea created on 2010-07-29 10:50:50 by Joao Carlos Carvalho), on 2010-07-30 11:04:42 by Pedro Oliveira
I agree with Joop, be careful to make this comment not required but optional. In TFS the option to comment all chek-ins are nice but stupid where you are obligated to do so.
This is just a wonderful idea, and very, very useful one mainly if you could integrate this comments in OutDoc...

This is particularly useful when you really have to register those changes, either because you are working on a multi-environment, ,multi-development, highly dynamic team (and want to measure the level of changes in the code, while trying to figure out some way to optimize those changes) or because you are making changes to a crytical system already in production, and want to keep track of what developers really did. (the next step would be to convince the developers to write useful, optional, comments for their changes).

Have you ever had to track all your changes manually (with comments) into an Excel File? 
Well I had, and classify it as dangerously boring, self-depressing, and probably the first step into the abiss (or out of the room) (of course, if there is an alternative and you keep doing it, then you might go on and just pretend you don't enjoy masochism)

This option is very useful and needed in my opinion.

additionals:

- Wrap commands of different espaces together when creating a   Solution.

- Overview of changes by eSpace in ServiceCenter.

- Search functionality to search trough commands. This can be useful when searching for incident number for example.
It would be interesting to be able to write a comment for each new publication.
Today we do this when using the cvs or svn, in each commit we can put the number of issue related to change.
With this we have a traceability for each commit.


Merged from 'It would be interesting to be able to write a comment for each new publication.' (idea created on 2013-03-21 20:13:04 by Pedro Luiz Cesar Gonçalves Bezerra Filho), on 2013-04-04 16:09:41 by Gonçalo Borrêga
2016-04-21 20-09-55
J.
mvp_badge
MVP
is this not the same as : https://www.outsystems.com/ideas/70/check-in-comments/

Merged from 'It would be interesting to be able to write a comment for each new publication.' (idea created on 2013-03-21 20:13:04 by Pedro Luiz Cesar Gonçalves Bezerra Filho), on 2013-04-04 16:09:41 by Gonçalo Borrêga
2016-04-21 20-09-55
J.
mvp_badge
MVP
Oh thy edit-button, How I miss thee!!

Since I cannot edit the post, here is another go only with a proper link now: https://www.outsystems.com/ideas/70/check-in-comments/



Merged from 'It would be interesting to be able to write a comment for each new publication.' (idea created on 2013-03-21 20:13:04 by Pedro Luiz Cesar Gonçalves Bezerra Filho), on 2013-04-04 16:09:41 by Gonçalo Borrêga
This discussion is the closest to what I found when looking for a way to generate *release notes* automatically after deploying a new version. In another set up, I have been used to giving a Jira issue number as the check-in comment and then the build system labels the issues in Jira with the build number. Similar functionality would be very handy, since customers always ask "what has changed".

In short: please add check-in comments and go a step further so that this can be used for generating release notes.
In Service Studio, it would be helpful to allow user to add comments/notes before uploading or publishing the app. This comments field should be stored with the uploaded version. It should be visible to user in "Version History"(Service Center) and in "Compare and Merge with Another Version or File"(Service Studio).  This way, user and his team will know the important notes/comments about a specific version if they want to rollback to it. This comment field should not be less than 500 characters long.  

Merged from 'Allow user to add comments before uploading/publishing' (idea created on 2015-09-18 05:00:11 by Peter Areewatanakul), on 2015-09-19 08:09:20 by Goncalo Borrega
2016-04-21 20-09-55
J.
mvp_badge
MVP
similar to https://www.outsystems.com/ideas/70/check-in-comments

Merged from 'Allow user to add comments before uploading/publishing' (idea created on 2015-09-18 05:00:11 by Peter Areewatanakul), on 2015-09-19 08:09:21 by Goncalo Borrega
Another vote for this - surprised this basic functionality is not available as of yet 
Really missing that.
It would be useful to be able to have to option to add version comments at the beginning publishing cycle. Something similar to the Changesets of Team Foundation Server (TFS) within the Microsoft Visual Studio IDE. In my company, we sometimes have 2 or more developers making modifications to the same project at the same time. If someone breaks something, it would be helpful to have some idea what they were working on. The version number, change date, and changed by are rather sparse. Especially when you have over 1,000 publishes in a short period of time.

Merged from '1-Click Publish - Ability to Add Version Comments' (idea created on 2016-02-29 19:03:03 by Daryl Van Johnson), on 2016-03-01 08:43:48 by Goncalo Borrega

Kinda curious about why Outsystems haven't added this option. It is a must in any version control system.

Currently it is very hard to identify a set of changes made in the past when trying to track down an issue.
There may have been hundreds of these 1-Click publish events between deployments. It seems that you can only add comments at deployment time.
#MissingRealisticSourceControl



Merged from 'Add revision comment to the 1-Click Publish feature' (idea created on 2017-02-01 20:36:07 by Anthony Sitterly), on 2017-02-02 08:55:28 by André Vieira
2019-11-12 17-31-26
Justin James
mvp_badge
MVP

This is a duplicate of an Idea that gets posted up fairly frequently it seems.

J.Ja



Merged from 'Add revision comment to the 1-Click Publish feature' (idea created on 2017-02-01 20:36:07 by Anthony Sitterly), on 2017-02-02 08:55:28 by André Vieira

I think the title says it all.

When you publish an oml, you must deploy a non-mandatory message field, which allows the developer to briefly identify the changes that he made, and later become available in the different versions of eSpace on service center.

I currently have a workaround, by changing the oml description whenever I make a change that I want to be identified in the service center.



Merged from 'Publishing comments' (idea created on 2017-02-11 20:48:59 by Alex.), on 2017-02-12 21:25:36 by André Vieira
2016-04-21 20-09-55
J.
mvp_badge
MVP

roughly the same as https://www.outsystems.com/ideas/70/check-in-comments




Merged from 'Publishing comments' (idea created on 2017-02-11 20:48:59 by Alex.), on 2017-02-12 21:25:36 by André Vieira

Yes it would be great if we can enter check-in comments when publish. It can be optional but atleast the developers have a means to write comments on why there were changes and indicate the story number for the changes

This would be useful.

Give the option to add names to a version you publish or have published before so you can look back to what you've changed in that version. 

This makes it easier to use the version system like some sort of version control.



Merged from 'Giving names to published versions' (idea created on 2017-10-03 12:56:13 by Alexander van Doorn), on 2017-10-06 14:38:51 by J.

Wouldn't that be the same as this idea https://www.outsystems.com/ideas/70/check-in-comments ?



Merged from 'Giving names to published versions' (idea created on 2017-10-03 12:56:13 by Alexander van Doorn), on 2017-10-06 14:38:51 by J.

Yap, agree. Probably the same problem with two slightly different solutions ;)



Merged from 'Giving names to published versions' (idea created on 2017-10-03 12:56:13 by Alexander van Doorn), on 2017-10-06 14:38:51 by J.

Yes, you're right. I didn't see that idea before posting this :)



Merged from 'Giving names to published versions' (idea created on 2017-10-03 12:56:13 by Alexander van Doorn), on 2017-10-06 14:38:51 by J.
2016-04-21 20-09-55
J.
mvp_badge
MVP

@alexander merged the idea

We would definitely need something like this.

I am also missing ability to OPTIONALLY comment version on publish time. (Sometimes would be nice to have that possibility also after publish.) Then you don't need to guess-open-publish multiple versions to find the correct version.

É uma observação considerável!

É uma observação considerável!

É uma observação considerável!

It is a considerable observation.

2020-03-13 12-09-25
Johan den Ouden
mvp_badge
MVP

This is a good idea. I miss this option too.

Good to have, any comment from Outsystems about his?

It would be good to have an easily exposed or visible audit of who changed an action (and or page and or entity) and how.  

Some rough ideas:

Ideally implement a generic global to-do list to control what work gets done by a team, this allow the developer to link the to-do/job to a development change in the action.  

Allow the developers/project managers to group to-dos into sprints/versions and allocate them to developers. Audit the changes as we code.  

Show these change audits in the actions they were created in, show them aggregated to the eSpaces they were coded in, and also allow them to be viewed from the to-do list, so you can see what changes affected an action from a number of different angles.  

Create an aggregate of undocumented changes for the current sprint/release.  This would include the developer making the changes and when.

So in the development platform to-do list I would see:

To-do: Project X sprint 99.99.99 assigned to DevXXXXXX: #9999 Investigate and fix the bug returning the aggregate of users logging in more than once, which is miscounting the numbers.

At the top right of the action flow there would be a history icon that opens a panel showing the changes with the most recent change at the top.

In the history panel you can add a change comment to the current sprint.  You might make one comment, but publish a number of times.  Changes I think should aggregate to the latest change note you made. Some thought needs to be done around where a break is made.  For simplicity, work done in the same day I'd assume is the same task.

+ [your name appears automatically] [currDate()] [ToDo#] Type a comment.

If a change is made but not annotated then you will see:

+ [your name appears automatically] [currDate()] Added n actions, changed n actions, deleted n actions.
  

For brevity these messages are aggregated into a day's work for each developer who "touches" the code.

This audit would allow release notes to be created, filtered for detail.  For the management level you might only show the to-do and unallocated changes.  However to get finer detail on all changes for a sprint would be great.  Undocumented changes would be very useful for audit - in the case of mitigating the risk of fraud or tracking down competency issues.

Some automated notes/audits are better than none.

Unfortunately I am seeing more and more audit questions around tracking what developers are doing.  Having some reliable audit of the changes made would be a great thing to just give them!


Simple to use and unobtrusive is perhaps the best starting point.


2020-03-13 12-09-25
Johan den Ouden
mvp_badge
MVP

Hi Richard,

I think you should make a new idea for that. I like the idea but that's too big for this idea.

2015-12-22 20-48-25
Bill Brady
Staff
It would be handy to be able to add a note to an individual version of an eSpace published to DEV, so that developers working on the same eSpace would have a better idea of the changes made by thier peers, to any given version of the eSpace.

Most of us publish to DEV countless times in a day, and determining the version of an earlier eSpace that you want to rollback to, isn't always easy.

Merged from 'Adding comments to eSpaces published to DEV.' (idea created on 2014-08-13 20:01:29 by Bill Brady), on 2018-01-30 13:11:29 by Vasco Pessanha
2022-09-05 17-58-21
Matthias Preuter
mvp_badge
MVP
is something like this (with 193 Likes!)

Merged from 'Adding comments to eSpaces published to DEV.' (idea created on 2014-08-13 20:01:29 by Bill Brady), on 2018-01-30 13:11:29 by Vasco Pessanha
Everyone in my bootcamp wanted this

Merged from 'Adding comments to eSpaces published to DEV.' (idea created on 2014-08-13 20:01:29 by Bill Brady), on 2018-01-30 13:11:29 by Vasco Pessanha
2016-11-21 23-23-05
Gonçalo Borrêga
Merged this idea with 'It would be interesting to be able to write a comment for each new publication.' (created on 2013-03-21 20:13:04 by Pedro Luiz Cesar Gonçalves Bezerra Filho)
UserImage.jpg
Neil Thomas

Cannot state enough how useful this would be to allow proper version control and allow you to go back to specific versions!!

Merged this idea with 'Add a description in a new publication' (created on 19 Jul 2018 14:53:47 by Paulo Cação)

It can be interesting if developer have the ability to add a description in his publications. 


For example: 

- "Create/update Movie form" -> Publish

- "Fix button add comment" -> Publish

...... etc etc


After that, the developer will be able to see this descriptions in the publications list, with the capacity to analyze the publications faster and easier.



Merged from 'Add a description in a new publication' (idea created on 19 Jul 2018 14:53:47 by Paulo Cação), on 19 Jul 2018 16:21:17 by Vasco Pessanha
Merged this idea with 'Way to view/research Deployment notes' (created on 31 Oct 2018 14:20:04 by Maycon Oleczinski)

We have already had the need to consult the deployment notes, because we inform into about the adjustments and/or improvements of the version.

I have not found a user friendly interface anywhere.


A screen could be created for this in SC or LT.
Plus: filter for research can be usefull too.



This comment was:
- originally posted on idea 'Way to view/research Deployment notes' (created on 31 Oct 2018 by Maycon Oleczinski)
- merged to idea 'Check-in comments' on 31 Dec 2018 09:58:39 by Vasco Pessanha

Very surprised that it has not been realized even after years since the first post.

I'd like to know why this idea is not adopted.

It's about time to implement this idea, I would say. As Tiago stated above, it is important for the developer to state WHY he made the changes (see: Commit Message Guidelines, How To Write a Git Commit Message)

In addition, if the team is using an issue tracking system, there should be a reference in the check-in comment to the issue the developer is working on. This reference could be just plain text or, better yet, a link to the issue.

As other have mentioned, adding a comment section while publishing your changes should be the number 1 priority. Adding an optional text field for developer comments while publishing your codes may not seem like a ´cool´feature but it is something very very practical and plain useful.  Please prioritize this feature.

Merged this idea with 'Comment in publish' (created on 01 Aug 2019 18:13:51 by Lucas Souza)

The ability to add a comment on posts. To make it easier to find them.



This comment was:
- originally posted on idea 'Comment in publish' (created on 01 Aug 2019 by Lucas Souza)
- merged to idea 'Check-in comments' on 14 Aug 2019 15:45:39 by Magda Pereira
Merged this idea with 'Publish Notes' (created on 08 Sep 2019 13:15:10 by Abduljabbar Salim)

First of all, kudos on the great product. We are no more using our TFS / Software Configuration Management. But, when we go back down the line we forget why was this change made and for what. Should be really great if you guys can give us the option to log Publish Notes / Comments which will remind us what all changes we did, why we did this change and against what requirement.



This comment was:
- originally posted on idea 'Publish Notes' (created on 08 Sep 2019 by Abduljabbar Salim)
- merged to idea 'Check-in comments' on 09 Sep 2019 12:22:50 by Magda Pereira
Merged this idea with 'Adding change notes when you are publishing' (created on 22 Nov 2019 11:45:23 by Vitor David)

The idea is adding new field non mandatory when you are publishing to write what you changed.


If you are working by yourself its ok, you know what changes you did. But if you are working with a team and everytime someone publish something there is really no way to know what was published and whenever you are trying to open the version history of a certain module you just know the version, when was changed, by whom and if its published, not giving us much information to what exactly was changed, that is when the change notes of the user come handy, soo we have a certain history that we can follow.



This comment was:
- originally posted on idea 'Adding change notes when you are publishing' (created on 22 Nov 2019 by Vitor David)
- merged to idea 'Check-in comments' on 22 Nov 2019 14:46:35 by Rita Tomé
Merged this idea with 'Possibility to add notes when publishing a Module' (created on 22 Nov 2019 14:52:14 by Luís Reis)

Similar to lifetime, it should be possible to add notes when we publish a module so that If we need to rollback versions of that module or even if we're just searching for something that was changed/deleted in a past version, it's far easier to know when to rollback to. 



This comment was:
- originally posted on idea 'Possibility to add notes when publishing a Module' (created on 22 Nov 2019 by Luís Reis)
- merged to idea 'Check-in comments' on 04 Dec 2019 10:17:34 by Magda Pereira

IMHO at least having the possibility to Add a comment to each Publish and then a way to view and search these comments would be a good starting point.

2019-11-12 17-31-26
Justin James
mvp_badge
MVP
Merged this idea with 'Comment on what was changed when publishing a module' (created on 12 Mar 2020 23:06:33 by Eduardo Sousa Sales Rodrigues)


I would like the option to comment on a publication, as on Github. It would help to find which old version to open, knowing what has changed in it.

And show that comment in the version lists of the modules.



This comment was:
- originally posted on idea 'Comment on what was changed when publishing a module' (created on 12 Mar 2020 by Eduardo Sousa Sales Rodrigues)
- merged to idea 'Check-in comments' on 13 Mar 2020 23:23:16 by Justin James

+1 



This comment was:
- originally posted on idea 'Comment on what was changed when publishing a module' (created on 12 Mar 2020 by Eduardo Sousa Sales Rodrigues)
- merged to idea 'Check-in comments' on 13 Mar 2020 23:23:16 by Justin James


Eduardo

I think is a good idea, but I already propose something similar. Consider Merge it.


https://www.outsystems.com/ideas/1785/description-notes-in-the-version-list?IsFromAdvancedSearch=True


Regards




This comment was:
- originally posted on idea 'Comment on what was changed when publishing a module' (created on 12 Mar 2020 by Eduardo Sousa Sales Rodrigues)
- merged to idea 'Check-in comments' on 13 Mar 2020 23:23:16 by Justin James
Merged this idea with 'Description Notes in the Version List' (created on 17 Nov 2014 06:55:05 by Alberto Ferreira)
I would be nice if in the version list, besides the date of upload or publish, we could add some small comments.

This comment was:
- originally posted on idea 'Description Notes in the Version List' (created on 17 Nov 2014 by Alberto Ferreira)
- merged to idea 'Check-in comments' on 27 Mar 2020 21:26:17 by Tiago Simões
Something like this. A new column where we can write some notes



This comment was:
- originally posted on idea 'Description Notes in the Version List' (created on 17 Nov 2014 by Alberto Ferreira)
- merged to idea 'Check-in comments' on 27 Mar 2020 21:26:17 by Tiago Simões
The notes could be introduced when we publish or  upload the work, as optional

This comment was:
- originally posted on idea 'Description Notes in the Version List' (created on 17 Nov 2014 by Alberto Ferreira)
- merged to idea 'Check-in comments' on 27 Mar 2020 21:26:17 by Tiago Simões

I love the idea. I'd be very useful especially for larger teams. 



This comment was:
- originally posted on idea 'Description Notes in the Version List' (created on 17 Nov 2014 by Alberto Ferreira)
- merged to idea 'Check-in comments' on 27 Mar 2020 21:26:17 by Tiago Simões
2018-08-26 20-34-32
Pankaj pant
Champion

My vote for this idea.



This comment was:
- originally posted on idea 'Description Notes in the Version List' (created on 17 Nov 2014 by Alberto Ferreira)
- merged to idea 'Check-in comments' on 27 Mar 2020 21:26:17 by Tiago Simões
2021-04-09 11-42-43
assif_tiger
Champion

Would be an Add-on in the Feature :)



This comment was:
- originally posted on idea 'Description Notes in the Version List' (created on 17 Nov 2014 by Alberto Ferreira)
- merged to idea 'Check-in comments' on 27 Mar 2020 21:26:17 by Tiago Simões

It's very much like a commit message and must be there integrated with OutSystems One-Click publish.



This comment was:
- originally posted on idea 'Description Notes in the Version List' (created on 17 Nov 2014 by Alberto Ferreira)
- merged to idea 'Check-in comments' on 27 Mar 2020 21:26:17 by Tiago Simões

This really needs to be done, in all other versioning you can add comments while making a commit, pushing or merging, why can you not do this when publishing? its the same thing and would make tracking via Jira or, giot or bitbucket much much easier



This comment was:
- originally posted on idea 'Description Notes in the Version List' (created on 17 Nov 2014 by Alberto Ferreira)
- merged to idea 'Check-in comments' on 27 Mar 2020 21:26:17 by Tiago Simões

Platform developers sincerely do not understand their customers and it is upsetting. To pay such money for the enterprise of the decision and then to suffer with the curve repository



This comment was:
- originally posted on idea 'Description Notes in the Version List' (created on 17 Nov 2014 by Alberto Ferreira)
- merged to idea 'Check-in comments' on 27 Mar 2020 21:26:17 by Tiago Simões

They live in a world that is far from reality, if they have not yet implemented such a simple and necessary thing as commit comments. It's terrible.



This comment was:
- originally posted on idea 'Description Notes in the Version List' (created on 17 Nov 2014 by Alberto Ferreira)
- merged to idea 'Check-in comments' on 27 Mar 2020 21:26:17 by Tiago Simões
2019-11-12 17-31-26
Justin James
mvp_badge
MVP

Can I merge this Idea into this one: https://www.outsystems.com/ideas/70/ ?

J.Ja



This comment was:
- originally posted on idea 'Description Notes in the Version List' (created on 17 Nov 2014 by Alberto Ferreira)
- merged to idea 'Check-in comments' on 27 Mar 2020 21:26:17 by Tiago Simões
2022-11-17 11-29-37
Carlos Lessa
Champion

good idea!!!

Quite a long post, but still with many interested folks :D 

In my latest projects I've been successfully working with a new approach to application commits: everytime a developer ends his work the involved applications get tagged with the respective project issue number and a brief description. This is not left to the deployment stage but instead everytime work is completed on an assigned task. What we are just missing now is linking Lifetime Application Version Tag feature with a Developer's Service Studio 1CP, optionally. This idea is fully detailed in https://www.outsystems.com/ideas/8213/integrate-auto-tagging-of-application-versions-including-description-from-service - check it out!

Lifetime and tagging at the application level - very bad idea. Tagging must be at espace level before publish. 

2019-11-12 17-31-26
Justin James
mvp_badge
MVP

Pedro -

You're tagging work for Feature A, meanwhile a developer doing bug fixes is halfway done and their work is getting tagged for release as well. It isn't *just* that this needs to happen on a per-module basis as Sergey points out, not per-application, it's that people need to keep their work out of the release stream until it's ready for release. This is not something I would recommend.

J.Ja

Justin, 

what you described is classic development using git branches.

Unfortunately, this approach doesn't work in outsystems. No feature branches.

We have a common app with 15 espace. Including one module with about 4000 entities. This app is used by about 50 other apps and 60 developers who are developing new functionality in these apps. Tagging at the application level causes chaos. And deploy on the production environment for applications just turns into hell.

2019-11-12 17-31-26
Justin James
mvp_badge
MVP

Sergey -

Yes, that kind of branching is desperately needed for larger factories as well.

I'm actually working on an app now that basically rides on top of publishes and when someone publishes asks them to provide details and optionally tie to a Jira ticket.

J.Ja

Hi Justin, Sergei, thanks for replying. I do see some limitations with my suggested approach for larger factories, but at the same time, I also see some extreme cases being described here that perhaps beg other solutions. Read along, please.


Regarding the scenario Justin described, it's precisely because we should not just tag an Application Version when we go for deployment, but every time a developer ends his assigned task, that I recommend my above approach: this already improves traceability of business requirements down to the code, to a reasonable degree. The kind of Applications I'm talking about here use the OutSystems typical composition (i.e. aggregating code modules into a Core Services app, or end-user modules into End-User Layer app, etc.) - this helps avoiding a high number of developers on the same app.


I also totally agree with Justin that it would be beneficial to have such "commit-messages" visible at a module's level, but until we don't have that possibility, maybe the suggested approach already brings some advantages, if the straightforward one is harder to implement.


Also, the suggested approach (of using Lifetime Application Version Tags to trace development of business requirements) does not intend to tackle branching at all: this should be avoided, if possible, in OutSystems [since the product does not support it, as Sergei well mentioned above], or tackled with other means: e.g. feature flagging/toggling, if branching cannot indeed be avoided. This approach only solely attempts to resolve the traceability matter (e.g. where was this JIRA# developed in the application version history/single trunk?)


Sergei, regarding your scenario, any sane reason why you have to deal with a module with 4,000 entities? Could those be broken down by some feasible means (e.g. functionally)? This would certainly help to keep track of different development tracks (branches, if you will) in the application... perhaps this would be a good discussion to have in another (community forum) thread, though. 

2019-11-12 17-31-26
Justin James
mvp_badge
MVP

Pedro -

Tagging also makes "delete old versions" find many less items that can be deleted, *also* a problem.

Yes, feature flagging is the only option right now. It's something I *personally* don't mind. The overwhelming majority of OS users and potential customers reject it as an option. Regardless of what my feelings are on the subject, it's not what people want. This has been a high-demand change for a long time now.

Right now I am working on a component that enables *proper* comments and labeling and tying things to Jira as well, though I am waiting to see if the check in comment system will be addressed soon and how it is addressed if it is.

J.Ja

2016-04-22 00-29-45
Nuno Reis
mvp_badge
MVP
Merged this idea with 'Adding comment on every published versions' (created on 12 Jun 2020 19:14:13 by Marco Sacay)

I think it is a best practice where we are aware about the details of every publish we made. Creating this option will help our team to know and track information of each publishes.

This is ideal before clicking publish button. or maybe can modify later on.




This comment was:
- originally posted on idea 'Adding comment on every published versions' (created on 12 Jun 2020 by Marco Sacay)
- merged to idea 'Check-in comments' on 16 Jun 2020 00:10:51 by Nuno Reis

Marco the idea is good, but it was already sugested.


Consider to merge it.


https://www.outsystems.com/ideas/70/check-in-comments?IsFromAdvancedSearch=True

Regards



This comment was:
- originally posted on idea 'Adding comment on every published versions' (created on 12 Jun 2020 by Marco Sacay)
- merged to idea 'Check-in comments' on 16 Jun 2020 00:10:51 by Nuno Reis

Justin, thanks for replying once again: I was not aware that tagging also makes "delete old versions" find many less items that can be deleted... sorry, but isn't this related to Solution versioning? I find that odd to occur, honestly, since application tagging occurs at a different system data model (or at least different entities e.g. Application, Application_Module) than the ones bound to "delete old versions" feature in Service Center (i.e. Espace_Version and Solution_Version).


Looking forward to get to know that component, myself often struggling with JIRA and business requirement traceability, too. Let me know if I can help!

2019-11-12 17-31-26
Justin James
mvp_badge
MVP

Pedro -

Yesterday I was deleting old versions in an environment, it told me there were 6000+ versions that couldn't be deleted because they were tagged, and there are only 3 or 4 solutions and each one only had 2 - 3 versions. Lifetime uses Solutions under the hood. So I think what's happening is Lifetime is marking things so that you can't delete the Modules.

The whole system is really in bad shape. With the 100 GB limit in cloud DEV environments and no bytewise comparison on the versions of of modules thanks to encryption & compression... most active environments can't keep more than a few weeks of versions and at the same time removing them is a hassle.

It needs a rework from top to bottom. :(

J.Ja

Hi Pedro.
>>Sergei, regarding your scenario, any sane reason why you have to deal with a module with 4,000 entities? Could those be broken down by some feasible means (e.g. functionally)? This would certainly help to keep track of different development tracks (branches, if you will) in the application... perhaps this would be a good discussion to have in another (community forum) thread, though. 


Historically, this module was the first to be developed by the first team. Then there were more than one teams. Now there are 25 of them. More than half of them use Entity, which is in this General large module. The list of consumed dependencies of this module is close to 200. For example, you can't make 25 tables with clients. There must be one table. This is how the 4000 entity runs in the module. We wanted to redo it and divide it into modules, but it turned out that the list of dependencies and table usage is so large, and the tables are so interconnected, that it is impossible for each team to develop its own functionality without stopping.

For example, there can be up to 10,000 places where a single shared table can be used in a single module. Multiply by an average of 15 teams that use the table, and we get the inability to redo the code.

Every code change (refactoring) must be tested, so in addition to the developer's work, there is a lot of work for testers.

Hi Justin James, sorry for the delay in getting back to this thread, but I had to double-check your described scenario of Lifetime tagging affecting removal of old module versions - I was not at all expecting this behavior, sorry! The good news is that there is already a solution for that (just hope you and other fellow community members have compatible platform versions) - OutSystems Support replied me the following:


...is it really true that LifeTime Application Tagging affects deleting old versions?

The answer is yes. Let me elaborate a bit more on this topic since deleting old eSpace versions can be affected by mainly by:

  1. Solutions- If you do have old solutions that reference old eSpace versions then, those specific eSpace versions are bond to those existing solutions, and, due to that, you won't be able to delete the eSpace versions. In order to delete them, first, you will need to delete the Solutions that contain them.
  2. LifeTime tags- Tags in LifeTime, can be blocking some versions from being deleted just like the Solutions do. Since the LifeTime Release Feb.2019 version it's possible to delete application versions (LifeTime tags) using the new method of LifeTime API v2.
    DELETE 
    /applications/{ApplicationKey}/versions/{VersionKey}/
    Using this API method you can delete selected tagged versions, so you can then retry the deletion process. In order for you to have more context about this API please consider the following article here
    • Don't forget to follow the guidelines presented in REST API Authentication to authenticate your API requests. As already stated once you implement some logic to release the Tagged Versions it should be possible to Delete the versions of the modules bond to those tags.
2019-11-12 17-31-26
Justin James
mvp_badge
MVP

Pedro -

No worries! But Service Studio most definitely does not use that API (because it skips tons of versions to delete), and I suspect DB Cleaner and DB Cleaner on Steroids don't do it either, don't have time to dig through the code right now... but the big point is that the system-provided tools for killing old versions is basically broken by tagging. And with only 100 GB in OS PaaS non-PROD... it usually takes a team on a project 1 - 3 months to fill the non-PROD DB.

J.Ja

Hi!

I would like to add some more information from my experience regarding deleting old versions of espaces.

There are many things that can prevent an old version of an espace from being deleted successfully (undeleted entities, undeleted timers, undeleted site properties, etc) but two main reasons are:

1) Versions of solutions;

2) Tags of applications.

Regarding solutions, to be more precise, you do not need to delete the solutions, you need to delete the versions of the solutions.

In particular there is one system solution "OSMonthlySnapshot" that at the first day month of each month gets a new version created, so you will most likely need to delete old versions of this solution to be able to delete old versions of espaces.

Regarding applications, and assuming that you have LifeTime installed on its own separate environment, you do not need to use LifeTime API to delete application tags in LifeTime; you just need to delete the application tag from the environment that you want to delete the old versions of espaces, normally the Development environment. I have found that LifeTime keeps its own tags of applications in its own metamodel.

To delete application tags in the environment you can simply use DBCleaner, menu Applications.

Take the example below for the application "Silk UI Web" where in LifeTime it still exists all all tags, but in the Development environment the tags 3.3.0 and 3.3.2 have been deleted.


--Tiago Bernardo

2019-11-12 17-31-26
Justin James
mvp_badge
MVP
Merged this idea with 'Service studio: Version name option during publish' (created on 02 Jul 2020 18:47:11 by Ali Amin)

Option to name version during or after publish.


Idea is provide a custom name with possible short description to help in identifying the changes done  in publish.

it should be optional. And it could be simple text box near to publish button.


Cheers,

Ali Amin




This comment was:
- originally posted on idea 'Service studio: Version name option during publish' (created on 02 Jul 2020 by Ali Amin)
- merged to idea 'Check-in comments' on 04 Jul 2020 20:23:30 by Justin James
2019-11-12 17-31-26
Justin James
mvp_badge
MVP
Merged this idea with 'Ability to add comments/notes while publishing a version' (created on 09 Jul 2020 16:54:32 by Vaibhav)

Sometimes a developer wants to have a look at the changes made in past as part of a task but there is no easy way to figure out the exact published version number. He/she has to open each and every version to see those changes, sometimes it might take a lot of time.

To overcome this, there can be an option to add comments/notes while publishing, and those comments/notes should be visible while looking at the published versions (similar to SVN and other version control tools) 

So that, one can identify what changes were made in a particular publish or why those changes were made (task name or number  or other description can be mentioned)




This comment was:
- originally posted on idea 'Ability to add comments/notes while publishing a version' (created on 09 Jul 2020 by Vaibhav)
- merged to idea 'Check-in comments' on 10 Jul 2020 05:12:28 by Justin James

This feature becomes particularly relevant when we think of Requirement to Software traceability. Adding something like "US #XX [feature name]" to a publish message can be extremely usefull when trying to figure out where and when some US was implemented.

2019-11-12 17-31-26
Justin James
mvp_badge
MVP
Merged this idea with 'Comments When Publishing' (created on 18 Aug 2020 15:46:09 by Luis Dinis)

For us Developers it will be useful if we can have the possibility to add one comment when publishing an espace, for version control purposes.


So we can see the versions published and one comment for each.


Thanks in advance,

Luís Dinis



This comment was:
- originally posted on idea 'Comments When Publishing' (created on 18 Aug 2020 by Luis Dinis)
- merged to idea 'Check-in comments' on 24 Aug 2020 03:51:15 by Justin James

Hi Luís, believe something similar has been requested at - https://www.outsystems.com/ideas/70/check-in-comments (other similar requests have been merged on that thread, too) - but do feel free to explore the discussion there and bring new insights!



This comment was:
- originally posted on idea 'Comments When Publishing' (created on 18 Aug 2020 by Luis Dinis)
- merged to idea 'Check-in comments' on 24 Aug 2020 03:51:15 by Justin James
2019-11-12 17-31-26
Justin James
mvp_badge
MVP
Merged this idea with 'Provision to enter short description while committing changes in Service Studio' (created on 16 Dec 2020 15:21:08 by Sughosh Deshpande)

While committing changes in service studio there should a provision to enter short note/description/comment. Entering the comments will be helpful for tracking the changes. The comment section should be pre-populated with the last entered comment.



This comment was:
- originally posted on idea 'Provision to enter short description while committing changes in Service Studio' (created on 16 Dec 2020 by Sughosh Deshpande)
- merged to idea 'Check-in comments' on 19 Dec 2020 02:40:56 by Justin James

Similar to https://www.outsystems.com/ideas/70/check-in-comments



This comment was:
- originally posted on idea 'Provision to enter short description while committing changes in Service Studio' (created on 16 Dec 2020 by Sughosh Deshpande)
- merged to idea 'Check-in comments' on 19 Dec 2020 02:40:56 by Justin James
2019-11-12 17-31-26
Justin James
mvp_badge
MVP
Merged this idea with 'Describe published version (Commits)' (created on 13 Mar 2021 16:40:59 by Ahmad Al-Ghzawi)

I think it would be great for developers to be able to describe the application version they are publishing...
Maybe a text field beside the "one-click publish" button would do the trick.

It would be nice to have a "description" column between "Version" and "Changed" columns when you want to check out a published version (like commits), it will be very useful...

 

Some examples:

  • Consume Service - "service Name"
  • Add Header Footer Style
  • Add validation for "form name" inside "screen name" screen


This comment was:
- originally posted on idea 'Describe published version (Commits)' (created on 13 Mar 2021 by Ahmad Al-Ghzawi)
- merged to idea 'Check-in comments' on 14 Mar 2021 03:28:55 by Justin James
2021-01-19 14-07-32
Tom Zhao
Champion

Totally agree, Also it will be nice to show what changed from the previous version.



2021-01-19 14-07-32
Tom Zhao
Champion

Totally agree, Also it will be nice to show what changed from the previous version.



2020-04-15 12-37-36
Daniël Kuhlmann
mvp_badge
MVP
Merged this idea with 'Published modules message' (created on 29 Mar 2021 11:46:39 by Mohamed Antar)

It's better to add message linked with each version  when publish module. It will help developers to know the history of the changes had done ,and  message text be optional.
like commit message in GIT.



This comment was:
- originally posted on idea 'Published modules message' (created on 29 Mar 2021 by Mohamed Antar)
- merged to idea 'Check-in comments' on 30 Mar 2021 05:09:34 by Daniël Kuhlmann
2020-04-15 12-37-36
Daniël Kuhlmann
mvp_badge
MVP

Hi Mohamed, 

A very good idea, and it should definitely be implemented. The truth however is that it is one of the oldest Ideas that exists. So I will merge yours into that one.

Regards,

Daniel



This comment was:
- originally posted on idea 'Published modules message' (created on 29 Mar 2021 by Mohamed Antar)
- merged to idea 'Check-in comments' on 30 Mar 2021 05:09:34 by Daniël Kuhlmann

It would be very useful to distinguish versions, when we are trying to open a different version and have to do a trial and error until we get the desired version.

Great idea.

2020-04-15 12-37-36
Daniël Kuhlmann
mvp_badge
MVP
Merged this idea with 'Description for each One Click Publish' (created on 01 Jun 2021 19:27:34 by Miguel Ely)

Hi Guys,


I believe it would be interesting to have the possibility to have a description for each "One Click Publish". The descriptions of each publication could be seen in the other versions tab.





This comment was:
- originally posted on idea 'Description for each One Click Publish' (created on 01 Jun 2021 by Miguel Ely)
- merged to idea 'Check-in comments' on 02 Jun 2021 04:56:20 by Daniël Kuhlmann
2020-04-15 12-37-36
Daniël Kuhlmann
mvp_badge
MVP

Very good idea, also one of the oldest on the Ideas page, so I will merge yours into that.



This comment was:
- originally posted on idea 'Description for each One Click Publish' (created on 01 Jun 2021 by Miguel Ely)
- merged to idea 'Check-in comments' on 02 Jun 2021 04:56:20 by Daniël Kuhlmann

Thanks Daniel!
I hope this will be implemented soon. 

2020-04-15 12-37-36
Daniël Kuhlmann
mvp_badge
MVP
Merged this idea with 'add comment to a publisch' (created on 21 Jun 2021 10:06:25 by Doltbum)

Is it possible to add a comment to the publisch?
This would help me find the feature that i made a couple of weeks ago.

This also forces developers te specify what they are doing. So when the project is handed over everyone can see what has been done. And when i have to roll back instead of opening every publisch to check if this is the change i want to roll back to.



This comment was:
- originally posted on idea 'add comment to a publisch' (created on 21 Jun 2021 by Doltbum)
- merged to idea 'Check-in comments' on 22 Jun 2021 05:27:44 by Daniël Kuhlmann
2019-11-12 17-31-26
Justin James
mvp_badge
MVP
Merged this idea with 'Filter + Possibility of adding a description of the changes made in each published version' (created on 18 Aug 2021 22:17:18 by Anderson!)

Wouldn't it be possible to have the possibility to add some description about the changes made in the version to be published? Considering a scenario with multiple updates in a row where someone could accidentally lose some code

And also the possibility of filtering these published versions by date / time, for example, once it is currently necessary to click multiple times to view the others - and maybe even define the number of lines / records available, since currently the limit is 10 per page



This comment was:
- originally posted on idea 'Filter + Possibility of adding a description of the changes made in each published version' (created on 18 Aug 2021 by Anderson!)
- merged to idea 'Check-in comments' on 19 Aug 2021 19:17:11 by Justin James
2019-11-12 17-31-26
Justin James
mvp_badge
MVP

Please separate this into two ideas, or edit to just one idea. There is already as single idea for code publish comments, it's got a zillion likes, and if you did not put a second idea in here about sorting/filtering on the columns, I would just merge this with the pre-existing idea for code publish comments.

Thanks!

J.Ja



This comment was:
- originally posted on idea 'Filter + Possibility of adding a description of the changes made in each published version' (created on 18 Aug 2021 by Anderson!)
- merged to idea 'Check-in comments' on 19 Aug 2021 19:17:11 by Justin James

Hello Justin! I found the discussion about the possibility of code publishing comments right now and wow, it's been over 10 years(?)! I'm going to suggest merging this part about filtering I mentioned into this pre-existing idea!


Anyway, also did a second post considering the use of filtering for the forum itself - did not find a similar idea -, so the user could search by multiple tags in the same research



It doesn't seem like it's possible to exclude our own ideas - they're just eventually marked 'out of scope' - so that's it, let's keep moving forward. Thanks!



This comment was:
- originally posted on idea 'Filter + Possibility of adding a description of the changes made in each published version' (created on 18 Aug 2021 by Anderson!)
- merged to idea 'Check-in comments' on 19 Aug 2021 19:17:11 by Justin James
2019-11-12 17-31-26
Justin James
mvp_badge
MVP

Awesome, thanks!

J.Ja



This comment was:
- originally posted on idea 'Filter + Possibility of adding a description of the changes made in each published version' (created on 18 Aug 2021 by Anderson!)
- merged to idea 'Check-in comments' on 19 Aug 2021 19:17:11 by Justin James
2019-11-12 17-31-26
Justin James
mvp_badge
MVP
Merged this idea with 'Include Note when publishing via Service Studio' (created on 24 Aug 2021 10:47:15 by rodrigo henriques)

There should be a option to include a note when publishing a new version of a module.
This would be very useful when we need to get a specific version that introduced some major changes such as:
- new webservice reference
- code refactoring
- change in business rule
- ...

My suggestion would be to introduce a new button that would prompt the user to set a note and then would publish that version with the note associated.
The notes would be visible in Service Center and Service Studio when selecting older versions to open



This comment was:
- originally posted on idea 'Include Note when publishing via Service Studio' (created on 24 Aug 2021 by rodrigo henriques)
- merged to idea 'Check-in comments' on 25 Aug 2021 03:22:09 by Justin James
2017-07-05 12-29-36
Carlos Alfaro
mvp_badge
MVP
Merged this idea with 'Version Note' (created on 25 Aug 2021 20:51:51 by Ravani)

As we publish a version at Service Studio, would be nice if Outsystems asks you if we want to add a note to de published version.

Once this functionality exists, it will help, if the note is used correctly, to find a especific change on code, for example:

Version 1 - Note: Added button 'Click Here' at the homescreen
Version2 - Note: Added function 'Navigate' to button 'Click Here'.



This comment was:
- originally posted on idea 'Version Note' (created on 25 Aug 2021 by Ravani)
- merged to idea 'Check-in comments' on 26 Aug 2021 16:32:13 by Carlos Alfaro
2020-04-15 12-37-36
Daniël Kuhlmann
mvp_badge
MVP
Merged this idea with 'Publish with message' (created on 21 Sep 2021 05:05:33 by Shanmugam Thillaigovindarajan)

It will be good if we add optional message when we are doing publish. It will be easy to identify the details if we want to roll back to older versions.



This comment was:
- originally posted on idea 'Publish with message' (created on 21 Sep 2021 by Shanmugam Thillaigovindarajan)
- merged to idea 'Check-in comments' on 22 Sep 2021 06:33:15 by Daniël Kuhlmann
2020-04-15 12-37-36
Daniël Kuhlmann
mvp_badge
MVP

Hi good idea, but it is actually one of the most old ideas still not implemented by OutSystems. So I will merge this one into it.



This comment was:
- originally posted on idea 'Publish with message' (created on 21 Sep 2021 by Shanmugam Thillaigovindarajan)
- merged to idea 'Check-in comments' on 22 Sep 2021 06:33:15 by Daniël Kuhlmann

I am amazed at how long this idea has been out there and how many upvotes it has received and it is still not implemented. I've come into an existing project which has been worked on by many people around the world, and the lack of comments in publishing makes it extremely difficult to find when and why certain elements were changed. There is also no ability to add comments on screen elements, which is also deeply disappointing and frustrating.

2016-04-21 20-09-55
J.
mvp_badge
MVP
Merged this idea with 'Option to add comment for 1 CP to track commits.' (created on 11 Jan 2022 17:16:25 by Rahul Yadav)

What do I need - Option for version tracking comment on 1CP. Just as we have for any version tracking tools available in the market, this option can appear when we click 1CP.

What can it improve - It can improve tracking and traceability for the changes. A developer can mention ticket number on any versions related to that specific feature while going for 1CP.

Who would benefit from that - It would benefit immensely to the developers to track changes related to ticket or features instead of comparing different versions for it. Right now we only have developer name, date, version number and published column when we check comparison. This especially is a pain when the buck is constantly getting exchanged between developers in a project which have persons going in and out frequently. 

Honestly, if this feature is already there I would love to know about it. I wouldn't mind if this idea was already raised earlier and this one gets merged to it. :)

Version control comments that can be linked to your ALM system too - Very handy.  Currently Jira is out ALM system of choice.

2020-04-15 12-37-36
Daniël Kuhlmann
mvp_badge
MVP
Merged this idea with 'Name module versions in Service Studio / Center' (created on 28 Jan 2022 11:37:56 by José Torrão)

Have the ability to name a module version in service studio and service center.

Right now, when I want to roll back to a previous, stable version of a module, I need to check the dates and compare against the work I have done, it would be nice to name a module version a specific name, like for example (dev example): "Version with sql fix 1 working"

It would also be great if when we deploy a solution / lifetime deployment, it would automatically name that version to "Deployed with lifetime"

It would be nice to have the possibility to add comments during a check-in. Currently, I use adding a description by tagging a version in Lifetime. Sometimes changes must be made to multiple modules. 



It's a good idea.

Additionally, we could use this information when generating lifetime tags (timeline). And analyzing these values would make it easier and more effective to fill in the description at the time of the tag.

2020-04-15 12-37-36
Daniël Kuhlmann
mvp_badge
MVP
Merged this idea with 'Possibility to add a message when publishing an application' (created on 14 Apr 2022 10:08:56 by Kadir Özcan)

It would be nice to have the option to provide a message when publishing an application. One example scenario when this is useful is e.g. when viewing the versions history of an application.


2020-04-15 12-37-36
Daniël Kuhlmann
mvp_badge
MVP
Merged this idea with 'Add optional Title/Comments on 1CP' (created on 24 May 2022 09:58:39 by Denys Bondarenko)

We should be able to set a Title on publish to be displayed in the "Open other version" window. Additionally, the Title could be viewed from the module's Service Center. Basically, it's extra comments on the published version.

Here's an example (with some wild colors 😃):

This would provide an overview on some important changes — you can say it's like a bird's-eye view on a module's history. Additionally, this could be useful when debugging: an issue could have popped up after a specific publish, and using the new Version Title functionality could help tracking this.

The Title should not be mandatory because often the 1CPs are small bugfixes and adjustments. This feature should be a helpful tool in the developer's toolkit, not an enforced rule.

I follow your idea. It can be very useful

But I have already seen other similar ideas. See for example:

https://www.outsystems.com/ideas/11480/adding-description-to-espace-versions/

Regards

2020-04-15 12-37-36
Daniël Kuhlmann
mvp_badge
MVP
Merged this idea with 'Add notes when pressing the 1-Click Publish' (created on 02 Aug 2022 22:30:16 by André Guerra)

So, the ideia is to have the possibility to add a note when click the "1-Click Publish" button.

The objective of that is that when we go to get other previous version (the "Open other Version" on "module" menu), we can see that notes so it will be easier to get the version we are looking for.

2020-04-15 12-37-36
Daniël Kuhlmann
mvp_badge
MVP

Hi André good idea, it is actually one of the oldest most popular ideas around (#70).

So I have to merge yours into that one.

Sorry, I haven't seen it in my search, but it is very good.

By the way, I will leave here the mockup menu sample I made for my idea submission.


2020-04-15 12-37-36
Daniël Kuhlmann
mvp_badge
MVP
Merged this idea with 'Other Version Feature' (created on 07 Oct 2022 11:21:45 by Hevert Vinicius)

a very useful improvement, it would be that when the application is published, there is the possibility of having a field that allows you to add a note of the modification you made, this makes it much easier when I select the version I want to go back, for example.

Amazing, after 12 years, almost 8000 visualizations, 160 comments and nearly 600 likes keep "on the radar" status. !!!!


2020-04-15 12-37-36
Daniël Kuhlmann
mvp_badge
MVP
Merged this idea with 'Possibility to leave a comment before publish to identify a specific change' (created on 21 Oct 2022 00:00:15 by Bruno Silva)

Possibility to leave a comment before publish to identify a specific change as we have for example in a GIT Push where we give a title that facilitates the search and deployments in specific cases where there was a certain change.

Maybe an option that can enable in the preferences to be or not mandatory to use the comment in publish.


2020-04-15 12-37-36
Daniël Kuhlmann
mvp_badge
MVP

If people only would search for ideas before posting.

This idea needs to be merged once or twice every month, as it is one of the oldest Ideas of the community. Unfortunately, still not implemented

2020-04-15 12-37-36
Daniël Kuhlmann
mvp_badge
MVP
Merged this idea with 'Comment Widget on IDE Outsystems before Publish' (created on 25 Oct 2022 14:18:31 by Italo Saraiva Goncalves)

I think comments before publishing a version would help when someone needs to recover from a previous version. As in the images below and as an example of what is applied in GITHUB commits. One column with Comments Would help a lot.

2020-04-15 12-37-36
Daniël Kuhlmann
mvp_badge
MVP

This idea is posted like 2 per month, people please search ideas first before you post, saves me a lot of merge work every time

Any update on this 12 year old idea yet? 

This idea is the result of the merger of various ideas, including one version of mine. To be honest, I don't really need this anymore. I submitted the idea before LifeTime existed and back then it was much harder to keep track of changes. With LifeTime it is possible to add a comment when tagging an application. With this you can include the issue number when tagging a new version of applications, keeping a clear overview of what was done in a version.

2020-04-15 12-37-36
Daniël Kuhlmann
mvp_badge
MVP
Merged this idea with '1-Click Publish note field' (created on 28 Dec 2022 02:17:19 by Samuel Neves)

Currently when we open the previous version popup in Service Studio we are presented with a table view of versions that are listed with Version Number, DateTime stamp, Author, and whether it's the Published version.

Whilst navigating through this, there is little clue as to what each Publication represents. It becomes specially hard with medium-large development teams, with multiple people working on the same project and its modules.

I suggest the addition of a simple non-mandatory text field to the 1CP button, so we can have notes attached to each version and see those notes in the Previous Versions popup.

while we open the preceding version popup in service Studio we're provided with a table view of versions which might be listed with model 

2020-04-15 12-37-36
Daniël Kuhlmann
mvp_badge
MVP
Merged this idea with 'Add an option by which we can add comment with the module version' (created on 24 Jan 2023 07:45:02 by Neha Sheikh)

While development if we fee that one of the module's version will be productive in future we might want to get back to that particular version or more versions of that module it will be great if we get an option to add comment with the version of modules in service center.

In Service studio as we publish more often it is not that great to add comment everytime but if the comment is important developer can go to service center and add a comment for that version. 

Yes this might be helpful