Single project composed of different sections - how supply different versions? (1 Viewer)

[amorosik]

Let's suppose we have the classic management software to make sales documents, accounting, warehouse, e-commerce, etc...
Different 'sections' each with a specific macro task, each section composed of different forms, reports, modules
And let's suppose we want to provide gigi with the version with only sales and warehouse, peppe with the complete package, mariuccia with only the e-commerce
Wanting to maintain a single project to minimize the problems related to code maintenance, how would you do to have the possibility of supplying different versions of the same project?

 

[CJ_London]

Your ‘sections’ are what are known as ‘schemas’. In access you would manage this as part of the login process and a user login profile to identify what a specific user is entitled to see. This can extend to user read/write permissions as well.

For example a sales manager might be restricted to only seeing their own teams sales - part of what they can see will be the salespersons name- but that is in the hr schema so they will need read access to the employee table - and that is further restricted to the name fields only and not other personal data

To identify schema I use the form/table etc name by including a prefix such as hr, fin,sls etc. objects use by all, such as a login form would be preceded by ‘sys’

 

[DHookom]

This project would require a robust database like SQL Server or Azure. The whole integrated system seems like SAP or Dynamics. I wouldn’t attempt to roll your own if your business depended heavily on it.

 

[CJ_London]

If you use sql server you can use schema level properties to set user rights

 

[amorosik]

Your ‘sections’ are what are known as ‘schemas’. In access you would manage this as part of the login process and a user login profile to identify what a specific user is entitled to see. This can extend to user read/write permissions as well.

For example a sales manager might be restricted to only seeing their own teams sales - part of what they can see will be the salespersons name- but that is in the hr schema so they will need read access to the employee table - and that is further restricted to the name fields only and not other personal data

To identify schema I use the form/table etc name by including a prefix such as hr, fin,sls etc. objects use by all, such as a login form would be preceded by ‘sys’

No, maybe I explained myself badly
My request is about the program, not the data
What I wanted to understand is whether it is possible to obtain version1, version2, version3 of the program, starting from a single project that we will call version0 that will contain all the sections
So what I'm asking is whether it is possible to obtain different versions starting from a single initial project

 

[amorosik]

If you use sql server you can use schema level properties to set user rights

The question is about program, not about data

 

[amorosik]

This project would require a robust database like SQL Server or Azure. The whole integrated system seems like SAP or Dynamics. I wouldn’t attempt to roll your own if your business depended heavily on it.

"..I wouldn’t attempt to.." ehhhh ???
I think I asked for a feature that is necessary for many developers who maintain a large single project and then want to provide the user with a version composed of some sections of the complete project
It is not a particular feature and necessary only for very large projects

 

[The_Doc_Man]

To clarify... are you asking about dividing up the project (for maintenance purposes) so that you would have separately maintainable parts of the project - to later be put together as a new version of the whole project? And each part represents one sub-function of the overall project?

IF that is what you are describing, I have seen various programs you could buy over the counter or online that are generally referred to as source-code management programs or configuration management programs (CM programs). I have never worked with one of those for Access because Access tends to be a bit difficult due to the way that code, forms, reports, and named queries are all stored in the same front-end file. I worked with one for a Navy project that wasn't Access-related and it was a pain in the keister due to the tedious requirements to check out a module, work on it, submit it for review, and eventually check it back in.

It is not IMPOSSIBLE to use CM programs that would track source code for Access, but it adds an extra step or two because of needing to export certain elements as text and then re-import them. I have been retired too long to remember the names of those CM products that claimed to be usable for Access and they might not even be around any more. But you could do a web search for configuration management products and perhaps get some ideas.

IF you are going to do this on your own, you need to set up a really strict set of rules for yourself that you must never bypass, regarding isolation of development, test, and production versions from each other, and you need some record-keeping elements to keep version status from getting convoluted. It is possible to do but I can't stress enough that you need to keep meticulous records at a level of detail that might be daunting.

 

[amorosik]

No, my request is the opposite of what you described
I have a single large project that I will call Version0, containing all the forms, queries, reports, modules used
I would like to set up a system that allows me to provide a project, that I will call Version1, which is a subset of the forms, reports, queries, modules contained in the Version0 project
A second project that I will call Version2 containing another subset of the forms, reports, queries, modules contained in the Version0 project

 

[CJ_London]

No, maybe I explained myself badly
My request is about the program, not the data

Perhaps you didn’t read my post properly. I mentioned the program and data.

classic management software to make sales documents, accounting, warehouse, e-commerce, etc.

So the tables will be shared. If all linked tables, related forms, reports queries and code modules specific to a section/schema all share the same prefix you simply import those to a new FE.

not the best way to manage an enterprise scale application but if you don’t want to do it by managing user access via tables it’s the only option

 

