Thanks for your interest in the module!

There is a template patch in the Formulize area on dev.xoops.org which turns off report writing mode and all its features for non-admin users of the form.

Note that the patch takes notice of admin permission on that specific form, as defined in the module itself, it does not pay attention to a group's module access permission.

Please direct other questions/issues/requests to the trackers and the forum in the Formulize area on dev.xoops.org. Thanks. I hope Formulize helps you do what you need to do.

--Julian

Block placement (the layout of items on the page) is centrally controlled. Sorry. I believe certain modules integrate with RSS; there is no core integration with RSS.

--Julian

This sounds very similar to a bug reported in 2.0.7 here:

http://sourceforge.net/tracker/index.php?func=detail&aid=1014403&group_id=41586&atid=430840

I think they thought that was fixed. I suggest posting another bug report, or a followup to that one above. Check to see if the Admin menu entry is present but just contains no text, or whether that menu entry is just completely gone. If it is present but has no text, then it's definitely the same symptom as that bug above.

--Julian

LDAP is a minefield. And it is not really like SQL. SQL is, well, like the name suggests, a standardized query language that you use to retrieve info from a database.

LDAP is a specialized database system optimized for storing contact type information and which provides very fast read access. Setting up and connecting to an LDAP directory is a chore, to say the least. It is no where near as straight forward as adding a datatable to your XOOPS DB and then querying it.

That's not to say it can't be done. And integration with LDAP is a very very cool thing, and very very useful.

However, if your organization does not already have an LDAP directory then I see absolutely no point in building this functionality into your module. None, you're just making extra work for yourself.

--Julian

I believe the hope is that these features will be available in 2.2, the next big release of XOOPS for end users. 2.1 will be a development version that will hopefully make it easy to swap out the registration system and replace it with one more suited to your needs.

We have plans to do something like what you describe for the 2.0.X branch of XOOPS. You can read about it here:

http://sourceforge.net/forum/message.php?msg_id=2951479

I can't say when such a solution would be complete though, it's still in the planning stages.

--Julian

You should ask the developers. Try the trackers in their space on dev.xoops.org.

I think the files end up in the main XOOPS upload folder off the root.

--Julian

They have a spot on dev.xoops.org:

http://dev.xoops.org/modules/xfmod/project/?formulaire

--Julian

Quote:

Thank you mOnty.

I am sure I could have come to a clear conclusion about this myself if I had followed along more closely with all the releases, patches and comments about them.

But once I sensed there was a problem with 2.0.9, I just steered clear and thought I'd come back when the dust settled. The thing is, while it was pretty clear from what was going on (several patches all at once) that here was something really wrong, there was no clear announcement once the dust had settled.

--Julian

Quote:

Indeed, there are many implications of the word....

Quote:

Yes, I would definitely agree with that.

Quote:

I agree that they do not have an obligation per se, certainly not in a legal sense.

But I think it's somewhat disingenuous to suggest that the fact you don't pay hundreds of dollars for XOOPS makes a significant difference. The license agreements of 99% of commerercial software clearly state that they take no responsibility for data loss, damage, or any screwup to your system caused by their software. It's one of the big differences between software engineering and other engineering disciplines: if the bridge falls down, the engineer is on the hook, but if the software fries your machine, too bad, so sad for you.

I don't want to get into a debate about whether or not that is a fair difference between software engineering and other types of engineering, I just want to point out that open-source software and commercial software are not so different in this respect.

I think the overall professionalism of the XOOPS project has created an expectation on the part of the users. Just as you expect that, because they are a reputable company, Valve will fix the sound stuttering problem in Half Life 2, even though they don't have to, I think it's fair to expect that the XOOPS team will deal with the block problems in 2.0.9.x, because XOOPS is a reputable project.

I guess another way to put it would be: I agree that the XOOPS team is not obliged to fix the problem (and no one should jump up and down demanding they do), but I expect, reasonably I think, that the XOOPS team will make software releases from time to time, each one improving on previous releases in whatever ways they think is best. And I expect that they will think it's best to fix this problem, so I expect that they will fix this problem.

And let's be clear: they *are* working on the problem and I absolutely believe they will fix it -- I'm not suggesting that they're not doing this and I think they should and they're wrong for doing whatever they're doing. I just think it follows from the track record and the reputation of the XOOPS project that they would deal with this, and so it's okay for users to expect that they will deal with it.

But I take your point that it would be crossing a line to suggest that users *have a right* to expect the XOOPS team will fix this. That is an important point.

