The removal of certain functionality from NearBeach

The following modules are being removed from NearBeach;

  1. Opportunities
  2. Quotes and Invoices

We currently feel that they do not fit within the new NearBeach’s project management system, as they are more LEAD generating. We will toil with the idea of bringing them back into NearBeach in some capacity.

Development Alpha 0.27.3 released

The newest version can be found on PyPI. Please note it is not backwards compatible with the 0.26 branch.

Release 0.27.0 – Broken and back to Alpha

It has been 3 months since we started doing the refactoring/rewrite of NearBeach. A lot of work has gone into completing just 1 object. When the release candidate (RC 1) comes out this week, it will only focus on “Requirements” object.

Why are we releasing this as an unfinished product?

Good question – we actually want to;

  1. Show the work completed so far,
  2. Get feedback on this work before we apply the changes to the other sections of the code.

Why are the other objects and components disabled?

We really didn’t want the site to have both “New/Old” themes on it. We are focusing on only one section of the code.

What objects will be applied next?

The following is a simplified road map

  1. Release Candidate 1 – Requirements
  2. Release Candidate 2 – Requirement Items
  3. Release Candidate 3 – Organisations/Customers
  4. Release Candidate 4 – Projects
  5. Release Candidate 5 – Tasks

We are hoping to have the majority of this completed well before the year’s end. We are hoping all the hard work that we have applied at the requirements object, will be transferable to the other sections.

Will this release be buggy? Should I use it?

This release will be buggy – we are only releasing it to get feedback on the UI/UX. We are also going to test it thoroughly as many of the functions within it will be utilised in the other objects, i.e. projects, tasks. We will NOT recommend using it for any production environment.

If you end up using it for testing purposes and find any issues, please submit a ticket at https://bugzilla.nearbeach.org

Almost finish part 1 of the refactoring

It should be noted that this has been more of a code re-write. Only small sections of the code have come through untouched. Recent fixed to the models.py has lead me to rewrite all the migration files again, which means we will not be able to allow upgrades from 0.26.2 to later versions. We will work with anyone to help update in this situation.

We will be doing another release soon, however a lot of the functionality of NearBeach has been stripped out. The next releases afterwards will be focusing on putting that functionality back in.

NearBeach will be getting some help from another developer, which is exciting news for us. They will be helping with constructing the new objects and help document everything.

I am hoping to have more information by the end of the weekend.

Refactoring NearBeach Part II

I have said this multiple times, design is not my strong suit. I have sought multiple feedback at different times to determine if I am heading in the correct direction.

We have only been focusing on one small component first. Focusing on fixing all the issues with this small component first will hopefully speed up the process of constructing other pages.

Refactoring NearBeach

In the last year and a half I finally took a web development job full time. In that time I have learned a lot of new technologies like Webpack, VueJS, D3 etc. I am now turning around and seeing that I can improve NearBeach tenfold by applying what I have learned.

The majority of the issues left with NearBeach revolve around the UI/UX, and code base that I can improve. For example I can structure NearBeach a lot better – so the code flows a lot nicer and it becomes easier to program for.