[The_Doc_Man]

Ah, I understand. The correct search argument would be "Role-based Security" or "Role-based access." You can search this forum for "Role-Based" and get a lot of hits.

 

[amorosik]

Here is a menuing system with very simple security which sounds like what you are asking for. It controls view/add/change/delete. The switchboard uses the view argument to determine who can see what. So, if you are not authorized to see the data, it doesn't appear on your menu as an option.

Switchboard with simple security

This is a custom switchboard. It expands on the Switchboard Items table to add four additional columns to define view/edit/add/delete security levels for switchboard items and forms/reports referenced by them. It includes tables to manage users and also to assign them security levels. The user...

www.access-programmers.co.uk

Yes, custom menu for Version1 e Version2 can solve the problem to limit accessibility only to 'section' desired
But this is the first step
I mean, i would like cut also the program

 

[Edgar_]

What I wanted to understand is whether it is possible to obtain version1, version2, version3 of the program, starting from a single project that we will call version0 that will contain all the sections
So what I'm asking is whether it is possible to obtain different versions starting from a single initial project

Yes, it's possible. These are two options for you in the context of MS Access:
1. Provide full version and limit it based on something.
2. Provide parts of full version based on something (this is what you're describing)

BUT...
I would keep this in mind, though:
What if two teams with the same responsibility want to do the same thing differently?

That's where things can get tricky very quickly. But if you don't have that problem, don't worry for now.

 

[isladogs]

As others have indicated, I would supply the full version to all users and then restrict it based on various conditions.
That's the approach used by MS for Office 2016/2019/2021/2024 and 365. All include the same core code but with different features enabled depending on the license currently in use. It works well and is reasonably simple to implement
Indeed, I've used this approach for many of my commercial and client apps for over 20 years.

 

[amorosik]

Yes, it's possible. These are two options for you in the context of MS Access:
1. Provide full version and limit it based on something.
2. Provide parts of full version based on something (this is what you're describing)

BUT...
I would keep this in mind, though:
What if two teams with the same responsibility want to do the same thing differently?

That's where things can get tricky very quickly. But if you don't have that problem, don't worry for now.

Yes, option 2 is what i would like to do

 

[amorosik]

As others have indicated, I would supply the full version to all users and then restrict it based on various conditions.
That's the approach used by MS for Office 2016/2019/2021/2024 and 365. All include the same core code but with different features enabled depending on the license currently in use. It works well and is reasonably simple to implement
Indeed, I've used this approach for many of my commercial and client apps for over 20 years.

Yes, this is one approch
I would like try other approch

 

[CJ_London]

I would like try other approch

Go for it then - since copy/pasting appears also to not appeal and using your version 0 as a library would not meet your ‘smaller’ requirement, I’m intrigued to know how you would accomplish this.

 

[Josef P.]

If these "modules" are standalone, you could consider calling them as an "add-on/add-in" from a start application.
But I see more disadvantages in splitting it up than just maintaining one big application and “unlocking” only the required modules in it.
The only advantage is that you only have to update one add-in file (e.g. "Warehouse") if something has been changed in it. Anyone who does not use this module does not need an update. (This can also be implemented in the complete (1 file for all modules) application so that an update is only required as soon as a module in use has been changed.)

 

[isladogs]

One of the many advantages of maintaining one version and restricting according to e.g. job role or license type is that the app doesn’t need to be reinstalled if the conditions change e.g changing job role or purchasing a Pro license. It will update the functionality automatically according to the new settings.

The other approach will be more complex to setup, maintain and distribute but if that’s what you want to do then it’s your choice

 

[The_Doc_Man]

I had a role-based environment where part of the role choice was whether a person was an systems administrator or project manager and another part was for which projects the person had legitimate authority. The way I approached it was that every person was in the Users table, which included a person's role. The customer dictated that a person had one and only one role with regard to admin, manager, reviewer, or something else - even though in theory that level COULD have been qualified by project. There was a project table and a person's ID appeared in a junction table to show that s/he had rights within a project. The system was a dispatch/switchboard type of setup with buttons to open reports or forms. Each report or form had an _Open event that checked the person's rank and project rights, and forms/reports would Cancel for project violations. Reports didn't care about admin vs. manager vs. reviewer, but forms, during the _Load routine, would set up flags internally so that when the user navigated, the Form_Current routine might mark certain controls is locked (but still visible) or hidden (and locked).

Admittedly, this was tedious to set up, but I made a template form that had some of the security code already set up, just waiting for the detailed control changes to be implemented. I just copied the template to whatever name it needed to be and edited the detailed effects - but having the code already set up in the form for the various safeguards cut anywhere from 30% to 60% off the coding time. Also had the side-effect that since every form used the same template, there was a consistency of look-and-feel.