Quote:

I think your position here is more than fair to such an individual! However, if you released a patch for AMS that somehow screwed up the display of articles on the front page of people's sites, I am sure you would race to fix the problem, and wouldn't it be fair of your users to expect that you would fix the problem?

Quote:

Yes, but see my point above about commercial license agreements. The material below is from the end-user license for MS Word 2000:

Quote:

So they're saying that you have a right to expect the documentation will more or less accurately describe what the software does. Whoppie! And you don't have a right to expect much else:

Quote:

Check any other commercial software license, they're basically all the same. And note the similarities between the wording of the GPL and the Microsoft license, in terms of implied warranties. Coincidence? Nope. Both licenses simply use standard legal wording to cover the asses of the developers.

Paying for your software entitles you to nothing special, it's just a different way of funding development than the open-source model. I don't think anyone should suggest that there's a fundamental difference between what you should expect from a commercial versus an open-source product. All you can expect is whatever the reputation of the company or project leads you to believe.

--Julian

This is a complicated thread with a lot of valid ideas and opinions, and for the most part I agree with both (all?) sides, to some degree (I don't think there's a fundamental disagreement here, but perhaps a difference of opinion in approach or degree).

I'd like to offer some comments on just one point...

Quote:

I completely support the idea that everyone in the community is capable of (and should be encouraged to) help out however they can. I also agree that non-programmers are capable of more than they realize.

But I think that's the double-edge of this sword: non-programmers often literally do not realize what they can offer, or lack the knowledge necessary to offer it. Detailed information about how or when you run into a problem, plus detailed information about your site setup, OS, PHP version, etc, is often beyond the ability of many users to provide.

However I think it is unreasonable to suggest that the core team is in some kind of equal relationship with posters in the support forums, and everyone has simliar obligations to work at fixes. The core developers are releasing a product for others to use, and there is an implied responsibility there, the lack of warranty notwithstanding, which does not flow in the other direction. End users do have a right to expect something be done for them, namely, that developers fix serious problems that they introduce.

There has been a lot of fantastic features and overall professionalism in the XOOPS project over the last year or so, which make it even more reasonable to expect that upgrades will not actually damage your XOOPS installation. Introduce some bugs, maybe, but this block situation is actually harmful to a site. That is very serious, it's the most serious kind of bug you can ever have. To my knowledge, there has never been so serious a bug in XOOPS.

I made a comment to this effect in a news posting, and it was perhaps harsh of me to do so without saying more. So I'll pipe up here and say that I think the core devs have done and continue to do an amazing job; XOOPS really is reaching a professional level of maturity. But that is why the problem is so serious, in my opinion. A problem of the magnitude of the blocks bug is simply not expected at all from a project that is otherwise so good.

So, especially considering the professionalism that the XOOPS team has exhibited in pretty much every area, I think the "you broke it, you fix it" attitude is completely fair. It's what you would expect of a professional software development effort, and XOOPS has been behaving in a professional way overall.

Sure, the users have a role to play filing bug reports, etc, more so for open-source projects than for commercial ones. But the fundamental responsibility lies with the developers.

I also think the communication effort about this could be better. There has been no prominent explanation of the problem in a news posting. There have been numerous threads discussing problems, and notes in the changelogs for patches that mention problems. But no single explanation.

I think this multipliction of references to the same issue(s) actually makes things seem worse than they are, because there's more chatter in the ether about this stuff than there would be if there were a single point of discussion about them. The current situation unnecessarily propogates FUD (fear, uncertainty and doubt) about 2.0.9.2.

My original training was in journalism, and there is a principle in the press (not always followed!) that if you run a correction, it should be as prominently placed in the newspaper as the original story was. I think that advice holds true for any communication effort: if there's a major problem like this in an upgrade, then some statement about the problem should be made, in the same way that the upgrade itself was announced. In this case, that means a news posting.

I have yet to see a clear statement that the problem only affects users who upgraded from 2.0.7.3 to 2.0.9 or to 2.0.9.1, but not ones who go straight from 2.0.7.3 to 2.0.9.2. I don't even know if that is true, though I think it is from what I've read. That kind of information should be coming from a central, reliable, trusted source, and should be broadcast prominently to the community. That's the kind of thing that eliminates FUD.

Anyway, like I said, I don't think there's a fundamental disagreement going on here. But I do think the overall excellence of the XOOPS project makes this issue stand out in stark contrast.

--Julian