Single project composed of different sections - how supply different versions? (3 Viewers)

[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

 

[Pat Hartman]

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

 

[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.

 

[Pat Hartman]

I used view to control what the switchboard shows. But, if it makes more sense to you, add a fifth option which is used only by the switchboard. Separate the functions into groups. That lets the view be a sub selection to hide/show forms within a group. Using the group option, I would probably add another table because a single person may need access to more than one group.

Anyway, the system as defined is very basic but it will give you a start and something to think about. As defined, it doesn't require you to associate each form with every individual but that is certainly done in many applications. It is harder to maintain though because it requires much more system knowledge and data entry so I would use the system as defined unless you have some special need for something else.

 

[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.)