Forum OpenACS Development: Re: roles in permissions

I think that the bug-tracker formally defines roles, but they are private to that application. Query-writer can define roles which span an entire OpenACS instance, or application specific roles which are required for an application to function.

The acs_rel_roles seems overly complicated, but there may be uses for all of this complexity somewhere. Besides defining what each endpoint of a relationship is, you get a limit on the number of each possible side, something like a restricted mapping. This is beyond the built in capabilities of a relational database and requires special triggers to maintain the constraint (you don't have to write the triggers, but application code will become more difficult to code when the constraint is violated, you now have a new fail point).

A new concept is a typed map. You could implement this in OpenACS fairly easily. The idea is very simple: any object could have a typed relationship with any other object. Essentially you get an overlapping DAG which can be traversed by either generic or application specific code. Typed relationships allow you to archive in place, rollback to previous points in time, or roll forward to a future date and see what the state will be. Applications should not be too much harder to develop because they will all use very similar methods to do the difficult jobs. But if applications require advanced features, the job will be much easier, and it should be possible to start simple and add on things like archiving without the need to reprogram.

A typed map is somewhat on the other end of the scale from acs_rel_roles. The database knows nothing about the application and doesn't enforce application level logic. Therefore, the application is responsible for deciding what data to use and what relationships to create. The database just stores those decisions. The main constraint on the developer is that all objects/types/classes are on the same level. There is no reason for subtypes, and it generally blows the abstraction of independent objects all to hell. But this constraint makes the programming task very much easier. Although you don't have subtypes, the typed relationship provides possibly even more potential for describing the relationship. For instance, if you have an employee->employer relationship. This is not an immutable relationship like father->son. This relationship only exists for a certain span of time. Father->son could be figured out by looking at a birthday of son, but is it a biological relationship, or legal? With a typical mutable relationship, most data models would require that you destroy the information if the relationship ceases to exist or changes. If you have an employee chart which lists names and positions which change over time, can your simple relationship model keep up with that? If a customer moves or changes their phone number, where do you store the previous data which is probably referenced on an invoice? What happens when a customer sends you a change of address for a move one month in the future? Do you store the paper somewhere and hope you remember to put it in at the right time? So only focusing on the time value of a relationship can give a lot.

Now consider the fact that each relationship is also an object with as many attributes as you wish, and these are added to the immutable attributes of the related objects.

Say you wanted to maintain a list of friends, past and present. You add a friend beginning the relationship, maybe you marry them, they are no longer a 'friend'. But all you have to do is to put an end date which corresponds to the new begin date for your spouse(s).

In OpenACS, you could redefine applications to use a typed map. Forums have threads composed of messages. If someone posts a message to the wrong forum, an admin could 'move' it to the right forum by expiring the previous mapping and creating a new one. Users could query the message history and discover that it had been in another forum. Also, a message or thread could appear on multiple forums. It would be easy for an application to display this fact so that users could traverse between forums and threads to find related discussions or subjects. You could add in a previous message/ to the current thread so you don't have the problem we have here where five year old threads get revived with new information at the very bottom.

Wow, I didn't realize you were talking about SL! Definitely my favorite accounting package. I kind of like the way it works where you push enter on a form and it gets updated like an automatic search. OTHO, the values get locked in once they are used. If you add an item to an invoice and then realize you have a 30% discount to that customer, it is hard to then go back and change the conditions. I guess that explains it: it is some kind of transaction or saved state.

I would put transactions in a different category than typed maps because typed maps refers to permanent data. There is a difference. Permanent data doesn't undergo much change, except for things like correcting mistakes, or setting the expire date. But both can be used the same, using the same tables, maybe more effectively than a transaction. The reason is that you can add an order, an invoice which has not been mapped to be valid yet. Once it is mapped as valid, that freezes the date/time of the invoice, now values used in the invoice are based upon that date when building/displaying it at a future date. After that, you can go in change the customer address, expiring the old address, then go print the just added invoice, with the old address.

In the case of discovering an incorrect discount after starting an invoice (as above), this would be immediately reflected in the open invoice since you haven't set the transaction date/time. Admins would always have the ability to see the state of the system at any past time, or selectively look at what a part would look like in the future (given current knowledge).

But this could be time consuming to apply to SL, so this isn't really a recommendation to try it.