ACL view access

Thank you for your assistance Hoffi.

I do hope that you guys will seek each other's approval before merging new code. Please remember we had a discussion about it last week, so please make sure that all you 4 (Hoffi, Bluefox Jojo and Diesl) agree on any change.

We simply do not have a good core-review procedure in placeb yet, and merging too quickly sometimes leads to more frustrations than joy.

That is my only concern in this matter.

Because I'm not a git expert Jojo had send me a zip per eMail and I would send my changes back per eMail - so there are only three...

Of course, this is not the best way because git allows branches (forks?) as far as I know. Maybe I find the time to learn git (locally) to prevent mistakes. At the moment my prevention strategy is not to push anything directly into JEM repo on github.

Yep, I do realise that you want to prevent messing the Git repo up. I actually think you have no access rights (yet) to push changes into the master.

My remark was more directed to the rest of the guys.

ernst67 wrote: My remark was more directed to the rest of the guys.

seems I've to respond.

@Ernst you're right. Well, can start a big discussion but think my opinion is clear about merging the ACL code at this point (postpone). Reviewing the code is something different and if there time in the weekend I don't mind to check it.

Beside of that this is the topic "feature request" and think the solution provided by Hoffi will do the trick for the problem Jojo stated. And think it can be used for later.


@Hoffi

Bluefox wrote something about weekend

That's correct, but if it's a week later it's no problem You'll notice that the model of the Event-page has also been modified a bit.


//
this topic can get big

@Bluefox,

I was not expecting a reply from anyone. Just want to make sure we don't take actions too quickly, and everyone stays happy

But let's be more specific about this: Do we vote Hoffi's proposal in JEM before version 2.0 or after? I can't overlook the consequences.

1. Does it imply a major change? (will his code change be enough, or does it have an impact on other code?)
2. Does it solve a problem that many people have?

We did agree to freeze features until the official release, so I think we can only implement this it it's a minor code change, and does not affect other parts of the software, and solves an issue for many users, AND if we all agree to do it.

(Sorry, I am throwing a lot of restrictions here...)

think we're hijacking this topic but to respond:

Does it imply a major change?

It depends, for me it ain't but it does involve several pages. The GID code is being replaced by the AuthorisedViewLevels and think it can be replaced without a lot of hassle. There will be a problem with multi-category-access but that's the same thing as it's now so that's also no reason against it.

Does it solve a problem that many people have?

There will be users that will run into it but think more then 50% won't have the problem.

think we're hijacking this topic but to respond:

Does it imply a major change?

It depends, for me it ain't but it does involve several pages. The GID code is being replaced by the AuthorisedViewLevels and think it can be replaced without a lot of hassle. There will be a problem with multi-category-access but that's the same thing as it's now so that's also no reason against it.

Does it solve a problem that many people have?

There will be users that will run into it but think more then 50% won't have the problem.

before version 2.0 or after?

It depends to what others think. If it was up to me i would say that when we're changing it we should also tackle the specific edit/create rights but that's something for another topic.