Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature suggestions #1

Open
introwit opened this issue Feb 17, 2017 · 31 comments
Open

Feature suggestions #1

introwit opened this issue Feb 17, 2017 · 31 comments

Comments

@introwit
Copy link
Contributor

Comment your feature suggestions in this thread so you and we can track, discuss & work on them

@Braunson
Copy link

Braunson commented Mar 1, 2017

It would be neat to be able to see along side the packages that are install any that have existing updates available.

Another feature that could be helpful is an adapter or event for example Bugsnag, when your app throws an fatal error (for example, could be any level of error defined by this package's config), it would include a system report with installed packages and their version.

@introwit
Copy link
Contributor Author

introwit commented Mar 1, 2017

@Braunson thank you for considering to suggest features for this package :) And yes the first feature suggested by you is been mentioned in the roadmap . Can you explain the second feature a bit more as it sounds really nice to have anything similar in the package

@Braunson
Copy link

Braunson commented Mar 1, 2017

@introwit Ah yes sorry must have read-over that on the roadmap.

As for the second feature, if I was using some type of third-party error service, such as Bugsnag it would be nice to send additional information (such as the system report decomposer provides) to Busnag with certain levels of errors (presumably this level would be set in the decomposer's config) alongside the actual error's being logged.

@introwit
Copy link
Contributor Author

introwit commented Mar 1, 2017

@Braunson ok so what I have understood is that if the user is already using an error service, every time that service logs an error it logs the system report with that error as well. Correct me if I am wrong

@ajitbohra
Copy link
Member

@introwit +1 for the feature mentioned by @Braunson good use case :)

@introwit
Copy link
Contributor Author

introwit commented Mar 2, 2017

@ajitbohra yes I agree. Waiting for @Braunson 's reply so that if he has anything in mind like how he wanted to apply this feature as a user so I can code that feature into the package the same way making its application quick & easy for users :)

@REBELinBLUE
Copy link
Contributor

REBELinBLUE commented Mar 2, 2017

How about the ability to register other checks? For example my laravel app requires certain extensions or PHP functions to be enabled, so it would be useful if they appear in the report so when people give me their install info I can see if those are there

@introwit
Copy link
Contributor Author

introwit commented Mar 2, 2017

@REBELinBLUE this seems a better use case for one of the feature added in the roadmap that allows other packages/non-decomposer stats to be added in the system report. As you suggested this would be really nice to have in the package considering your given use case, thank you Stephen for that :) Feels good when the actual users suggest things he needs. Definitely adding this feature in the coming updates, will keep you posted with the development progress on it for sure :)

@Braunson
Copy link

Braunson commented Mar 2, 2017

@introwit Yes exactly, being able to pass the system report from decomposer through to that third party :)

@introwit
Copy link
Contributor Author

introwit commented Mar 2, 2017

@Braunson seems like a very nice feature. Noted! Will keep you posted with the development progress of it for sure over here. Thanks much Braunson again :)

@xitude
Copy link

xitude commented Mar 16, 2017

Feature request: Write to Readme file so we can see them in github/bitbucket.

@introwit
Copy link
Contributor Author

@xitude can you elaborate more on this?

@xitude
Copy link

xitude commented Mar 16, 2017

@introwit, one of my biggest issues with taking over projects is keeping an eye on dependencies. If I could get it to print to the readme file so I can commit it and see it on entry to the project repo that would a life saver.

@introwit
Copy link
Contributor Author

@xitude I found it a bit overwhelming to understand with regards to the Markdown report already being generated that can be copied and used anywhere. Also in the next release you will get the feature to produce the same report & get it as an array anywhere in your code. Can you give me an example use case so that will help me to understand what exactly your need is and work on it :)

@introwit
Copy link
Contributor Author

introwit commented Mar 17, 2017

@Braunson here you go getReportArray with the v1.1 release :) , @REBELinBLUE working on adding extra checks, seems to be sorted for app users, just waiting to make it dynamic so that other package developers can add their checks as well with the same process while developing their package, any suggestions?

@ryanvade
Copy link

ryanvade commented Mar 20, 2017

A bit more elaboration on the Server OS would be useful. For example:
OS: GNU/Linux x86_64
Kernel: 4.4.0-66-generic
Distribution: Ubuntu
Version: 16.04.2
Release End of Life: April 2021
Available Updates: 15

etc

@introwit
Copy link
Contributor Author

@ryanvade first of all sorry for being late to respond was stuck in some issues. And yeah do you think all of these info will be useful for someone? Like any specific case where these info might come in handy rather than just the server name that is being displayed now?

@Shkeats
Copy link

Shkeats commented Mar 24, 2017

A great and simple feature would to serve a json response as well, this could easily be monitored by other applications and services.

@ryanvade
Copy link

