Single project composed of different sections - how supply different versions?

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

Yes, of course
But I would like to experiment with the second system, the possibility of cutting out only the necessary code
 
I wanted to understand if you know the solution
The solution I know but would not use would be copy/paste so now you understand. I’m interested in knowing your solution or at least understanding why the two solutions suggested do not meet your requirements and some idea of what you envisage as being an acceptable solution
 
I mean, i would like cut also the program
That is the road to chaos. My software is always delivered as the same code base. The license key provides the information required to assign functions to groups. Within the app, the administrators can control the usage of forms by individuals by using the internal security which is similar to what is done in the sample app.
I actually asked in the group because I wanted to understand if you know the solution
So you know "the" solution but are toying with us. I quit, you're on your own. I don't have time to waste on your test. Do not expect me to bother answering future questions you post.
 
It feels to me like you are heading down a road with many forks. And more every day as new folks want different combinations of things. It sounds like a maintenance nightmare.

I designed a system which I called C2DbPresentLevelSecurity of Groups / users / User groups / Forms / Group forms... all maintained inside of access. I then set up what people belonged to what groups. I then set up what groups (not people) could see and perform what activities on what forms and reports. I am a class(y) kind of guy so it is all driven by the form or report class loading as a form loads, then calling into my C2DbPLS library checking what group(s) the current user belongs to, and from there whether the form loading is allowed to - be visible, it might load but not be visible or not load at all (close back down), allow edits (does the group(s) have edit rights?), Allow Adds (does the group(s) have rights to add records, and AllowDeletes (can the group(s) delete records in that form?).

It is not a trivial undertaking to set up the data but once set up it is just a matter of adding new users to groups. I call it table driven programming because these tables mentioned above drive the program rather than hard coding such things. A small maintenance nightmare rather than a huge maintenance nightmare.
 
That is the road to chaos. My software is always delivered as the same code base. The license key provides the information required to assign functions to groups. Within the app, the administrators can control the usage of forms by individuals by using the internal security which is similar to what is done in the sample app.

So you know "the" solution but are toying with us. I quit, you're on your own. I don't have time to waste on your test. Do not expect me to bother answering future questions you post.
I think we might be dealing with a language problem rather than an intention problem.
 
I think we might be dealing with a language problem rather than an intention problem.
The OP has a reputation of asking open ended questions and omits relevant facts about the requirement. Look back though their history. This one is a good example as it relates to this thread.
 
That is the road to chaos. My software is always delivered as the same code base. The license key provides the information required to assign functions to groups. Within the app, the administrators can control the usage of forms by individuals by using the internal security which is similar to what is done in the sample app.
Also my software is made like this, with a key that activates the authorized functions
And many other software are made like this
But now I want to check other possibilities, I don't understand why this request may seem strange to you
If you don't know how to answer, don't answer

So you know "the" solution but are toying with us. I quit, you're on your own. I don't have time to waste on your test. Do not expect me to bother answering future questions you post.
I'm asking for something, and this means that I don't know it otherwise I wouldn't have asked
It only takes a little effort to understand it
 
The OP has a reputation of asking open ended questions and omits relevant facts about the requirement. Look back though their history. This one is a good example as it relates to this thread.

"..omits relevant facts about the requirement.."
To understand the request, you just need to know how to read, it's written
 
To understand the request, you just need to know how to read, it's written
And if responders ask for clarification it would appear you are too arrogant to answer

I'm off this thread, a complete waste of everyone's time
 
While I agree in principle with other members here that this direction of investigation invites a LOT of extra work, I also realize that (a) amorosik is an experimenter and (b) what he suggests would lead to an experiment that would reveal the extra work.

@amorosik - while I don't think this is a productive path, I acknowledge that it is your time to spend in determining the best way to do some of this kind of role separation.

You asked about splitting DB files according to intended purpose/role within the overall application. You didn't specify how you would do the split. I will advise that having multiple back-end files would be counter-productive because you would take away the ability to declare Relational Integrity across the multiple BE files. But if you have one BE and multiple front-end files, at least you would keep everyone synchronized to the same data.

Splitting the FE and the BE into role-based parts would lead towards a dangerously confusing configurations that would make proper configuration management more difficult than it should be, because now you would have to remember which FE talked to which BE, and that would be a really interesting junction table. But a side-effect is that if you had multiple BE files statically linked, you increase your vulnerability to outages if any ONE of the files goes awry. Whereas if it is a singular BE and multiple FEs, only an affected FE and therefore a single FR purpose that would be effected.

Like I said, it is your direction, your time to spend as you see fit. Go for it.
 
I'm asking for something, and this means that I don't know it otherwise I wouldn't have asked
It only takes a little effort to understand it
You said this was a test because you already know the answer. You want to know if any of us know YOUR answer. That is a total disrespect of our time and I'm not playing.
 
Also my software is made like this, with a key that activates the authorized functions
And many other software are made like this
But now I want to check other possibilities, I don't understand why this request may seem strange to you
If you don't know how to answer, don't answer
My software also works with an activation key. The difference is that ALL the functions are in the code base. They are not added on the fly.
 
I use a library to hold all my code which is common across my apps / clients. Sometimes two libraries. Then the FE mostly has app specific code. Other than that I use a Presentation Level Security system to determine who gets to see what. I would never even consider splitting a database up. That said, if there are tightly controlled bounds, then perhaps a sales database, an accounting database etc. But to try and do this on the fly is just nuts IMHO.
 
You said this was a test because
I never wrote that this is a test
you already know the answer.
I never wrote that I knew the answer
You want to know if any of us know YOUR answer.
I never wrote that I wanted to know if you know MY answer
I wrote that I wanted to know if you know the answer to the question posed
And finding an answer to the question posed is the main goal of every person who inserts a post
That is a total disrespect of our time and I'm not playing.
I am sincerely sorry that you may think that my question was not respectful, but I have to tell you that it is not so.
 
I use a library to hold all my code which is common across my apps / clients. Sometimes two libraries. Then the FE mostly has app specific code. Other than that I use a Presentation Level Security system to determine who gets to see what. I would never even consider splitting a database up. That said, if there are tightly controlled bounds, then perhaps a sales database, an accounting database etc. But to try and do this on the fly is just nuts IMHO.

"..on the fly.." it's something that has never been asked
 
@amorosik - as you can see from the answers you got, your question seemed confusing to some. I suggest that you consider that at least some of the responses you got MIGHT have been misunderstandings.

Having functionally separate front-ends will already be a configuration nightmare. It is good that you were not looking to do this dynamically i.e. on the fly, because that would probably run into more problems than you might ever want to see. I warned you earlier and commented on split schemes that could work vs. those that probably would not. If you choose to go down the "functionally separate front ends" path, I will have little to offer in the way of help. I have always built monolithic FE files that simply refused to open forms or enable various fields based on a table of user roles and authorizations. I never tried any other way so have no advice that I haven't already given.
 

Users who are viewing this thread

Back
Top Bottom