Here are good examples of this are;

  1. view.py file currently sits at being 10711 lines long. Finding sections within that code takes time.
  2. Some forms are overly complex, i.e. the quote line items, and are becoming harder to fix any bugs or issues associated with them. Without the server time taking too long to render the form.
  3. Code is being repeated over multiple spots – for example the following code
    project_results = project.objects.filter(…
  4. No structure for the JS/CSS files

The general fixes for these would be;

  1. Split the view file into separate files for each modules. This will make each file smaller and easier to find the class you need
  2. Move a lot of the complexity out of the back-end and place it into front-end. VueJS is a powerful library that can easily deal with complicated forms
  3. Move these repeated codes into their own python file, with their own functions
  4. Utilise webpack to bring together all the required files for each library. Structure the folders for any JavaScript or SASS I write

As I am not releasing any new functionality – I am planning on implementing these changes during beta.

Refactoring NearBeach

One major issue NearBeach faced when we started getting users to test, was the simple fact that users HATED the UI/UX. I can not blame them, as I am not good at expressing visually. Design has been my weakest skill by far in web development. It has been something I have not given up on though – and in the last year I have learned a lot.

An early draft on the new UI/UX

I have decided that NearBeach will require a massive refactoring, both the UI/UX and the backend code. This will hopefully lead to a cleaner code base, and a streamline UI/UX.

NearBeach Beta 0.26.2 Release

The following are bugs that have been fixed

  • BUG577 – All tasks created by a user should be accesible to that user
  • BUG606 – Webp image now showing on iPhone Safari
  • BUG631 – Style the document uploader
  • BUG632 – Style Email Quote
  • BUG636 – Can make a quote that is already accepted
  • BUG641 – Opportunity Information – Success Probability needs to be larger
  • BUG656 – Template wide is missing favicon
  • BUG658 – PROJECT READ ONLY DOES NOT CHECK PERMISSIONS
  • BUG660 – User not forward to requirement readonly when they only have create permission
  • BUG661 – User not forward to quote readonly when they only have create permission
  • BUG662 – Creation user can modify RFC when they have no group permissions
  • BUG663 – Anyone can read RFC’s

You can install the release using PIP or find the release on github – https://github.com/robotichead/NearBeach/releases/tag/beta-0.26.2

There is 1 more planned release within the 0.26 branch. Then another full site test will be applied to NearBeach – with the results determining if there will be another release.

May 2020 – NearBeach update and it’s current future

I have a lot of plans for NearBeach. Many modules in my head that I want to implement into NearBeach. So why am I wrapping up to release a stable version? Simple – I had to draw a line in the sand somewhere. This is the best place to start – I can’t be stuck in a development cycle forever without a release.

What is coming up – how many version for the 0.26 branch? There are currently 2 planned 0.26 releases looking at fixing bugs and issues. After the next release I will be doing a system wide test of NearBeach – from there I will determine if we need any more releases.

What will happen after release? NearBeach 1.0 will be a long term support (LTS) version. How long we will support it will need to be discussed and planned. This is our very first LTS stable version of NearBeach. NearBeach will also have a secondary branch that will be for new development – once again, we are still in planning how this will work and we will have more information soon.

NearBeach’s Code

NearBeach started out as a learning project for myself. I had programming knowledge gained from my years of knowing C/C++, SQL, and other languages. A friend mentioned moving one of my prior ticketing systems from C++ to a web based application. NearBeach became that application.

As I learned more and more about web programming, NearBeach gained more and more modules, and essentially evolved into what it is today.

There is nothing wrong with this approach, however it does have a few shortcomings. One of those shortcomings is that I have learned a lot more effective ways to program for web development.

The next major release of NearBeach (lets call it 2.0 for now), will focus on the following;

  • Refactoring code, making it easier to read, quicker to implement new functionality, more efficient, have a defined structure.
  • Design update – NearBeach looks very bootstrap, and the reason is it is. I am not the best designer out there, however I have hit the books and youtube to try and improve my front end skills.
  • More modules – I will always be either adding or refining existing modules within NearBeach. If you require any extra features, why don’t you hit us up on our forums – https://help.nearbeach.org

Before we start any of these tasks, we want to create a stable code base. One with as few bugs in it as possible.

NearBeach Beta 0.26.1

Bug fixes, more bug fixes and some more bug fixes. It is currently very important for us to fix all current issues with NearBeach.

The new version of NearBeach can be installed using PIP

Bug Fixes

  • BUG563 – Instructions need to have “Group Leader” in them
  • BUG593 – Read only user in chrome has weird layout for “Run Sheet”
  • BUG621 – Table overflow needs scroll in administration group
  • BUG624 – Password Reset needs new layout
  • BUG626 – User settings – alert not in alert mode
  • BUG634 – Can not apply bugs to project
  • BUG637 – Organisation search is not character case insensative
  • BUG647 – New project under assign task
  • BUG648 – Adding a whiteboard to customer gives permission denied when accessing
  • BUG649 – Group projects dashboard shows closed projects
  • BUG651 – Read only user – can create kanban board
  • BUG655 – Linked objects in requirements showing requirement items

Short term future goals

We will do another bug finding and fixing run to try and get NearBeach as stable as possible before releasing into the wild as a stable product. We are currently looking for feedback, and are planning what to do in the future about developing new functionality.