@introwit I manage so many servers with different purposes and software sets that I forget what version server X is on or if updates for server Y are available. Yes these features are available on other 'management' platforms but providing view capabilities to site admins would certainly alleviate the management issues I have. With that in mind, it seems fit that I look into it. The good news is most of these features can be implemented by simply reading files (using system calls from PHP has always concerned me).

@ajitbohra
Copy link
Member

@Shkeats idea sounds interesting @introwit your thoughts

@introwit
Copy link
Contributor Author

introwit commented Mar 25, 2017

@Shkeats how can I forget the JSON response damn! Thanks for pointing it out, coming in the next release for sure, will update you :) @ryanvade makes sense, though confused how can we arrange that info in the UI. Any suggestions before I jump into it?

@introwit
Copy link
Contributor Author

introwit commented Apr 3, 2017

@Shkeats Json response is now available, hope you like it :) @Braunson @ajitbohra @REBELinBLUE @ryanvade @xitude You can now add your own personal extra stats as well if required 🎉

@ajitbohra
Copy link
Member

@introwit package is really shaping up good getting more useful with every update POWER!

@felorhik
Copy link

felorhik commented Apr 6, 2017

This would likely require extra configuration. But this is another idea.

I do find that sometimes issues, minor or major for an app might get lost as development progresses. What I mean is you may notice an issue, find / post it in the issue tracker, then forget about it since you moved on to a different section and such. For instance a Queue issue in laravel that is affecting your app, there is an issue posted in github and discussions are made, finally leading to a resolution / pull request that then closes the issue and "fixes" it.

So you could add a config file with an array that you could list like

'issues' => [
   'laravel/laravel' => '#321'
]

This would then have a section in decomposer to just show the status of that issue, is it closed? is it open? Would be useful to keep track of issues affecting your app and catch when they are resolved, for even third party packages.

This would open up the workflow that once you notice an issue, you could add it to the config, any other developers or your self will be able to see that the app is currently affected by that issue.

Really like this package, thought this would be a kind of cool addition and I can personally see a use for it, but I would be curious to see how many people might agree?

@introwit
Copy link
Contributor Author

introwit commented Apr 7, 2017

@jordanramstad Thank you for the appreciation Jordan :) This is a really cool addition as you said but I see a few complexities. Help me with your suggestions on them if possible, they are as follows:

  • I see 2 solutions out of it that are possible right now, first is subscribing to any particular issue on any GitHub repo so you get notifications & email for any activity on them that GitHub already provides. But yeah I know that you are talking in regards with Decomposer so this doesn't makes sense in this context.

  • Second, For now you may add the Issue title & link via adding your own stats that Decomposer provides out of the box so you can see that listed every time and whenever you feel you can go to that link and see the latest comment or activity on that issue thread.

  • If we specifically want to achieve what you suggested, we need to decide how the UI would look for it so it comes in as actually useful & need cron jobs for it as well. Any suggestions about how should we go about these 2 things if we implement it?

@felorhik
Copy link

felorhik commented Apr 7, 2017

@introwit The idea is to give a quick notice, decomposer is meant to help with debugging or making issues. If an issue affects the app, and another developer comes it, notices the problem and plans to go to the repo to possibly add an issue, then the fact that decomposer already has a note of it and if the related issue is closed or not would save a lot of time. Github API should only really need to do 1 request per issue to just check its current status. If the status of the issue is closed, and the issue is still there, then it opens up the thought to check the version used in the composer.json and check if the issue has been fixed in a release.

Yes a simple link would work though in most cases and if that is enough that is fine. I thought this could be a cool idea but I do understand an extra feature like this might find little actual use, on paper I feel it seems good but then there is how well it translates to actual use.

As for UI it would likely just be a panel with a list, showing the title and a checkmark or cross to denote if its closed or open. I don't think cron jobs are needed though, its doubtful hundreds of issues would be added in any application, I get at most maybe 5 over the course of making an application personally.

@introwit
Copy link
Contributor Author

introwit commented Apr 9, 2017

@jordanramstad I agree on all the points you listed. Exploring and playing with the idea locally, will keep you posted about the development progress & problems around it for sure :) Thanks Jordan for taking your time and suggesting & discussing things that can make the package more useful 🍻

@sbramley
Copy link

sbramley commented May 9, 2017

I feel like it would be great to see the actual version and hash installed from the composer.lock file. We have a few dependencies that use a wild card for patch versions but knowing what version is on prod vs staging would be helpful.

@introwit
Copy link
Contributor Author

@sbramley Thanks Sam , definitely adding to the list :) If you can just hit with a PR if possible as the roadmap is really getting long to work on alone 😅 Nevertheless the point is really good and will add this feature for sure.

@sbramley
Copy link

sbramley commented Dec 5, 2017

Hey mate, just dropped a PR into you. Let me know what you need me to add or fix, it's my first time 👍

@TheZachh
Copy link

TheZachh commented Mar 6, 2019

A search feature would be great. As well as an upgrade to Bootstrap 4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants